分布式数据库

主从复制

发展过程

• 一主一从：写主库，读从库

• 一主多从

• 主主复制

• 同一时刻，只有一个主节点和其从节点在响应

• 主主复制的两个数据不能并发写入。否则会出现数据冲突。

• 复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力

• 更新表结构会导致巨大的同步延迟。实践过程中，会关闭表结构的同步操作，由工程师手动执行。

主从复制，主要是为了提高处理高并发请求的能力，但是并没有增加数据的写并发能力和存储能力。

为了提高别并发能力和存储能力，出现了「数据分片」的方案。

数据分片

分批目标：

增加数据的写并发能力和存储能力。

分片原理：

将一张表分成若干片，存在不同的数据库上。比如把一张有 10 亿条数据的表，拆分到 100 台服务器上，每个表里只有 1000 万条。

分片带来的问题：

• 无法联合查询，比如 join 操作

• 无法使用事务

• 增加额外的代码，比如增加服务器后，客户端代码的处理，数据迁移等

为了解决数据分片带来的问题，需要引入分布式数据库中间件，比如 Mycat。中间件负责数据分片的选择，及结果的合并处理。

数据分片的数据迁移：

1. 一开始，就会对一个较大的数字取模，比如 100，生成 100 个数据库连接

2. 比如只有 2 台服务器，每个服务器上启动 50 个数据库实例

3. 有一个映射关系，将 100 个数据库连接映射到 50 个数据库实例

4. 当需要增加服务器时，先把原来数据库实例的数据迁移到新的服务器

5. 然后只需要把对应的连接改到新服务器上即可

这要求，在一开始就要规划好集群的最大规模，定好最大的取模值。

CAP 原理

参考命题作业。

最终一致性

基于 CAP 原理，可能会出现集群中的不同节点在一定时间段内不同节点的数据不一致，但是在网络恢复后，数据最终是一致的。

但是在数据恢复一致之后，如何保证客户端访问数据的一致性？

• 最终一致写冲突：根据时间戳，最总写入覆盖

• 客户端保证：客户端从不同节点读的数据不一致，客户端自己处理

• 投票解决冲突（Cassandra）

对于 Doris 设计的几点疑问：

1. Client 链接 config server，连接失败的话，怎么处理？

2. 故障发生时，日志结点不可用怎么办？

3. 只写不读的过程中，同时从日志结点恢复数据，以下情况是如何处理的？

• 新数据写入：set value = ABC where key = 123。而此时故障节点里这个 key 还没有从日志结点恢复。