聊聊replication的方式
序
本文主要聊一聊主流开源产品的replication方式。
replication
replication和partition/sharding是分布式系统必备的两种能力。具体详见复制、分片和路由. 对于海量数据来说，replication一方面可以增加冗余，保证系统可用性，一方面还可以提升读取的效率。 本文主要聚焦于replication，即假设每个node都足以存下整个副本。
replication type
按照有无leader以及leader数目可以分为：
- single leader replication 即一主多从的复制方式，由leader同步/通知follower，只有leader能接受写操作，follower只能读不能写。
- multi leader replication 即多主多从，有多个leader分布在不同node，同时接受写入操作，而每个leader之间相互为follower。比较适合多数据中心的场景，不过对于并发写多数据中心冲突解决的复杂度也增加。
- leaderless replication 无中心的复制，不区分主从副本，任意节点都可以接收请求，然后又它去通知其他副本进行更新。
leader-based replication way
具体详见副本更新策略，主要有如下几种
- sync replication 同步复制，这个可以保证强一致，不过follower多的情况下，延迟太大，一般很少使用
- async replication 异步复制，这个可能造成读不一致，但是写入效率高
- semi sync replication 半同步，一般采用quorum的机制，即当写入的节点个数满足指定条件，即算写入成功，然后通过并发请求多个node来满足读取的一致性
leaderless replication way
无中心的复制，可以分为三种拓扑结构，环形、星/树型、网状拓扑
replication implementation
主要分为以下几种
- statement/trigger-based replication 这种是基于数据库的语句或触发器来实现的复制，但是存在一定的问题，比如一些now()/rand()/seq()等函数可能造成主从同步的不确定性，比如从节点的now()/rand()等执行结果跟master不一样。mysql5.1版本之前用的是这种，5.1+版本,当有不确定语句时,就切换为row-based log replication
- write-ahead-log replication(
WAL) WAL是数据库中一种高效的日志算法，对于非内存数据库而言，磁盘I/O操作是数据库效率的一大瓶颈。在相同的数据量下，采用WAL日志的数据库系统在事务提交时，磁盘写操作只有传统的回滚日志的一半左右，大大提高了数据库磁盘I/O操作的效率，从而提高了数据库的性能。 PG使用的就是这种。 - row-based-log replication(
logical log) WAL跟数据库存储引擎是耦合的，而row-based-log也称作logical log，是跟存储引擎无关的，采用的是change data capture的方式，这个就很方便异构数据源的数据同步。
replication带来的问题
replication lag
- 同步差异大 比如mongo的oplog太小，跟不上写入速度，造成旧的操作日志就会被丢弃，主从延迟一直增加导致副本同步失败。
- 新加入node的同步 比如在线扩容增加replication，这个时候就涉及新节点的node的replication问题，一般这类同步的方式跟正常在线节点的同步方式是分开的，新的node同步到一定的时候才转为正常的增量同步方式。
master slave failover
一般replication增加冗余常用来做master的的热备(支持查询)/温备(不支持查询)
- 当主节点挂的时候，这个时候就涉及选哪个replication为主的问题
- 当旧的master恢复的时候，这个时候就涉及旧master与新master之间的数据差异的处理 read consistency 一旦replication支持读取的话，那么就涉及读的一致性问题，一般理论上除了强一致外，有这几种最终一致性：
- （1）因果一致性（Causal consistency） 即进程A在更新完数据后通知进程B，那么之后进程B对该项数据的范围都是进程A更新后的最新值。
- （2）读己之所写（Read your writes） 进程A更新一项数据后，它自己总是能访问到自己更新过的最新值。
- （3）会话一致性（Session consistency） 将数据一致性框定在会话当中，在一个会话当中实现读己之所写的一致性。即执行更新后，客户端在同一个会话中始终能读到该项数据的最新值
- （4）单调读一致性（Monotonic read consistency） 如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
- （5）单调写一致性（Monotoic write consistency） 一个系统需要保证来自同一个进程的写操作被顺序执行。
读取的话，涉及读己所写，因果读(
针对操作有序)、单调读(不读到旧数据)
quorum/RWN方案解决读冲突
write quorum
假设某份数据需要复制到3个节点，为了保证强一致性，不需要所有节点都确认写入操作，只需要其中两个节点（也就是超半数节点）确认就可以了。在这种情况下，如果发生两个相互冲突的写入操作，那么只有其中一个操作能为超过半数的节点所认可，这就是写入仲裁（write quorum），如果用稍微正规一点的方式说，那就是W>N/2，这个不等式的意思是参与写入操作的节点数W，必须超过副本节点数N的一半，副本节点数又称为复制因子（replication factor）。
read quorum
读取仲裁（read quorum），也就是说想保证能够读到最新的数据，必须与多少个节点联系才行。假设写入操作需要两个节点来确认（W=2），那么我们至少得联系两个节点，才能保证获取到最新数据。然而，假如某些写入操作只被一个节点所确认（W=1），那么我们就必须3个节点都通信一遍，才能确保获取到的数据是最新的。一个情况下，由于写入操作没有获得足够的节点支持率，所以可能会产生更新冲突。但是，只要从足够数量的节点中读出数据，就一定能侦测出此类冲突。因此，即使在写入操作不具备强一致性的情况下，也可以实现除具有强一致性的读取操作来。
RWN
- R 执行读取操作时所需联系的节点数R
- W 确认写入操作时所需征询的节点数W
- N 复制因子N
这三者之间的关系，可以用一个不等式来表述，即只有当R+W>N的时候，才能保证读取操作的强一致性。
主流开源产品的replication概览
产品 | 复制方式 | 实现方式 | 其他 |
|---|---|---|---|
mysql | 主从半同步 | MySQL 5.0及之前的版本仅支持statement-based的复制,5.1+版本,当有不确定语句时,就切换为row-based log replication | 主从延迟处理 |
kafka | 主从ISR半同步 | leader写入消息并复制到所有follower,ISR中的副本写入成功返回ack给leader才算commit成功 | 生产者可以选择是否等待ISR的ack |
elasticsearch | 主从半同步,默认replication=sync | consistency可选的值有quorum、one和all。默认的设置为quorum | tradelog及fsync以及refresh |
pg | 主从异步复制 | 基于Write-ahead log | archive及stream方式 |
redis | 主从异步复制 | 增量Redis Protocol(全量\增量\长连接) | Sentinel failover |
mongo | 主从异步,Replica set模式 | 持久化的ring-buffer local.oplog.rs(initial_sync,steady-sync) | Arbiter选主 |
可以看见一些对一致性要求高的，可以采用半同步的机制，一般是基于quorum机制，像es就是基于这种机制，而kafka是采用ISR机制，二者都可以配置 其他的基本是异步复制，对于新加入的node以及recovery node的同步来说，采用不同的同步方式，新加入的一般采用全量同步，而处于正常状态的node，一般是增量同步
小结
不同产品的replication细节不尽相同，但是大的理论是一致的，对于replication除了关注上述的replication相关方式外，还需要额外关注replication相关异常场景，才能做到成熟应用。
doc
- kafka 数据可靠性深度解读
- RWN及Quorum与强一致性
- es一致性问题
- es的写入过程
- Elasticsearch学习笔记(三)Elasticsearch集群分片的读写操作流程
- ElasticSearch权威指南-分片内部原理