总结



本周继续分布式系统架构的话题，涵盖分布式数据库（MySQL）和NoSQL（Cassadra，HBase），最后以Doris为例讨论了海量分布式KV存储的技术点。



分布式数据库



复制



MySQL主从复制



MySQL的主从复制是将binlog 从主服务器同步到从服务器的relay log， 然后从服务器再重做，使得主从同步。从原理上看，从服务器只能读而不能写。



优点



• 读写分离

• 专机专用

• 便于冷备



缺点



• 只有一个主，容易单点失效

• 可能有同步延时



MySQL主主复制



MySQL的主主复制实现方式是主从之间双向binlog和relay log同步。



1. 主1/2写入binlog，并同步到主2/1的relay log

2. 主2/1重做relay log



两个主不能同时写。在切换时，可能有短时间数据丢失或不同步。



优点



• 避免了写单点



缺点



• 不能并发写入

• 增加了同步延时



数据分片



复制并没有增加存储能力。数据分片正是为了实现存储的水平扩展——更多的机器带来更多的存储。



硬编码数据分片



应用程序中按某一个或多个维度实现硬编码数据分片。应用程序中实现数据分片路由算法。



映射表



应用程序中使用映射表而不是算法路由。映射表一般更灵活，但是对海量数据任然是个极大的负担。



挑战



数据分片一般会导致额外代码和复杂的处理逻辑，并且基本无法直接使用数据库的原生联合查询与事务。



分布式数据库中间件



中间件负责原应用中要硬编码的分片路由，连接池等职责，简化应用开发。可以分为客户端中间件和独立的中间件服务器两种方式。



数据库部署方案



• 单一服务器

• 一主多从

• 分业务的一主多从

• 分业务的一主多从和数据分片



NoSQL



CAP原理



分布式系统中一致性，可用性和分区容忍性三者不可能同时兼得，在必需分区容忍性的前提下，一致性与可用性只能二选其一。



一致性



从系统中读数据，要么返回最近一次写入的数据，要么返回一个错误，不能返回过期脏数据。



可用性



系统必须可读写，不能返回错误或不响应，但返回的数据不必是最近写入的数据，可以是过期脏数据。



分区容忍性



即使因网络原因，部分服务器节点间的消息延迟或丢失，系统任然可操作。



证明



一个分布式系统肯定会出现网络分区，任何网络的抖动和终端都可以造成节点间的通信延时和数据丢失，网络总是不可靠的，所有只能接受分区容忍性。因此，在出现分区后，只能在一致性和可用性之间二选一。因为，选择一致性，只能有一个分区是主，接受读写，而其他的分区不能再接受读写以免返回过期数据；选择可用性，那数据无法在节点间同步，于是部分分区是最新数据，而其他是过期数据，这就造成不一致了。总之，在分区存在的前提下，一致性和可用性的矛盾使得只有一个可以成立。



一个重要的事实是，并不是牺牲一个就自动获取另一个。就是说，不是所放弃一致性，就自然有可用性，或者放弃可用性就自动获得一致性。相反，常常是一荣俱荣的关系，都比较好，或都不好，只是不能同时全部完美。



冲突解决



CAP原理下，为保证一致性，常常要解决数据冲突。常见方式有两种。



数据冗余



数据写入时同时写入多个节点，当部分节点不可用时，采信多数节点的数据。



最终一致



数据通过消息队列，relay log，客户端合并等达到最终一致。



ZooKeeper



脑裂



在分布式系统中，服务器间的冲突会导致脑裂，即出现分区并各自决策，保持不一致无法调和。



共识算法



共识算法保证分布式系统中的服务器可以达成一致的共识，即对同一个请求给出相同的返回值。最初，也是唯一经数学证明的共识算法是Paxos算法，以及原作者在微软完成的Fast Paxos。后来相继出现了Raft和ZAB算法，是对Paxos的简化，经多年实践检验可行，但没有数学证明。另一共识算法，就是区块链用的POW共识算法，但是POW是去中心化的算法，要极大代价。



Paxos



也成为三阶段共识算法，在分布式系统中解决拜占庭将军问题，即在节点通信可能出现重复，丢失，和篡改的条件下达成共识。Paxos算法中弱化了篡改条件，即通信可能重复和丢失，但不会被篡改。



1. 发起者提出提案

2. 多数决策者接受提案

3. 确认，并强制所有学习者接受提案



Raft



三状态机共识算法。任何一个节点总是flower, candidate, leader三者之一。leader负责发送心跳，当follow一段时间没有收到心跳就转换成candidate，然后发起提案，当收到多数确认后转成leader，或是选取更高编号的节点做新leader，自己转成follower。



ZAB



ZooKeeper的共识算法。leader发起提案，follower入队并应答，若多数同意，leader就要求commit，而follower收到commit后，只有ID是等待队列中最小一个时才执行，不然就入队并等待条件成立。



作业



CAP原理



见前面CAP原理一节



Doris临时失效处理