一主多从，主从同步，读写分离数据库架构
本质是对数据的全量复制冗余，适用于读多写少的大部分业务场景，而且这种架构不仅适用于数据库，其他IO场景也能使用。
- 多个从库提供读服务，线性提升读数据的性能。
- 因为读写不在同一个库上发生，就没有读写锁的存在，提升写数据的性能，本质是扩展独立的IO服务数量（设备数）减少IO竞争。
- 全量复制也增加了高可用。
这里可以延伸下，数据IO的共享，就会牵涉到并发吞吐能力，就会牵涉到竞争和锁，就会影响性能。在这里提供性能，就是通过水平扩展IO的能力方式之一。
全量复制数据相比增量复制数据，增加了同步数据复杂性，但也更加提高了读性能。
水平切分
分库优于分表，分表还是在一个数据库文件上分享IO，还是存在IO竞争；而且分库能够方便迁移到不同的数据库服务器上，扩展性更好。（第1点也是一主多从解决的痛点，第2点则是数据库关于库和表2种粒度的特性决定）
分片的问题在于每片的部分数据之间不能紧耦合。（紧耦合带来的问题就是需要请求2次增加了RT，还要做额外的聚合计算，这个也是数据库特性导致，关系数据库原生的关系计算只适用于一张库的全量表上）
水平切分最大的问题是针对非切分字段的条件查询需要遍历所有库，影响性能。
数据库查询分为点查询（通常用户端发起）和 批量分页查询（通常运营端发起）。
2.1 点查询解决非切分字段思路：
- 建立非切分字段和切分字段的索引表，先通过索引表查询到映射的切分字段，再定位相应库的位置。索引表可以根据字段数据量决定单库还是分库。缺点在于多一次查询。
- 在非切分字段上加工生成切分字段（目前系统就是采用这种方式，但不是所有非切分字段都适用）。
2.2 批量分页查询解决思路：
批量分页查询特点：访问计算量大，返回数据量大，占用数据库性能高。另外，运营端查询维度各式各样，往往要建各种索引，影响用户端写数据的性能。
避免低效批量查询引发用户端查询抖动，另外创建备库，运营端查询对于数据实时性要求较低，可以通过消息或者线下方式异步同步数据，不影响热点前端业务流程。
如果数据量非常大，复制数据成本过高，关系型数据库查询性能无法满足需求，可以考虑外置索引elasticSearch，或者大数据处理hive。
水平切分解决了最大的痛点就是单库容量的问题，同一主多从的线性提升读性能基础上，水平切分线性提升了写的性能。（很好理解，因为独立IO数增加了；但是因为不是全量数据，所以所谓的线性提升也仅仅是读写不同分片的数据场景，这点还是不如一主多从的读。至于单机瓶颈是因为时代技术原因所限，和设计无关）
常见的水平切分算法有“范围法”和“哈希法”。
范围法优点：扩容简单。
范围法缺点：切分字段要满足递增；数据分布不均匀，同时导致了请求分布不均匀。
哈希法的优缺点和范围法正好相反。
4.1 哈希法最佳实践：基因法 （分库基因 % 分库库数）
在一对多场景下，一个批次对应多笔订单。先通过批次号最后4个bit决定落地到哪个数据库的批次表里，此时分库基因就是这4个bit。在生成订单号的时候，先生成除最后4位的前几位，将分库基因加到最后4位bit，使用相同的切分算法就能落到和批次表同一个数据库里了。
上述场景必须先外部批次号生成，外部订单号才能生成；反过来根据订单号确定分库基因有些麻烦。
垂直切分
热点小字段和长尾大字段分开切分，保证数据库缓存能够存储更多的热点数据，增减缓存命中率。适用于特殊的业务表。
