第 6 周 - 总结

分布式数据库

众所周知，传统数据库即便是“主 - 主”复制，依旧无法做到多库同时写入，而且磁盘IO是所有设备中读写最慢的设备，如果所有的业务都由一个数据库负责写入，压力可想而知。

业务分库

解决数据写入压力的办法就是将分布式系统按照业务领域进行拆分，业务各自建立自己的数据库，不同业务通过远程调用互联通信，也就是所谓的业务垂直拆分。



分表

然而分库并不能解决大表的问题，需要继续将大表按照某一维度进行数据分片，每个数据段分别存储在不同的schema中，每个schema存放在不同的数据库中，来分担数据压力。通常对表的操作交由像Mycat这样的中间件进行数据的访问路由。



CAP 原理

CAP中的C指的是一致性，A指的是可用性，P指的是分区容忍性，且任何系统都只能在C、A、P中选择三者中的两个，也就是不存在同时满足一致性、可用性、分区容忍性的系统。

• CP : 当系统选择一致性、分区容忍组合时，一旦数据发生分区，操作没法立即同步到数据，只好回滚操作，系统处于不可用（牺牲了可用性）。

• AP: 当系统选择可用性、分区容忍性时，当网络发生故障产生数据分区，系统操作为了达到系统可用，必须对外响应操作处于某软状态中，此时系统牺牲了一致性。

• CA： 要达到一致性和可用性，此时数据是不容许产生分区的，这就好比单机模式中的本地事务。

总结：在分布式系统中，网络不可用是无法避免的问题，因此分布式系统应该容忍分区，而有C和A中作出选择，也就是CP或AP。



ACID与BASE

• 严格的ACID

• 原子性（Atomicity）

• 事务要嘛全部成功，要嘛全部取消，如果事务奔溃，状态回到事务之前。

• 隔离性(Isolation)

• 隔离级别

• 读未提交

• 读已提交

• 可重复读

• 事务内，数据只存在一个版本，不会随外部事务的提交而变更。

• 串行读

• 冲突时锁定，等先拿到锁的事务提交或回滚方可读写数据。

• 持久性(Durability)

• 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

• 一致性(Consistency)

• 事务前后数据的完整性必须保持一致

• BASE

• Basically Available（基本可用）

允许损失部份可用性，如响应时间上的缺失或功能上的损失。

• Soft State(弱状态)软状态

不同于原子性，允许数据存在中间状态，并认为中间状态不会响应系统的整体可用性，允许数据副本之间同步存在延时。

• Eventually consistent (最终一致性)

系统保证数据能够最终一致，而不需要系统保证数据实时的强一致性。

分布式协调 Zookeeper

树型目录数据存储结构+数据变更事件监听

• 打铁还在自身硬，ZK选主

作为协调者，ZK自身通过选主算法选出LEADER

• 分布式一致性算法角色：

• Proposer

• Acceptor

• Leaner