分布式数据库架构

分布式数据库中间件，例如MyCat.



在分表时的集群的伸缩：

增加新的服务器，需要数据迁移，怎么迁移数据？

• 一个服务器部署多个数据库

• 迁移时把数据库实例移到新增的服务器

• 然后修改路由配置 （一定要数据迁移完了再改）数据不会丢失



NOSQL架构

CAP

Consistency: 每次读取的数据都是最近写入的数据或者返回一个错误，而不是过期数据。

Availability: 每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不保证数据是最近写入的。

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



CAP原理

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



最终一致性

Method to achieve eventual consistency:

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

• 客户端解决冲突 （比如两个购物车，就是合并购物车）

• 投票解决冲突（Cassandra）尝试写入三个节点，等待至少两个节点更新成功。读：尝试从三个节点读取，等待至少两个节点返回，取最新版本。



Cassandra分布式解决方案



HBase

Zookeeper 决定HMaster. HMaster选择一个HRegionServer. HRegionServer存贮数据在HRegion实例(HDFS)



可用性：HRegionServer宕机时，需要分配负责的key到其他Server。一般需要几十分钟。

一致性：key存在一个HRegionServer。非常好。

ACID -> BASE



案例分析：Doris 海量KV Engine

【职场TIP】：如何打动公司的决策者，给你机会？

要先指出当前现状，指出问题，痛点。给老板紧迫感。指出你的方案对公司的好处。

自己争取，当老板有了紧迫感，你又准备好了解决方法，那么你大概率有了这次机会。特别如果这次机会的科技是当红的，收获会很大。



然后提出产品目标，水平最好高于业界但是能力范围可及。



被质疑也是好事，说明你得到了关注。质疑你的人越牛，越有收获。



分布式系统的关键点：

1. 每次请求访问哪一个服务器？数据分区，路由选择。（类似Redis, 根据key计算virtual node,只用配置virtual node到physical node的映射。虚拟节点定下来就是10000，所以就用余数哈希。）

2. 失效情况下可用性：双写保证可用性 （向两个服务器同时写，并行）瞬时失效：重试3次，失败，sleep，再重试。一直失效，就不是瞬时失效。临时失效：Config Server尝试最多3次心跳写入，决定是KV client的问题还是Data server的问题，如果是data server的问题，告知集群。2小时内恢复，恢复后数据和失效前一致。长于2小时，视为永久失效。

3. 集群管理：健康检查，配置抓取

临时失效fail over:

物理节点X有点像binlog的职责。

永久失效fail over:

集群里有空的standby的服务器。Node永久失效了，把完整的数据从fail的node的replicate node拷贝过来，standby的服务器处于恢复期间。但是互相备份的两个物理节点都down了，问题会很大。



TODO：仔细研究Doris



ZooKeeper分布式一致性

分布式集群的脑裂（split brain）：

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

Zookeeper解决了分布式环境的一致性。



Paxos算法：（高频面试题）

三个角色：

Proposer

Acceptor

Learner

https://lamport.azurewebsites.net/pubs/paxos-simple.pdf



ZAB protocol:

Leader宕机之后，需要一些时间重新选举。所以有些时候是不可用的。



• 负载均衡，失效转移

• 分布式锁

• master选举

• 配置管理



服务器越多，写操作需要更多的ACK，所以需要的时间更长。但是读操作哪一台服务器都可以，所以需要的时间会更加短。



TODO： learn more about Paxos.

https://lamport.azurewebsites.net/pubs/paxos-simple.pdf