分布式数据库

主主复制

提高了写的高可用,而不是高并发能力.

当单表太大,或有并发写操作需求时,就改分片了.

分片

一个服务器存一片.分片之后SQL可不要再用JOIN了,靠应用程序了.

1) 硬编码数据分片

然而太硬了,而且规模太大时,不好管理.

2)映射表分片

比硬编码灵活,然而实际使用不多,因为需要额外查询映射表,以及一个用户可以对应多个分片造成潜在的不一致性.

3)分布式数据库中间件

于是出现了系统级的中间件,核心是路由算法.

实现了更多的分片方式,比如按字段分片,以cobar为例 .





扩容

当增加数据库服务器时,跟分布式缓存的情况不一样. - 不能丢数据,因此需要把现有的数据迁移到新服务器.

然后如此多服务器,更不用说数据一直在实时增加,如何搬最省事省力?

因此实际应用中,使用hase取模规则时,按数据库实例分片.

这样,只需要把几个数据库实例迁移到新服务器,然后更改下对应的数据库URL配置(如上defaultpools).

当然,要在迁移完成(主从数据一致)后才改配置,再删除原来服务器的数据库.要快要稳的话,不如就先停用相关上层应用程序.

但是如果系统新增的数据库实例改如何??? 所以一开始就要想好容量规划.

架构演化

1)读写分离

2)业务分离

3)业务分库 (最理想的情况一个服务器一张表)

4)主主复制/数据分片

可根据业务实际情况,进行混合部署.

CAP

就是三种特性,无法全部同时满足.

无处不在.

所以只好根据实际需要,择二,利用解决冲突的艺术,曲线救国,让用户感知不到背后的这些挣扎.

比如引入了"最终一致性"的概念.就是等一等系统恢复及同步处理,最终选择一个值. 用户会觉得慢吗?

比如投票解决冲突(cassandra).用户(客户端)从多个节点读数据,以多数节点的值为准.但这不会造成网络过度负载吗?读写都需要路由算法选出三个节点进行通信

一致性

要么对的数据要么没有



可用性

请求则一定返回数据值,不管对错.

分区耐受性

网络异常时,要么不返回值(只满足一致性),要么随意返回一个值(只满足可用性).

然而网络通信是不可能100%没问题的.







HBASE

HMASTER挂了怎么办?

靠zookeeper,还可以避免脑裂.

HRegion挂了,也不怕数据丢失,毕竟HFILE被复制在不同的服务器上.

每个key只会用一个HRegionServer.

HFile使用LSM,只能增加数据不能修改已有数据??!这样底层跟区块链有什么区别???? 不会太耗费存储空间吗??

也因此,写得快,查老数据的话慢.





DORIS

ACID与BASE





分布式系统的核心-路由算法

一种一致性哈希算法

Paxos及其简化版本

同一个服务器可以同事拥有以下三个角色.

Proposer - 发送prepareq请求.当收到的promise达成集群一致时,通知Learner

Acceptor - 超过50%的Acceptor接受来着Proposer的prepare请求,返回promise.

Learner - 接收propose.



节点失效

瞬时失效 - 几秒,可以通通重复请求或等待解决

临时失效 - 可由客户端发现,但一定由管理中心仲裁(主备),恢复方法如下图.

永久失效 - 2小时还不恢复的临时失效(时长可配置). 增加新节点,然后scp数据.如下二,三图.





脑裂

因数据不一致导致的整个分布式系统的奔溃,称为脑裂.

问题比解决方案重要

Zookeepr

许多关于一致性的经典设计