架构师训练营 第六周 总结

分布式数据库



数据分片

当单表存储数据量、写压力过大时，数据分片是提高写处理速度的有效手段。而由于逻辑上一张表的数据在数据分片后分布在不同数据库实例上，会带来额外的挑战，如：

• 需要大量额外代码、处理逻辑更加复杂

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

• 无法使用数据库的事务

• 随着数据的增长，需考虑如何增加更多服务器



有3种实现数据分片的方式

1. 硬编码实现数据分片：优点是简单、缺点是应用代码变复杂，难以扩展

2. 映射表外部存储：将映射关系存储在外部存储上，但是映射关系随着数据量的增多而变得难以维护，同时难以实现数据库实例伸缩

3. 分布式数据库中间件：由中间件负责数据分片，应用不需要实现数据分片的逻辑，可以更好地实现集群的伸缩



数据库伸缩

对于一个分布式数据库，需要考虑的核心问题是数据路由以及数据库集群的伸缩问题，实践中数据库集群的伸缩常见方式：一是考虑数据迁移，使得数据分布更加均衡，二是可以考虑通过余数取模将数据分片在固定数量的数据库实例上，通过增加服务器，将原先一台服务器上的多个数据库实例迁移到新服务器上，实现分布式数据库的扩容。







数据库部署方案

通常由最简单的单一数据库方案开始，当数据规模变大后，首先可以先通过主从复制实现读写分离和高可用。当单库无法满足数据要求时，根据业务处理分库分表。当某些业务数据量激增时，可以考虑对这个业务数据库做数据分片。



NoSQL

CAP原理



CAP分别指：

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

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

• 分区耐受性（Partition tolerance）：因为网络原因，部分服务器节点之间消息丢失或者延迟，系统仍然可以操作。



CAP原理是说在分布式系统必须要满足分区耐受性（P）的前提下，可用性（A）和一致性（C）无法同时满足，原因是：

• 当发生网络分区时，如果不再更新数据，那么数据就是一致的，但是系统不可用；如果继续写入数据，则数据的一致性无法得到保证

• 对于一个分布式系统，网络失效一定会发生，也就是说分区耐受性必须要保证，则可用性和一致性就必须二选一

• 当发生网络分区时，如果选择一致性，那么系统可能返回错误或者超时，系统不可用；如果选择可用性，那么系统总是可以返回数据，但是不能保证返回的数据是最新的。



在选择可用性时，通常考虑实现最终一致性，在发生最终一致性写冲突时，常见的解决方法有：

1. 简单冲突处理策略：如根据时间戳，最后写入的直接覆盖

2. 通过客户端冲突解决

3. 通过投票解决冲突