多副本数据一致性技术

这里数据一致性指数据多副本数据一致的。

MySQL

MySQL通常采用半同步进行主备复制，这时能保证底层数据一致性。

当发生异常时，半同步退化为异步复制，主备数据写入存在延时，存在不一致情况，主实例如果故障，备实例会丢失部分数据。

master将每个事务写入binlog(sync_binlog=1)，并发送到slave刷新到磁盘(sync_relay=1)，同时主库提交事务(commit)。master等待slave反馈收到relay log，只有收到ack后master才将提交成功结果反馈给客户端。

TiDB

TiKV 利用 Raft 来做数据复制，每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制功能，将数据安全可靠地同步到复制组的每一个节点中。不过在实际写入中，根据 Raft 的协议，只需要同步复制到多数节点，即可安全地认为数据写入成功。

Raft日志复制过程：客户端请求服务端，服务端leader把这条命令作为新的日志条目加入到它的日志中，然后并行地向其他服务器发起 AppendEntries RPC请求 ，如果其他服务器大部分成功复制日志条目并反馈给leader，leader会将这个条目应用到自己的状态机中，然后把执行的结果返回客户端。其他服务器随后也会将这个日志条目应用到自己本地的状态机中。

https://docs.pingcap.com/zh/tidb/stable/tidb-storage#raft-协议

OceanBase

OceanBase使用日志流在多副本之间同步状态。

日志流使用自研的 Paxos 协议将 Redo 日志在本服务器持久化，同时通过网络发送给日志流的从副本，从副本在完成各自持久化后应答主副本，主副本在确认有多数派副本都持久化成功后确认对应的 Redo 日志持久化成功。从副本利用 Redo 日志的内容实时回放，保证自己的状态与主副本一致。

https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000881167#复制层

Pulsar

Pulsar采用计算与存储分离架构。Pulsar负责计算，Bookeeper负责存储。

BookKeeper中每个Ledger(由一个或多个Fragment组成)可以跨多个BookKeeper节点(Bookies)进行复制，以实现数据容灾和提升读取性能。每个Fragment都在一组不同的Bookies中复制(存在足够的Bookies)。

通过以下配置可以设置Topic数据一致性级别

• Ensemble Size (E)

• Write Quorum Size (Qw)

• Ack Quorum Size (Qa)

1. Ensemble表示将要写入的实际的Bookies数量，以下用E表示。E表示Pulsar需要使用的Bookies数量。Ensemble Size (E) 决定了Pulsar写入Ledger可用的Bookies池的大小。

2. Write Quorum (Qw) 是Pulsar将要写入的实际的Bookies数量。可以等于或者小于E。

3. Ack Quorum (Qa) 是确认写入Bookies的数量，Pulsar Broker将确认发送给客户端。为了一致性，Qa应该是：(Qw 1) / 2 或者更大。

4. 增加E以优化延迟和吞吐量。增加Qw牺牲吞吐量实现冗余。增加Qa提升数据的容灾但会增加延迟和单一节点响应慢导致的延迟增加。

在实际使用中配置为：

• 5 3 2：5个Bookies的写入池，写入3个副本，有2个确认成功，就返回客户端写入成功。

• 3 3 2：3个Bookies的写入池，写入3个副本，有2个确认成功，就返回客户端写入成功。

• Qa<Qw，避免单点响应慢，改善响应延迟

某个Topic属于固定某个Broker，客户端连接到非所属Broker时，会重定向到Owner Broker上。

https://mp.weixin.qq.com/s/CIpCLCxqpLoQVUKz6QeDJQ 理解Apache Pulsar工作原理

ScyllaDB

ScyllaDB是C 版本的Apache Cassandra。

ScyllaDB所有节点都是对等的。

ScyllaDB可以通过CL与CF灵活设置复制策略：

• Consistency Level 一致性级别（CL）确定集群中的多少副本在被视为成功之前必须确认读取或写入操作。

• Replication Factor 复制因子或RF等于要复制数据的节点数。

RF=3 CL=2 时：

• 写请求发送到对应的三个副本节点上，当有两个副本写入成功，返回给客户端写入成功

• 读请求发送到其中的两个副本节点上，两个副本返回数据一致，返回给客户端读取的数据

CL与CF可在语句级别设置，灵活满足应用的不同场景的需求。
ScyllaDB节点对等，客户端发送请求到任一节点，节点根据数据分布，复制数据响应节点上。

总结

数据一致性技术有以下共性：

1. 一个领导者

2. 一个协调者

3. 多个跟随者

4. 多数派确认

分析如下

• MySQL主实例作为领导者与协调者，负责接收数据请求，协调主备实例，写入数据，确认写入成功，保证数据一致性。

• TiDB中TiKV通过选举产生领导者，同时作为协调者，负责接收数据请求，协调自身与追随者，写入数据，确认多数成功，保证数据一致性。即通过Raft协议保证数据一致性

• OceanBase与TiDB过程相似。不过是通过Paxos协议保证数据一致性。

• Pulsar中Broker作为领导者与协调者，负责接收数据请求，将数据写入多个bookies，确认多数bookies写入成功，保证数据一致性。Pulsar自行实现领导者选举。

• ScyllaDB 任一节点作为领导者与协调者，负责接收数据请求，写入数据到多个节点，确认多数写入成功，保证数据一致性。

MySQL、TiDB与OceanBase:

• 领导者负责接收数据请求，写入数据，commit数据

• 协调者负责复制数据，多数派确认，通知跟随者commit数据

• 领导者与协调者是逻辑角色，为了区分功能。

Pulsar 采用代理层与存储层结构，Broker作为代理，负责请求接收、转发与确认，不负责数据存储。

ScyllaDB 节点对等，合并代理层与存储层。

• 请求数据如果没有落到本节点上，则只转发数据。其他对应节点写入数据。

• 请求数据如果落到本节点，则写入本节点，同时转发数据写入到其他剩余节点。

本质上是两种模式:

1. Leader-Follower 通过Paxos或类Paxos一致性协议保证数据一致性。

2. Client-Server 通过客户端转发复制数据，多数派确认保证数据一致性。

3. 两种模式实现表现不同，实质上还是多数派，保证数据一致性。