第六周总结

分布式数据库

数据库分片

在业务数据量巨大，单一表数据量过大，需要进行数据分片。

1. 使用硬编码实现数据分片。(不够灵活)

2. 映射表外部存储。（外部映射表的数据量会很大）

3. 分布式数据库中间件：MyCat

分片所面对的问题:

• 需要大量的额外代码，处理逻辑更加复杂。

• 无法执行多分片的联合查询。

• 无法使用数据库的事务。

• 随着数据增长，如何横向扩容。

数据库部署方案

• 单一服务器与单一数据库。（简单的应用，MVP）

• 主从复制实现伸缩。（读取压力较大的场景）

• 多个Web服务器对应多个数据库。（业务规模增大，需要低耦合实现业务拆分）

• 综合部署。（针对性的对压力较大的业务服务模块进行优化）



NOSQL

CAP原则

1. 如果选择可用性(A) + 分区容错性(P), 就要放弃一致性(C)。

2. 如果选择一致性(C) + 分区容错性(P), 就得放弃可用性(A)。

3. 如果选择一致性(C) + 可用性(A), 就得放弃分区容错性(P)。



弱一致性：在以写入数据成功后，在数据副本上可能读不出来，也不能保证多长时间后每个副本上的数据都是一直的。

最终一致性：写入数据成功后，虽然在其他副本可能读不到该最新的值，但是在某个时间窗口之后能保证最终能读到该最新的值。

最终写一致冲突的解决方式：

1. 根据时间戳，最后写入覆盖。

2. 客户端冲突解决。（根据具体的业务）

3. 投票解决冲突（Cassandra）

强一致性：数据一旦写入成功，在任意的副本上都能读到该最新数据。

有的为了保证严格一致性会按照GPS时钟以保证时间一致性。



HBASE架构





ZooKeeper



分布式一致性算法Paxos

三个角色：

• Propose

• Acceptor

• Leaner



Zab协议

• 领导者（Leader）： 作为主节点，在同一时间集群只会有一个领导者。需要你注意的是，所有的写请求都必须在领导者节点上执行。

• 跟随者（Follower）：作为备份节点， 集群可以有多个跟随者，它们会响应领导者的心跳，并参与领导者选举和提案提交的投票。需要你注意的是，跟随者可以直接处理并响应来自客户端的读请求，但对于写请求，跟随者需要将它转发给领导者处理。

• 观察者（Observer）：作为备份节点，类似跟随者，但是没有投票权，也就是说，观察者不参与领导者选举和提案提交的投票。



Zab相较于Paxos算法最大的区别在于引入了ZXID，每个事务有一个全局单调递增的id，所以能够按序提交，解决了事务操作如何保证全局有序的难题。