持久化

合并不采用路径压缩，保证每次合并只修改一个节点的父亲，使当前版本与上一版本共用的节点尽可能的多 为防止并查集退化成链，采取按秩合并 \(code\) ： void build(int L,int R,int &cur) { cur=++tree_cnt; if(L==R) { fa[cur]=L; return; } int mid=(L+R)>>1; build(L,mid,ls[cur]); build(mid+1,R,rs[cur]); } void merge(int L,int R,int pos,int fath,int pre,int &cur) { cur=++tree_cnt; if(L==R) { fa[cur]=fath; de[cur]=de[pre]; return; } ls[cur]=ls[pre],rs[cur]=rs[pre]; int mid=(L+R)>>1; if(pos<=mid) merge(L,mid,pos,fath,ls[pre],ls[cur]); if(pos>mid) merge(mid+1,R,pos,fath,rs[pre],rs[cur]); } int query(int L,int R,int pos,int cur) { if(L==R) return cur; int mid=(L+R)>>1; if(pos<

此文章是webmagic 0.1.0版的设计手册，后续版本的入门及用户手册请看这里： https://github.com/code4craft/webmagic/blob/master/user-manual.md 之前就有网友在博客里留言，觉得webmagic的实现比较有意思，想要借此研究一下爬虫。最近终于集中精力，花了三天时间，终于写完了这篇文章。之前垂直爬虫写了一年多，webmagic框架写了一个多月，这方面倒是有一些心得，希望对读者有帮助。 webmagic的目标 一般来说，一个爬虫包括几个部分： 页面下载 页面下载是一个爬虫的基础。下载页面之后才能进行其他后续操作。 链接提取 一般爬虫都会有一些初始的种子URL，但是这些URL对于爬虫是远远不够的。爬虫在爬页面的时候，需要不断发现新的链接。 URL管理 最基础的URL管理，就是对已经爬过的URL和没有爬的URL做区分，防止重复爬取。 内容分析和持久化 一般来说，我们最终需要的都不是原始的HTML页面。我们需要对爬到的页面进行分析，转化成结构化的数据，并存储下来。 不同的爬虫，对这几部分的要求是不一样的。 <!--more--> 对于通用型的爬虫，例如搜索引擎蜘蛛，需要指对互联网大部分网页无差别进行抓取。这时候难点就在于页面下载和链接管理上--如果要高效的抓取更多页面，就必须进行更快的下载；同时随着链接数量的增多

1. Zookeeper的基本操作 　　zookeeper中的节点可以持久化/有序的两个维度分为四种类型： 　　PERSIST：持久化无序（保存在磁盘中） 　　PERSIST_SEQUENTIAL：持久化有序递增 　　EPHEMERAL：非持久化的无序的，保存在内存中，当客户端关闭后消失。 　　EPHEMERAL_SEQUENTIAL：非持久有序递增，保存在内存中，当客户端关闭后消失 　　每个节点都可以注册Watch操作，用于监听节点的变化，有四种事件类型如下： 　　Created event: Enabled with a call to exists 　　Deleted event: Enabled with a call to exists, getData, and getChildren 　　Changed event: Enabled with a call to exists and getData 　　Child event: Enabled with a call to getChildren 　　Watch的基本特征是客户端先得到通知，然后才能得到数据，Watch被fire之后就立即取消了，不会再有Watch后续变化，想要监听只能重新注册； 使用原生Zookeeper创建节点和监听节点变化代码如下： 　　1. 引入依赖，pom.xml <dependency>

可持久化数组 可持久化数组是一种可以回退,访问之前版本的数组 是一些其他可持久化数据结构的基石 例如可持久化并查集） 与普通并查集不同的是 这里用到了 按秩合并 不了解可以百度一下 添加链接描述 # include <stdio.h> const int N = 2e5 + 7 ; int rootfa [ N ] , rootdep [ N ] , cnt , tot ; struct Node { int l , r , val ; } T [ N * 40 * 2 ] ; int n ; void insert ( int l , int r , int & now ) { now = ++ cnt ; if ( l == r ) { T [ now ] . val = ++ tot ; return ; } int mid = l + r >> 1 ; insert ( l , mid , T [ now ] . l ) ; insert ( mid + 1 , r , T [ now ] . r ) ; } void modify ( int l , int r , int pre , int & now , int pos , int val ) { T [ now = ++ cnt ] = T [ pre ] ; if ( l == r ) { T [ now ] .

原文: 分布式事务,EventBus 解决方案:CAP【中文文档】 最新文档地址： https://github.com/dotnetcore/CAP/wiki 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解，所以花了将近两周时间写了这份中文的CAP文档，对 CAP 还不知道的同学可以先看一下 这篇文章 。 本文档为 CAP 文献（Wiki），本文献同时提供中文和英文版本，英文版本目前还在翻译中，会放到Github Wiki 中。 目录 前言 1、Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick Start 2、API接口 2.1 发布/发送 2.1.1 事务 2.2 订阅/消费 2.2.1 例外情况 3、配置 3.1 Cap Options 3.2 RabbitMQ Options 3.3 Kafka Options 3.4 SqlServer Options 3.5 MySql Options 4、设计原理 4.1 动机 4.2 持久化 4.3 通讯数据流 4.4 一致性 5、实现 5.1 消息表 5.2 消息格式 5.3 EventBus 5.4 重试 6、分布式事务 6.1 异步确保 7、FAQ 1、Getting Started 1.1 介绍 CAP 是一个遵循 .NET Standard 标准库的C#库

redo 日志是用来保证 MySQL 持久化功能的，需要注意的是 redo 日志是 InnoDB 引擎特有的功能。 为什么 InnoDB 引擎会引入 redo 日志作为中间层来保证 MySQL 持久化，而不是直接持久化到磁盘？我们先来看看《MySQL实战45讲》中提到的一个故事。 在《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊账记录。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜一定还有一个专门记录赊账的账本。 如果有人要赊账或者还账的话，掌柜一般有两种做法： 一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉； 另一种做法是先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。 在生意红火柜台很忙时，掌柜一定会选择后者，因为前者操作实在是太麻烦了。首先，你得找到这个人的赊账总额那条记录。你想想，密密麻麻几十页，掌柜要找到那个名字，可能还得带上老花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。 这整个过程想想都麻烦。相比之下，还是先在粉板上记一下方便。你想想，如果掌柜没有粉板的帮助，每次记账都得翻账本，效率是不是低得让人难以忍受？ 同样，在 MySQL 里也有这个问题，磁盘就相对于账本，如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程 IO 成本

文章目录 RabbitMQ 1 基本概念 2 安装 3 核心概念 交换器类型 4 入门demo 客户端开发相关说明 1 exchangeDeclare方法 2 queueDeclare方法 3 消费消息 4 消费的确认与拒绝 5 消息的可靠性投递 消息可靠性投递解决方案 RabbitMQ 1 基本概念 消息 (Message) 是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串、JSON 等，也可以很复杂，比如内嵌对象。 消息队列中间件 (Message Queue Middleware，简称为 MQ) （消息队列或者消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 两种传递模式：点对点(P2P, Point-to-Point) 模式和发布/订阅 (Pub/Sub) 模式 比较主流的有 RabbitMQ,Kafka,ActiveMQ, RocketMQ等。 面向消息的中间件(简称为 MOM ， Message Oriented Middleware) 提供了以松散藕合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的消息中间件通信 。

RabbitMQ一般情况很少丢失，但是不能排除意外，为了保证我们自己系统高可用，我们必须作出更好完善措施，保证系统的稳定性。 下面来介绍下，如何保证消息的绝对不丢失的问题，下面分享的绝对干货，都是在知名互联网产品的产线中使用。 1.消息持久化 2.ACK确认机制 3.设置集群镜像模式 4.消息补偿机制 第一种：消息持久化 RabbitMQ 的消息默认存放在内存上面，如果不特别声明设置，消息不会持久化保存到硬盘上面的，如果节点重启或者意外crash掉，消息就会丢失。 所以就要对消息进行持久化处理。如何持久化，下面具体说明下： 要想做到消息持久化，必须满足以下三个条件，缺一不可。 1） Exchange 设置持久化 2）Queue 设置持久化 3）Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息 第二种：ACK确认机制 多个消费者同时收取消息，比如消息接收到一半的时候，一个消费者死掉了(逻辑复杂时间太长，超时了或者消费被停机或者网络断开链接)，如何保证消息不丢？ 这个使用就要使用Message acknowledgment 机制，就是消费端消费完成要通知服务端，服务端才把消息从内存删除。 这样就解决了，及时一个消费者出了问题，没有同步消息给服务端，还有其他的消费端去消费，保证了消息不丢的case。 第三种：设置集群镜像模式

PV和PVC Kubernetes Volume提供了非常好的数据持久化方案，不过对于大型Kubernetes集群来说管理上还有不方便之处。Volume方案需要创建Pod或者Deployment的管理员对共享存储的参数和机制比较清楚，甚至对一些存储的访问是需要身份验证的，这导致集群用户（存储使用者）和系统管理员（存储管理员）的职责耦合在一起了。但对于大型的生产环境，为了管理的效率和安全，集群用户（存储使用者）和系统管理员（存储管理员）是分置的。 Kubernetes引入了两个新的API资源PersistentVolume和PersistentVolumeClaim来解决这个问题。 PersistentVolume（PV）是集群中由系统管理员配置的一段网络存储。它是集群中的资源，就像node是集群资源一样。PV也是像是Volumes一样的存储插件，但其生命周期独立于使用PV的任何单个Pod。PV配置存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。PV属于集群级别资源，不属于任何的Namespace。 PersistentVolumeClaim（PVC）是使用存储的请求，属于Namespace中的资源。PVC类似于Pod，Pod消耗node资源，PVC消耗PV资源。Pod可以请求特定级别的计算资源（CPU和内存），PVC可以请求特定大小和访问模式的存储资源。

模板代码： #include<bits/stdc++.h> using namespace std; typedef long long LL; #define mid ((l+r)>>1) const int INF=1e9+7,MAXNODE=24e6+7,MAXN=1e6+7; int N,M,tmp[MAXN],rt[MAXN]; int val[MAXNODE],lson[MAXNODE],rson[MAXNODE],sz; void init(int &x,int l,int r){ x=++sz; if(l==r){ val[x]=tmp[l]; return; } init(lson[x],l,mid); init(rson[x],mid+1,r); } void modify(int &x,int l,int r,int p,int q,int v){ x=++sz; if(l==r){ val[x]=v; return; } lson[x]=lson[p]; rson[x]=rson[p]; val[x]=val[p]; if(q<=mid) modify(lson[x],l,mid,lson[p],q,v); else modify(rson[x],mid+1,r,rson[p],q,v); } int query(int x,int l,int r,int