分布式数据库
主从复制和读写分离
数据库分库分表
分库有两种模式
垂直拆库：电商库 MallDB，业务拆分后就是 UserDB、OrderDB、PayDB 等。
分片拆库：用户库 UserDB，分片库后就是 UserDB_0、UserDB_1、UserDB_xx。
分表也有两种模式
垂直拆分：订单表 OrderTable，拆分后就是 OrderTable 以及 OrderExtTable。
水平拆分：订单表 OrderTable，拆分后就是 OrderTable_0、 OrderTable_xxx。
分库分表适用场景
1. 什么场景分表？
当出现以下三种情况的时候，我们需要考虑分表：
单表的数据量过大。
单表存在较高的写入场景，可能引发行锁竞争。
当表中包含大量的 TEXT、LONGTEXT 或 BLOB 等大字段。
2. 什么场景分库？
当出现以下两种情况时，我们需要考虑通过分库来将数据分散到多个数据库实例上，以提升整体系统的性能：
当单个数据库支持的连接数已经不足以满足客户端需求。
数据量已经超过单个数据库实例的处理能力。
3. 什么场景分库分表？
当出现以下两种场景下，需要进行分库又分表：高并发写入和海量数据：
高并发写入场景：当应用面临高并发的写入请求时，单一数据库可能无法满足写入压力，此时可以将数据按照一定规则拆分到多个数据库中，每个数据库处理部分数据的写入请求，从而提高写入性能。
海量数据场景：随着数据量的不断增加，单一数据库的存储和查询性能可能逐渐下降。此时，可以将数据按照一定的规则拆分到多个表中，每个表存储部分数据，从而分散数据的存储压力，提高查询性能。
分库分表框架:
MyCat：https://gitee.com/MycatOne/Mycat2
ShardingSphere：https://shardingsphere.apache.org
分库分表设计
分片键和分库分表算法
1. 如何选择分片键？
数据均匀性：分片键应该保证数据的均匀分布在各个分片上，避免出现热点数据集中在某个分片上的情况。
业务关联性：分片键应该与业务关联紧密，这样可以避免跨分片查询和跨库事务的复杂性。
数据不可变：一旦选择了分片键，它应该是不可变的，不能随着业务的变化而频繁修改。
2. 分库分表算法？
分库分表的算法会根据业务的不同而变化，并没有固定算法。在业界里用的比较多的有两种：
HashMod：通过对分片键进行哈希取模的分片算法。
时间范围： 基于时间范围分片算法。