分布式系统之美（主要讲的还是分布式数据库）

分布式系统之美 （知乎社区直播）

其实这次分享看完并记录之后有一些还是不是太懂的地方，关于一致性算法，两阶段提交（在我个人而言这就是一个主从确保，最终保证事务特性的算法，可以先看看seata的AT模式，再理解一下TCC模式三个字符的意思，关于seata的saga长事务个人还是不太理解补偿冲正，XA的话Mysql就有实现）的讲解不是太多，但是说了一个Gossip,可以后续了解一下，还有关于zk的ZAB我也不知道黄老师说的意思，因为实操不多但是我觉得竟然使用范围广，毕竟有他的可取之处。
黄：关注不变的东西

分享人：伴鱼（徐成选，陈现麟）,知乎（白瑜庆），PingCAP(黄东旭)

C（一致）A（可用）P（分区容错）

CAP理解：
徐：三个属性有自己的定义，结合实践的角度
系统基于网络通讯，跨机房，网络不可达也是一种分区
分区出现了，要么停下1去保证一致性，要么继续运行保证可用性

白：A的可用性也有自己的程度，针对情况
P必然存在，不仅是网络故障，也有可能是节点故障
解决：多副本等减小P的影响范围
不是非黑即白

黄：百分百的A不存在（个人也是赞同）吗，原来理论中A是百分百的
实际保证的是H-A
TiDB：这个一致性C和ACID的C不是一回事，这趋向于一种解释，在C的基础上开发出一种东西，然后这种东西去构建一种ACID的能力
其实只要看看redis的关于ACID的几种情况，就能理解上面几句话，更简单的来说这是一个数据库系统对事务的保证，这一句话个人觉得是这此分享的精华，是一个不变的东西

陈：线性一致性（不太懂），CAP（90年代过早的论文，现在有不同的解读）

Personnal：三种属性在实际的生产中是均衡，不是非黑即白

##实际业务中对于数据库落地的挑战
解决问题，保证稳定。
（伴鱼）陈：理论先支持，操作首先要保证回滚，然后再保证一点点平滑的过渡
单机到分布式迁移

徐：早期从16年就开始从mongo迁移，迁移历史大表，业务感知，双写（缓存，数据库的一致性），迁移之后
索引失效，针对某一条数据过慢，Mongo的服务端连接数，服务治理（熔断（库，表级别）等），研发中间件
实现范式级别的锁定（记得蚂蚁的seata也在做细粒度锁定），做sql-WAF

白：单库容量上限，先使用Hbase,很重。TiDB从实例热点数据问题。

黄：金融长事务，TiDB金融场景下5.0在做，要让延迟尽量要比单机事务处理的延迟要低。串行改并发
单机单线程串行叠加，（一个事务单机1ms，分布式10ms），分布式数据库的吞吐是比较大的，前提是事务之间交叉少。单机多机的区别
优化器TiDB自己写的，索引选择可能有问题

徐：单表扩容
数据库扩容

黄：基于binlog复制改成基于relog复制

白：30亿数据，Mysql做业务变更，改DDL

徐：数据补足，多个节点不一样，还要merge补页

Paxos&&Raft||一点点Gossip（关于这两个算法，我之后会更一份对比博客，以前写过）

徐：Paxos不是太理解，Raft主要趋向于实践
陈：也是趋向于实践Raft
黄：序列算法，日子复制状态机。两个充分优化的其实性能差不多，写并发的吞吐Paxos较好，但能写不能用，尤其是在
“数据空洞”。但是如果数据之间是没有交集相互独立，就没有影响。阿里的并行Raft对吞吐有优化（个人没了解，抽时间看看）。
Gossip（个人看了一点，感觉这不是一个强一致性保证）