架构师训练营第六周 - 总结

这周主要讲了分布式数据库，NoSQL数据库中的CAP原理，以及ZooKeeper的原理与使用。



分布式数据库

什么分布式数据库呢？

简单的说就是使用时，大于一台数据库服务器在运行，这些服务器可同时对外提供服务（主写从读），也可部分对外提供服务（主备方案）。

我们为什么需要分布式数据库？

单台数据库服务器对外提供服务的能力达到了瓶颈，需要扩大读写能力，或者服务器容量达到瓶颈。

常见的分布式数据库方案有主备，主从，主主，分库分表。

主备，一台主服务器，负责读写，一台备用服务器，同步主服务器数据，不对外提供服务，做数据备份，防止数据丢失，做数据的高可用。

主从方案，主服务器负责写，从负责读，优点有：

• 分摊负载

• 专机专用

• 便于冷备

• 高可用

缺点是当主服务器挂掉后，无法再写入，且无法自动恢复。

主主方案，主主方案是两套服务器部署，其中一套主服务器挂掉后，自动切换到另一套服务器。一套服务器内部可以做主从。

主主复制，只是提高了数据库写可用性，并没有增加服务器写并发能力和存储能力。两个主服务器不能并发写入。

我们时常听到分库分表，但分库分表包含两层含义。

首先当预测到数据库压力将会比较大时，首先对不同业务进行拆分库。即首先垂直拆分。把关联度不大的业务数据库放到不同的数据库上。

随着业务的持续发展，一张表需要存储上亿条数据的时候，就需要分表。即水平拆分。

拆分表时，有一些技巧。比如，拆分时，预估一张表最终需要存储的数据量，比如，最终差不多有10亿条数据，那我们可以分为12张表。但是，当前数据量比较小，使用12台服务器比较浪费，当前只需要三台服务器就可以够用。随着业务的发展，逐渐加服务器。数据库表在存储时，是以文件的形式保存。当要加机器的时候，移动数据，只需要使用linux命令scp就可以把数据传输过去。

比如：

3台服务器时，服务器1：1,4,7,10；服务器2:2,5,8,11；服务器3:3,6,9,12。

4台服务器时，服务器1：1,5,9；服务器2:2,6,10；服务器3:3,7,11；服务器4:4,8,12。只需要对应调整服务器上文件即可。

分表时，可以客户端决定连接的数据库服务器，也可以在应用和数据库服务器之间加一层库表路由层，在分库分表层配置决定连接哪台服务器。



NoSQL数据库

NoSQL数据库，Not only SQL，NoSQL数据库天生支持分库分表，这对于需要存储大数据量的用户来说是一个好的选择。

NoSQL中，有一个很著名的理论，CAP理论。

C：一致性，Every read receives the most recent write or an error。就是说每次读取的都应该是最近写入的数据或者返回一个错误，数据是一致的。

A：可用性，Every request receives a (non-error) response, without the guarantee that it contains the most recent write。每次请求都会返回一个值，而不是一个错误，但是不保证这个值是最新写入的。

P：分区耐受性，The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes。即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的。

对于当前网络环境来说，多节点之间一定会出现网络故障问题，故CAP三者中P是一定要满足的。

C与A在分区可用性的前提下，是不可能共存的。所以分布式数据库要选择CP或者AP。

CP满足了数据一致性，但可用性就大打折扣。

AP满足了可用性，但是数据不一致会带来业务上的困扰。

现在，业界主流使用的既不是CP也不是AP，而是CA各自让了一步，是最终一致性。

最终一致性解决数据冲突的方法：

• 根据时间戳，最终写入覆盖（数据只要最新的，且数据之间无依赖关系）

• 客户端冲突解决（购物车场景）

• 投票解决冲突（Cassandra使用方案）



Zookeeper

zookeeper解决的问题是：分布式环境下脑裂问题。

在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，被称作分布式系统脑裂。

如常见的主主备份场景，如何选择一个主服务器为写服务器？

Zookeeper通过paxos协议解决了这个问题。

paxos协议中有三个角色：

1. proposer

2. acceptor

3. learner

决议三阶段：

1. prepare阶段。proposers向acceptors发出prepare请求，acceptors针对收到的prepare请求进行promise回应。

2. accepte阶段。proposers收到多数acceptors的promise回应后，向acceptors发出propse请求，acceptor针对收到的propose请求进行accept处理。

3. learn阶段。proposers在收到多数acceptors的accept之后，标志着本次accept成功，决议达成，将形成的决议发送给所有learners。

Proposer生成全局唯一且递增的proposal ID，向所有acceptor发送prepare请求，这里无需携带提案内容，只携带proposalID即可。Acceptor收到prepare和propose请求后:

1. 不再接受proposalID小于等于当前请求的prepare请求

2. 不再接受proposalID小于当前请求的propose请求。

主主备份时，两台主服务器选举，产生一个master节点，今后由master节点来管理集群事务。

Zookeeper使用在多种分布式场景中。

如kafka集群，客户端从zookeeper中获取主节点。

HBase中，使用zookeeper获取HMaster节点。