分布式数据库

数据分片

• 分片目标

• 将单表数据量很大的表拆分为不同物理机上的多个表

• 分片特点

• 分片后，数据库的压力被多个分片分摊了，查询写入的效率就会高很多

• 分片原理

• 通过业务上去定义路由规则，根据路由规则来读写数据

数据分片的挑战

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

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

• 无法使用数据库的事务

• 随着数据增长，怎么增加更多的服务器

分布式数据库中间件

MyCat

特征：

• 遵守Mysql原生协议，跨语言，跨数据库的通用中间件代理。

• 基于心跳的自动故障切换，支持读写分离，支持 MySQL 一双主多从，以及一主多从

• 有效管理数据源连接，基于数据分库，而不是分表的模式。

• 基于 NIO 实现，有效管理线程，高并发问题。

• 支持数据的多片自动路由与聚合，支持 sum , count , max 等常用的聚合函数。

• 支持2表 join，甚至基于 caltlet 的多表 join。

• 支持通过全局表，ER 关系的分片策略，实现了高效的多表 join 查询。

• 支持多租户方案。

• 支持分布式事务（弱xa）

• 支持全局序列号，解决分布式下的主键生成问题。

• 分片规则丰富，插件化开发，易于扩展。

• 集群基于 ZooKeeper 管理，在线升级，扩容，智能优化，大数据处理（2.0开发版）。

Amoeba/Cobar

Cobar的分布式主要是通过将表放入不同的库来实现：

• 支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分

• 支持将不同的表放入不同的库

• 多数情况下，用户会将以上两种方式混合使用。



Cobar的功能约束：

• 不支持跨库情况下的join、分页、排序、子查询操作。

• SELECT 语句执行会被忽略，事务和字符集设置除外。

• 分库情况下，insert 语句必须包含拆分字段列名。

• 分库情况下，update 语句不能更新拆分字段的值。

• 不支持 SAVEPOINT 操作。

• 暂时只支持 MySQL数据节点。

集群伸缩



Nosql

CAP原理

概述：

• 一致性（Consistency）：每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据，也就是说，数据是一致性的。

• 可用性（Availability）: 每次请求都应该得到一个响应，而不是返回一个错误获取失去响应，不过这个响应不必保证数据是最近写入的。也就是说系统需要一直都是可以使用的，不会引起调用者的异常，但是不保证数据是最新的

• 分区耐受性 (Partition tolerance) : 即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然是可以操作的。



分析：

当网络分区失效的时候，要么取消操作保证数据的一致性，但是系统不可用了；要么继续写入数据，但是数据的一致性就得不到保证了。

对于分布式系统而言，网络失效一定会发生，所以分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一了。

所以，关于CAP原理，准确来说，在分布式系统中必须满足分区耐受性的前提下，可用性和一致性不能同时满足。

数据一致性冲突

在更新数据的时候，节点失效了，导致一致性冲突

最终一致性

服务器之间采用异步扩散，过程中可能存在数据不一致，但是是最终一致性的。

最终一致性写冲突

简单冲突处理策略：通过时间戳，最后写入覆盖

客户端冲突解决

通过合并数据来解决。

投票解决冲突

在客户端写入数据的时候，必须得到大部分数据节点返回响应更新成功才能写入成功。

Cassandra 分布式解决方案

客户端连接任一节点通过投票一致性级别写入数据，被选中节点计算数据分区范围，然后发送给对应节点存储。



Hbase 架构



ACID与BASE

ACID

• 原子性（Atomicty）: 事务要么全部成功，要么全部取消。如果事务崩溃，状态回滚到事务之前

• 隔离性（Isolation）: 如果两个事务T1,T2同时运行，那么它们的最终结果是相同的，不管谁先结束。隔离性一般通过锁实现

• 持久性（Durability）:一旦事务提交，不管发生什么（崩溃或出错 ），数据要保存在数据库中

• 一致性（Consistency）：只有合法的数据才能写入到数据库中



BASE

• 基本可用（Basically Available）：系统在出现不可预知故障时，允许损失部分可用性，如响应时间上、部分功能上的损失

• 弱状态/软状态（Soft state）:允许系统中的数据存在中间状态，并认为该中间状态不影响系统的整体可用性，即允许系统在不同节点上的数据副本之间进行数据同步的过程存在延时。

• 最终一致性 （Eventually consistent） : 系统中所有的数据副本，在经过一段时间的同步后，最终能达到一致性的状态，它不需要系统保证数据实时一致性

分布式一致ZooKeeper

分布式系统脑裂

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

数据库主主备份

将数据库主节点注册到ZooKeeper来完成主主备份



分布式一致性算法 Paxos

三个角色：Proposer、Acceptor、Learner



第一阶段：Proposer阶段。Proposer想Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺



第二阶段：Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。



第三阶段：Learn阶段。Proposer在收到了多数的Acceptors的Accept之后，标记着本次Accept成功，决议形成，将形成的决议发送给所有的Learns。



Proposer生成全局唯一且递增的Proposal ID （可使用时间戳加Server ID）,向所有Acceptors发送Prepare请求,这里无需携带提案内容，只携带Proposal ID即可。Acceptors收到Prepare和Propose请求后：

1. 不再接受Proposal ID小于当前请求的Prepare请求

2. ‍不再接受Proposal ID小于当前请求的Propose请求

ZooKeeper架构



Zab协议

概述：

ZAB 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。



ZAB协议运行过程中，所有的客户端更新都发往Leader，Leader写入本地日志后再复制到所有的Follower节点。



一旦Leader节点故障无法工作，ZAB协议能够自动从Follower节点中重新选择出一个合适的替代者，这个过程被称为选主，选主也是ZAB协议中最为重要和复杂的过程。

选主时机

• 节点启动时：每个节点启动的时候状态都是LOOKING，处于观望状态，接下来就是要进行选主了。

• Leader节点异常时：Leader节点运行后会周期性地向Follower发送心跳信息（称之为ping），如果一个Follower未收到Leader节点的心跳信息，Follower节点的状态会从FOLLOWING转变为LOOKING

• 多数Follower节点异常：Leader节点也会检测Follower节点的状态，如果多数Follower节点不再响应Leader节点（可能是Leader节点与Follower节点之间产生了网络分区），那么Leader节点可能此时也不再是合法的Leader了，也必须要进行一次新的选主。

• Leader节点启动时会接收Follower的主动连接请求，对于每一个Follower的新连接，Leader会创建一个LearnerHandler对象来处理与该Follower的消息通信。

Doris

概述：

Doris(https://github.com/itisaid/Doris)是一个海量分布式 KV 存储系统，支持中等规模高可用可伸缩的KV存储集群。跟主流的NoSQL 系统 HBase 相比较 (Doris0.1 VS HBase0.90)，Doris 具有相似的性能和线性伸缩能力，并具有更好的可 用性以及更友好的图形用户管理界面。



Doris系统架构图



系统整体上可分为三个部分

• 应用程序服务器:它们是存储系统的客户，对系统发起数据操作请求。 

• 数据存储服务器:存储系统的核心，负责存储数据、响应应用服务器的数据操作请求。 

• 管理中心服务器:这是一个由两台机器组成的主-主热备的小规模服务器集群，主要负责集群管理，对数据存储集群进行健康心跳检测;集群扩容、故障恢 复管理;对应用程序服务器提供集群地址配置信息服务等。

分布式存储系统的故障分类:

• 瞬时故障:引起这类故障的主要原因是网络通讯瞬时中断;服务器内存垃圾回收 或后台线程繁忙停止数据访问操作响应。其特点是故障时间短，在秒级甚至毫 秒级系统即可自行恢复正常响应。

• 临时故障:引起这类故障的主要原因是交换机宕机、网卡松动等导致的网络通讯 中断;系统升级、停机维护等一般运维活动引起的服务关闭;内存损坏、CPU 过热等硬件原因导致的服务器宕机;这类故障的主要特点是需要人工干预(更 换硬件、重启机器等)才能恢复正常。通常持续时间需要几十分钟甚至几小时。 故障时间可分为两个阶段:临时故障期间，临时故障恢复期间。

• 永久故障:引起这类故障主要原因只有一个:硬盘损坏，数据丢失。虽然损坏硬 盘和损坏内存一样，可以通过更换硬盘来重新启动机器，但是丢失的数据却永 远找不回来，因此其处理策略也和前面两种故障完全不同，恢复系统到正常状 态也需要更长的时间。故障时间可分为两个阶段:永久故障期间，永久故障恢 复期间。



分布式存储系统故障高可用解决方案：

• 瞬时故障：瞬时故障是一种严重性较低的故障，一般系统经过较短暂的时间即可自行恢复，遇到瞬时故障，只需要经过多次重试，就可以重新连接到服务器，正常访问。如果应用多次重试后，仍然失败，那么有可能不是瞬时故障，而是更严重的临时故障，这时候需要执行临时故障处理策略。 当然也有可能是应用服务器自己的故障，比如系统文件句柄用光导致连接不能建立等，这时候需要请求管理中心服务器进行故障仲裁，以判定故障种类。

• 临时故障：临时故障要比瞬时故障严重，系统需要人工干预才能恢复正常，在故障服务器未能 恢复正常前，系统也必须保证高可用。由于数据有多份拷贝，因此读数据的时候只需要 路由选择正常服务的机器即可;写数据的时候，正常服务的机器依然正常写入，发生故 障的机器需要将数据写入到临时存储服务器，等待故障服务器恢复正常后再将临时服务 器中的数据迁移到该机器，整个集群就恢复正常了。

• 永久故障：永久故障是指服务器上的数据永久丢失，不能恢复。由于故障服务器上的数据永久丢失，从临时服务器迁移数据就没有意义，必须要从其他序列中正常的服务器中拷贝全 部数据才能恢复正常状态。永久故障发生期间，由于系统无法判断该故障时临时故障还是永久故障，因此系统 访问结构和临时故障一样。当系统出现临时故障超时(超过设定时间临时故障服务器仍 旧没有启动)或者人工确认为永久故障，系统启用备用服务器替代原来永久失效的服务 器，进入永久故障恢复。