分享程序员开发的那些事...
更新时间：2022-08-17 13:56:47
分表的策略就相对简单了，复杂的是迁移方案，在同一个业务领域，对于数据进行分表，无非就是分表规则，场景等。
分表规则很简单，我们根据自己的业务场景，按照人的纬度hash取模的方式来进行分表，这里大家经常会遇到的问题是，将来还需要再继续分的时候怎么办，我们的策略是，目前的分表充分考虑未来的容量，尽量不给将来二次分表的机会；即使不得不做，我们可以采用通用的2分法来做，2分法可以保证在采用新的分表策略时，需要迁移的规模是2分之一；除此之外，还有一种方式，就是数据冷热分级，需要分析用户的行为把用户数据分为冷热数据，冷数据归档起来提供单独处理。有同学可能会问，为什么不优先选择冷热，然后再做分表，个人觉得各有千秋，且看本文第四部分讨论。
读写我们封装了统一的中间层来负责分表规则，这里我们并没有去做SQL解析，来统一处理，原因有二：
表关联确实是个问题，我们的场景是尽量规避表关联，尽量通过数据冗余，空间换时间来做。 如果不得不做，基于场景讨论。
这个是杜绝的，针对分表的所有操作，都需要带着分表主键，如果确实有场景需要进行聚合操作，则根据场景进行异步数据合并，然后操作合并后的数据，而非直接操作原始分表数据。
拆分后
终于到迁移方案了，迁移方案有很多种，有粗暴的，有温柔的，还有无感的（这些词不要想歪了）。
这个很简单，高效，停机，旧数据按照分库、分表规则直接导入到新表中就行，迁移过程中的细节就不说了，无非就是数据备份、数据准备、数据操作、数据验证、业务恢复。
无感大家都很喜欢，也是我们喜欢和选择的，为了能够在基础能力扩充和业务无感上寻找一个平衡，我们花了不少代价，总结下来就是双写、并行、验证、回写、追数据、切换，这几个环节并非严格按照次序，需要根据业务场景及对数据的操作来进行细分：
针对分库的数据，新旧库各写一份，数据操作依然用旧库。 对于分表，采用的是业务隔离，按照一定的条件旧写旧，新写新，新的数据回写到旧表，数据读取依然用旧表。
并行一段时间，保证有足够的时间片内的数据，这个时间根据不同业务的数据热度以及迁移代价来定，太短稳定性有风险，太长有数据压力。
针对并行期间的数据做新旧逻辑验证及数据验证。
针对分表数据，走消息系统回写到旧表中，保证用户能够及时看到数据。
验证并并行一段时间以后，就可以针对旧数据进行迁移了，这个环节由于数据规模比较大，都是在数据库级别的批量操作。
分库业务的切换，要注意数据的时效性，切换到新的服务，分散旧库的压力。 分表的切换会分的更细一些，按照读、写的纬度来切，优先切写到新表，通过数据回写保证能读到，然后切读到新表，最后再停回写。
这两个放在一起是不是有些奇怪，笔者是基于保证数据一致性的手段来考虑这件事情。 通常来说，反查更多用在同步调用上，而消息是异步场景下来用。 两者共同点在于，都需要用幂等机制来保证数据一致性。不同点在于反查时效更高，通常依赖调度，并且系统隔离性较差。 消息系统隔离性较好，但是存在消息无序性和较大延迟。
这两个放一起也是由于解决数据一致性的问题，两者各有千秋，我们选择了开发复杂一些，但是相对灵活一些的方案，针对大数据量、高并发的场景，分布式事务对于我们来说太重了。如果只是单纯的把数据库进行拆分，分布式事务可能更为适合。
读写分离也是分摊系统压力和数据库压力的有效方式，两者不存在谁更好的问题，需要根据面对的业务场景及数据场景，分析数据的读写比作出选择，如果读写比非常高，那么无疑读写分离的效果是非常明显的。
数据归档也是一种常用的策略，根据用户行为的分析业务场景和数据，来降低系统压力，选择依据是数据本身的冷热程度，如果数据冷热分布存在比较大的不均衡，那么归档无疑是比较优先的选择。
并行时间需要根据数据时效要求来做评估，时效要求比较长，那么并行期会比较长，这时建议考虑其它策略。
从直接操作数据库到依赖服务，从同步改为异步，这些对业务流程和数据流程都有非常大的影响，需要评估并做好处理。
方案选择直接影响就是开发复杂度，如果要做无感迁移，复杂度要多非常多，怎么平衡和选择才是关键。
如果应用和外部系统有交互，那么还需要考虑灰度及兼容，以及推动外部迁移的部分，这些就是后话，不在此文之列。