OB-oceanbase 蚂蚁集团开源的分布式关系型数据库支付宝底层数据库2021年开源是金融级分布式数据库的代表海量交易。以Paxos强一致、透明水平扩展Mysql兼容为卖点。架构shared-nothing paxos强一致适用于金融、交易、高并发、大数据量场景mysql兼容 应用层几乎无感知ob与mysql对比 前者是原生分布式透明水平扩展后者是单机为主、主从复制分库分表需要中间件。mysql 适合中小业务ob适合海量业务场景。mysql 中小业务、快速上线oceanbase 海量交易强一致性postgresql 复杂查询丰富数据类型clickhouse 分析型大数据查询Paxos一致性算法用于多个节点就某个值达成一致即使部分节点故障也能保证一致性。多数派投票两阶段提交基于消息传递且具有高度容错特性的一致性算法是目前公认的解决分布式一致性问题最有效的算法之一。分布式系统中总会发生机器宕机或网络异常消息延迟、丢失、重复、乱序网络分区等情况paxos需要解决的是如何在一个可能发生上述异常的分布式系统中快速正确在集群内部对某个数据的值达成一致并保证不论发生以上任何异常都不会破坏整个系统的一致性。数据的值不是狭义上某个数可以是一条日志也可以是一条命令根据场景不一样数据的值有不同的含义。三种角色proposeracceptorlearnerspaxos算法阶段一(准备)proposer选择一个提案编号N向半数以上的accepter发送编号为N的prepare请求acceptor收到编号N承诺不再接受任何编号小于N的提案。阶段二采纳如果proposer收到半数以上accepter的响应就发生一个[NV]提案的accept请求给accepter。如果acceptor收到编号N的提案请求只要没有对大于N的做出响应就接受该提案。paxos活锁是指多个proposer交替提出更高编号的prepare请求互相覆盖对方的进度导致系统理论上可以无限循环却始终无法达成共识。通过给proposer增加一个随机时间解决该问题。paxos一致性算法图解 https://blog.csdn.net/qq_57581439/article/details/153215271为了解决活锁问题 引出了raft算法。raft算法多节点之间数据一致性问题paxos的替代方案leader 负责处理所有客户端请求周期性发送心跳维持地位若follower超期没收到心跳就变成candidate发起新一轮选举 若同步数据失败follower会无限期重试直至成功followercandidatepaxos是分布式一致性算法的的理论基础但是实现复杂、难以理解raft通过强领导机制和模块设计降低理解和工程落地门槛。分布式架构shared-nothing是一种分布式架构每个节点拥有独立的CPU、内存、存储节点之间不共享资源仅通过网络通信协作。仅影响本节点 节点间无冲突 oceanbase/Mysql分片 加节点即可扩容单点故障不影响其他。主要缺点 跨节点事务复杂需要分布式事务shared-disk共享磁盘影响共享磁盘 需锁协调 Oracleshared-memory共享磁盘和内存全局影响 需锁协调 代表 传统单机数据库