PaxosStore解读
1.
QuorumKV (NWR)
微信有大量分布式存储(QuorumKV)使用这个算法保证一致性,我们对这个算法做了改进,创造性地把数据副本分离出版本编号和数据存到不同设备,其中N=3(数据只有2份,版本编号有3份),在R=W=2时仍然可以保证强一致性。因为版本编号存放3份,对版本编号使用Quorum方式,通过版本编号协商,只有版本序号达成一致的情况下读写单机数据,从而在保证强一致性的同时实现高读写性能。实际数据只写入一台数据节点,使用流水日志的方式进行同步,并更新版本编号。但是我们的分布式存储(QuorumKV)仍存在数据可靠性比Paxos低的问题,因为数据只写一份副本,依靠异步同步。如果数据节点故障,故障节点上没有同步到另一个节点,数据将无法访问。版本节点故障时,如果Quorum协议没有设置W=3,也可能无法访问正确的数据节点副本。
2. PaxosStore (paxos)
2.1 paxosStore介绍
paxosStore是一个在跨园区数据中心间同步复制,提供灵活的数据模式和访问接口并支持单表亿行,具备快速伸缩能力,低延迟低成本,强一致和高可用的分布式存储系统。
特点:1) 无租约Paxos工程化,多主多写,高可用;
2) 针对业务特性优化,合并整体优化成本15+%;
3) 同一容灾、迁移框架下,支持多种插件化存储引擎、亿行大表;
4) 快速伸缩能力,基于反馈的自适应迁移系统。
2) 针对业务特性优化,合并整体优化成本15+%;
3) 同一容灾、迁移框架下,支持多种插件化存储引擎、亿行大表;
4) 快速伸缩能力,基于反馈的自适应迁移系统。
paxosStore的整体架构:
编程模型针对各种外部应用提供多种数据架构。一致性层(consensus layer)执行基于 Paxos 的存储协议。存储层包含了多个根据不同存储模型构建的存储引擎,这些引擎可以满足各种各样的性能要求。PaxosStore 的架构与传统存储设计的不同之处主要在于它能将一致性协议应用提取出来作为一个中间件,为所有潜在的存储引擎提供数据一致性保证。
2.2 一致性层详解
2.2.1 paxos

2.2.2 paxos
paxosLog的结构:

相关字段的解释:
1)Promise No:
2) Proposal No:
3) Request ID:
4) Proposer ID:
5) value:
paxosLog + Data对象:

PaxosLog-as-value for key-value storage:

PaxosStore 中读取过程的示例:

2.2.3 基于PaxosLog的强一致性读写协议
1) 强一致性读协议
2) 强一致性写协议
这里有三个优化点:
A. 优化写
FastWrites部分,描述:LogEntry i-1值的归属者可以在写LogEntry i时跳过Paxos算法的Prepare阶段直接进行Accept阶段。基于这段迷一样的文字,我们实现Paxos优化写算法:减少1次写盘、2次协议消息发送、2次协议消息接收;最终实现了写耗时和失败的降低。
B.
如何确定谁的提议写成功了?
Paxos算法只保证LogEntry i确定唯一值,但在多个Proposer的条件下(即A/B机均可发起强一致写),只有确定值的归属者可以返回成功。这里我们复用了etcd中requestid的方案。
其中member_id用于区分不同的Proposer,timestamp为毫秒级别的时间戳,req_cnt随写请求单调递增。基于requestid方案可以满足单机25w/s的写请求,足够了。requestid只需要在单个plog纬度上保证唯一即可。
C.
Paxos活锁问题
Paxos算法本身不保证终止性,当出现写冲突时算法可能永远终结不了,即存在活锁问题;因此在实际工程中我们需要进行一些权衡:限制单次Paxos写触发Prepare的次数和随机避让。我们目前使用了Prepare次数限制策略。
2.3 存储层详解
2.4 容错性和可用性详解
3. 总结
PaxosStore是微信内部一次大规模Paxos工程改造实践,创新性地实现了非租约Paxos架构。