架构师训练营第一期 - 第六周学习总结

在互联网应用系统中，一般都是使用存储系统（文件系统和数据库）来保存系统的状态数据，关系数据库进行分布式处理时一般有如下模式：主从模式，主主模式，分片模式。

关系数据库的主从模式是主服务器负责数据的写操作，从服务器负责数据的读操作或专门的数据分析处理。主从模式的情况下，主服务器在进行数据写入操作的同时将操作命令写入到日志文件，从服务器同步获取日志文件进行操作重放将数据写入数据库文件，这样就完成了数据在主从服务器上的数据同步。这种模式下数据只能从主服务器进行数据写入，一旦主服务器故障则整个数据库集群不能提供数据写入服务，从服务器只能提供数据读取服务，因此只提供读操作的高可用。

关系数据库的主主模式是 A 服务器可以从 B 服务器同步日志文件重放写入数据，B 服务器也可以从 A 服务器同步日志文件重放写入数据，但是在任意时刻只能有一台服务器提供数据写入服务而不能同时对两台服务器进行写入操作。当前提供写入操作的服务器宕机后，由另外一台服务器接管相应的操作，从而实现了数据库读写操作的高可用。

主从模式和主主模式实现了负载分摊，增加了一定程度的并发处理能力，也不增加数据的存储能力，并不能实现水平伸缩来线性扩展数据库的并发处理和数据存储的能力。

要实现真正的水平伸缩能力需要使用数据分片处理模式。数据分片需要先选取一个 key，然后根据 key 值的范围将数据映射到不同的服务器上去进行处理存储。数据分片可以采用硬编码的方式进行，直接在应用程序中进行分片逻辑处理选择对应的服务器去处理存储数据。这种方式需要额外分片逻辑处理代码且跟应用逻辑耦合在一起，处理逻辑负载、对应用程序的影响大、维护管理困，不能支持多分片联合查询、数据库事务等，不能进行灵活方便的水平扩容处理。

为了方便的解决硬编码方式存在的问题，可以将数据分片的处理逻辑从应用中完全隔离处理进行专门的处理就形成了分布式数据库中间件（Mycat/cobar)。应用程序连接数据库中间件，将 sql 语句提交过去，中间件对 sql 语句进行解析获取分片 key 及值，根据值进行相应的路由计算处理得到分片服务器的 IP 地址列表，再将 sql 语句提交到真正的分片数据库服务器上去进行处理，然后收集处理的结果返回给客户端，如果是查询处理则对结果集进行合并处理后返回给客户端。

使用数据库中间件进行水平伸缩需要进行预先规划分配一个大的分片数值，比如开始有两台数据库服务器，预先分配 100 个分片，每台服务器分配 50 个分片启动 50 个数据库实例，在需要进行水平扩容时又增加了 2 台服务器，则根据新的服务器进行分片分配（每台新服务器分配 25 个分片），从每台旧服务器上分别迁移 25 个数据库分片的数据到一台新服务器上，然后调整分片配置将对应的 key 值映射到新的服务器上，启动数据库实例完成数据库的水平伸缩。

关系数据库并不是为分布式场景使用来设计的，为了完成水平伸缩而进行的各种分布式处理手段在使用时会受到各种各样的条件限制，使用起来并不方便和顺畅。为了更加原生的支持数据存储的分布式特性，诞生了另外一套存储方案 nosql 数据库。Nosql 实现了更好的分布式处理和更灵活的水平伸缩，但是对一些关系数据库的特性（事务、关联查询等）却并不支持。Nosql 数据库是基于 CAP 和 BASE 理论来设计实现的。

CAP 理论：指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），只可同时满足 CAP 其中两点，无法三者兼顾。

分区容错性（P）：在机器故障、网络故障、机房停电等异常情况仍然能满足可用性。（采用副本方式处理）

一致性（C）：在任意时刻读操作读取到的数据都是上一次写入的数据，在分布式系统中就需要所有数据备份在同一时刻的值是相同的。（所有副本数据一致）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（数据具备高可用性）

在一个分布式系统中，异常情况是一定存在的，因此分区容错性是必须要满足的，所以就必须在 C 和 A 之间去做权衡处理，这个权衡则是通过 BASE 理论来处理的。

BASE 理论：

基本可用（Basically Available）系统在出现不可预知故障时，允许损失部分可用性，如

响应时间上的损失或功能上的损失。

Soft state（弱状态）软状态，指允许系统中的数据存在中间状态，并认为该中间状态的

存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步

的过程存在延时。

Eventually consistent（最终一致性）指系统中所有的数据副本，在经过一段时间的同步

后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达

到一致，而不需要实时保证系统数据的强一致性。

在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，被称作分布式系统脑裂。为了避免脑裂产生，在分布式系统中进行一致性处理的时候，通常是使用一个主节点或者协调节点来进行全局的管理控制，保证同一时刻只能有一台服务器或者一个节点进行数据的写入操作。这也就要求同一时刻只能有一个主节点存在，分布式系统主节点的选择则是通过 ZooKeeper 来管理的。

ZooKeeper 是一个分布式一致性协调处理系统，它基于对 Paxos 算法的实现，保证了分布式环境中数据的强一致性，提供的功能包括：配置维护、统一命名服务、状态同步服务、分布式锁、选主、集群管理等。

Zookeeper 的分布式一致性是基于了 ZAB 协议来实现的，ZAB 协议是在 Paxos 协议及 2PC 算法的基础上进行的设计和延伸。Zab 协议包括两种基本的模式：崩溃恢复模式和消息广播模式。

当整个集群启动过程中，或者当 Leader 服务器出现网络中弄断、崩溃退出或重启等异常时，Zab 协议就会 进入崩溃恢复模式，选举产生新的 Leader。当选举产生了新的 Leader，同时集群中有过半的机器与该 Leader 服务器完成了状态同步（即数据同步）之后，Zab 协议就会退出崩溃恢复模式，进入消息广播模式。ZooKeeper 使用一个单一的主进程（Leader 服务器）来接收并处理客户端的所有事务请求，Leader 服务器负责将一个客户端事务请求转换成一个事务 Proposal（提议），并将该 Proposal 分发给集群中所有

的 Follower 服务器。之后 Leader 服务器需要等待所有 Follower 服务器的反馈，一旦超过半数的服务器（Follower +Leader 服务器）本身进行了正确的反馈后，那么 Leader 就会再次向所有的 Follower 服务器分发 Commit 消息，要求其进行提交。