如何确保水平分表后的数据一致性？

分布式事务

• 两阶段提交（2PC）：引入协调者，第一阶段，协调者向所有参与者发送事务预提交请求，参与者执行事务操作但不提交；各参与者向协调者反馈执行结果。第二阶段，若所有参与者都反馈成功，协调者发送提交指令，参与者提交事务；若有参与者反馈失败，协调者发送回滚指令，参与者回滚事务。比如电商系统中，订单分表存储，在创建订单涉及多表操作时，通过2PC保证数据一致性。不过它存在单点问题（协调者故障影响全局）、阻塞问题（等待其他参与者响应时资源被占用）。
• 三阶段提交（3PC）：是2PC的改进版，增加了准备阶段。第一阶段，协调者询问参与者能否执行事务，参与者反馈自身状态；第二阶段，协调者根据反馈发送预提交指令，参与者执行事务操作并反馈；第三阶段，协调者根据反馈发送最终提交或回滚指令。它减少了阻塞，但依然不能完全解决分布式系统问题。

异步复制

• 基于消息队列：将分表操作产生的数据变更以消息形式发送到消息队列，消费者从队列获取消息并应用到相应分表。如用户在社交平台发布动态，动态数据水平分表存储，发布操作产生的数据变更消息发送到消息队列，消费者异步处理消息更新各分表。为保证一致性，可采用事务消息机制（如RocketMQ的事务消息），确保消息发送和业务操作的原子性。
• 主从复制：一个主表对应多个从表，主表数据变更后异步复制到从表。在一些读多写少场景适用，如新闻资讯平台文章表水平分表后，主表负责写操作，从表用于读操作，主表数据变更异步同步到从表。要关注复制延迟问题，可通过监控工具监测，必要时调整配置或架构。

应用层处理

• 补偿机制：业务操作失败时，在应用层编写代码进行补偿。如在分表的支付系统中，支付操作涉及多个分表，若部分操作失败，应用层根据日志记录和业务规则执行补偿操作，如退款、回滚库存等。
• 重试机制：操作因网络等临时性问题失败时，应用层自动重试。设置合理重试次数和间隔，如在网络抖动导致分表数据写入失败时，应用层重试写入操作。

定期数据核对

• 对比校验：定期对比分表数据，可采用哈希值对比、全量数据对比等方式。如电商系统定期对订单分表数据进行哈希值计算，对比各表哈希值判断数据是否一致；也可抽取部分数据进行全量对比。
• 对账系统：搭建专门对账系统，按照业务规则对分表数据进行核对。如金融系统通过对账系统每日对账户分表数据进行核对，发现差异及时处理。