其实这次分享看完并记录之后有一些还是不是太懂的地方，关于一致性算法，两阶段提交（在我个人而言这就是一个主从确保，最终保证事务特性的算法，可以先看看seata的AT模式，再理解一下TCC模式三个字符的意思，关于seata的saga长事务个人还是不太理解补偿冲正，XA的话Mysql就有实现）的讲解不是太多，但是说了一个Gossip,可以后续了解一下，还有关于zk的ZAB我也不知道黄老师说的意思，因为实操不多但是我觉得竟然使用范围广，毕竟有他的可取之处。 黄：关注不变的东西
分享人：伴鱼（徐成选，陈现麟）,知乎（白瑜庆），PingCAP(黄东旭)
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主要趋向于实践 陈：也是趋向于实践Raft 黄：序列算法，日子复制状态机。两个充分优化的其实性能差不多，写并发的吞吐Paxos较好，但能写不能用，尤其是在 “数据空洞”。但是如果数据之间是没有交集相互独立，就没有影响。阿里的并行Raft对吞吐有优化（个人没了解，抽时间看看）。 Gossip（个人看了一点，感觉这不是一个强一致性保证）
