# 问题:Dynamo风格的数据库和CP模型的主从复制数据库相比，优势是什么？
看DDIA时产生了一个疑问：像dynamo和cassandra这样的Leaderless Replication数据库和CP模型的主从复制数据库(比如只进行写操作的Zookeeper，比如MGR模式的Mysql集群[1]，比如通过Raft协议做数据复制的TiDB[2])相比，究竟有什么优势呢？
我理解Leaderless Replication相对于主从复制的缺点是：
1.需要quorum读写，每次写和读都要发送给多个节点，导致整个网络负载增高(当然，主从复制数据库通过Raft协议写数据时也要同步写多个节点）
2.没有主节点导致难以确定写入顺序，会产生写冲突
3.更复杂，比如引入一些复杂的冲突解决机制，还不一定能完美解决冲突
但是Leaderless Replication的优点我能想到的只有：
1.主从复制数据库在主节点故障时要failover,过程中会有短暂的写不可用，Leaderless Replication没这个问题
——但是failover的时间很短，难道dynamo的优势就只有这短暂的failover时间？
2.适合多机房。但是把主从复制改成主主复制也能适合多机房，所以这条不算
综上，看起来并没有什么优点，那当初为什么设计这么复杂的Dynamo呢？
# 解答：Dynamo不严格要求Quorum、放弃线性一致性时，能得到更好的availability
在知乎上咨询了aws大佬@阿莱克西斯，得到了解答：
豁然开朗，Dynamo的优势在于：允许使用者选择w+r<=N或者使用Sloppy Quorum、允许放弃强一致性，从而获得更好的avaliability。
# 如何理解“放弃线性一致性，就能获得更好的avaliability”
CAP理论告诉我们，当网络分区时，想保证强一致性就得牺牲可用性。那么，如何结合实际场景来理解呢？这里想到了几种场景：
1. 对于主从复制、CP模型的数据库（用paxos等算法做主节点选举，避免脑裂），当网络分区时，较少的那部分分区将不可用
场景1.1. 双机房场景，两个机房之间的网络故障（比如光缆被挖断了），假设app1只部署到机房1，app1只能访问到同机房的db follower，此时app1的写不可用，因为app1访问不到DB的主节点
场景1.2. 假设app1部署到了两个机房，机房间网络故障，但是负载均衡层（比如dns）不能自动把少数分区（机房1）的流量切走，此时访问机房1里的app1的用户会发现写入失败
场景1.3. 假设app1部署到了两个机房，机房间网络故障，负载均衡层自动把少数分区（机房1）的流量切走，所有访问app1的流量都流入机房2，但是机房2的app1集群机器数量不够多，系统过载，访问app1的请求大量超时
场景1.4. 即使是同一个机房内，交换机配置错误可能导致不同网段的机器互相无法访问，产生了网络分区，此时也会出现上述问题[3]
2.放弃quorum读写的Dynamo可以理解为AP模型的数据库，可以容忍故障节点数>= N/2，而CP模型只能容忍故障节点数<N/2的情况
3.CP模型的数据库，在主节点故障、重新选主的过程中会有短暂不可用，而Leaderless Replication的数据库没有这种问题
4.使用Raft等协议的主从复制数据库可能在网络不稳定时反复选举主节点，资源都浪费在选举上了[4]。
# 下一个问题：不严格要求Quorum的Dynamo和其他非强一致的Nosql数据库（AP模型的主从复制数据库)相比，会有更强的可用性吗？
我觉得这个问题很难回答，因为如果按照CAP的严谨定义来看，找不到现实世界的一个AP模型的主从复制数据库[5]。大部分主从数据库的选举都要求新leader获得大多数的投票，这就导致在分区情况下难以CAP-Availability。
开启只读模式、只进行读操作的Zookeeper是AP模型，但讨论只有读操作的场景好像没多大意义，因为Dynamo的优势是读和写都高可用
# 是不是可以说，在市面上所有（常用）分布式数据库中，不严格要求Quorum的Dynamo具有最强的可用性？
如果是这样的话，像阿里云这样的厂商很适合做Leadless Replication的数据库呀，毕竟云厂商对可用性的要求非常高。但是我翻了一下阿里云的产品，好像没有这种风格的数据库？
请教了大佬，大佬对这个问题的理解是：追求CAP中的A意义不大，因为CAP中的A指网络分区时少数派不可用，为了让partition时少数派可用而牺牲C会在app层制造非常多麻烦（出bug几率，app的复杂度暴增，开发周期等），不如在物理层增加冗余网络连接
# 附：引文
[1]美团数据库高可用架构的演进与设想https://tech.meituan.com/2017/06/29/database-availability-architecture.html
[2]三篇文章了解 TiDB 技术内幕 - 说存储https://pingcap.com/blog-cn/tidb-internal-1/
[3]浅谈zookeeper性能的优缺点https://cloud.tencent.com/developer/article/1039171
[4]Designing Data-Intensive Applications第九章《Limitations of consensus》
[5]https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html
网友评论