亿级大表分库分表实战总结( 四 ) _分库分表

in的分批查询。如果一个select...in...的查询，数据库中间件会根据分表键，将查询拆分落到对应的物理分表上，相当于原本的一次查询，放大为多次查询。（当然，数据库会将落在同一个分表的id作为一次批量查询，而这是不稳定的合并）

因此，我们需要注意：

业务层面尽量限制in查询数量，避免流量过于放大；
容量评估时，需要考虑这部分放大因素，做适当冗余，另外，后续会提到业务改造上线分批进行，保证可以及时扩容；
分64、128还是256张表有个合理预估，拆得越多，理论上会放大越多，因此不要无谓地分过多的表，根据业务规模做适当估计；
对于映射表的查询，由于存在明显的冷热数据，所以我们又在中间加了一层缓存，减少数据库的压力

3.4.2 分表键的变更方案本项目中，存在一种业务情况会变更字段pk3 ，但是pk3作为分表键，在数据库中间件中是不能修改的，因此，只能在中台中修改对pk3的更新逻辑，采用先删除、后添加的方式。
这里需要注意，删除和添加操作的事务原子性。当然，简单处理也可以通过日志的方式，进行告警和校准。
3.4.3 数据同步一致性问题
我们都知道，数据同步中一个关键点就是（消息）数据的顺序性，如果不能保证接受的数据和产生的数据的顺序严格一致，就有可能因为（消息）数据乱序带来数据覆盖，最终带来不一致问题。
我们自研的数据同步工具底层使用的消息队列是kakfa ，， kafka对于消息的存储，只能做到局部有序性（具体来说是每一个partition的有序）。我们可以把同一主键的消息路由至同一分区，这样一致性一般可以保证。但是，如果存在一对多的关系，就无法保证每一行变更有序，见如下例子。

文章插图

那么需要通过反查数据源获取最新数据保证一致性。
但是，反查也不是“银弹“ ，需要考虑两个问题。
1）如果消息变更来源于读写实例，而反查数据库是查只读实例，那就会存在读写实例延迟导致的数据不一致问题。因此，需要保证消息变更来源和反查数据库的实例是同一个。
2）反查对数据库会带来额外性能开销，需要仔细评估全量时候的影响。
3.4.4 数据实时性问题延迟主要需要注意几方面的问题，并根据业务实际情况做评估和衡量。
1）数据同步平台的秒级延迟
2）如果消息订阅和反查数据库都是落在只读实例上，那么除了上述数据同步平台的秒级延迟，还会有数据库主从同步的延迟
3）宽表到搜索平台的秒级延迟
只有能够满足业务场景的方案，才是合适的方案。
3.4.5 分表后存储容量优化由于数据同步过程中，对于单表而言，不是严格按照递增插入的，因此会产生很多”存储空洞“ ，使得同步完后的存储总量远大于预估的容量。
因此，在新库申请的时候，存储容量多申请50% 。
具体原因可以参考我的这篇文章为什么MySQL分库分表后总存储大小变大了？
3.5 本章小结至此，分库分表的第二阶段告一段落。
这一阶段踩了非常多的坑。
一方面是设计高可用、易扩展的存储架构。在项目进展过程中，也做了多次的修改与讨论，包括mysql数据冗余数量、搜索平台的索引设计、流量放大、分表键修改等问题。
另一方面是“数据同步”本身是一个非常复杂的操作，正如本章最佳实践中提及的实时性、一致性、一对多等问题，需要引起高度重视。
因此，更加依赖于数据校验对最终业务逻辑正确、数据同步正确的检验！
在完成这一阶段后，可以正式进入业务切换的阶段。需要注意的是，数据校验仍然会在下一阶段发挥关键性作用。