事件背景
我们的业务中，有一部分数据需要对外提供查询服务。由于数据量比较大，并且要提供多维度查询的功能，我们将此数据存放到了ElasticSearch搜索系统中。为了提高数据的可靠性，防止数据单点，我们存了一份数据在物理机集群中，由物理机集群提供主要服务。同时也存了一份数据在虚拟机上，拟当物理机出现问题时通过虚拟机提供服务。
值得一提的是，我们这两个备份采用的是完全不同的策略。
对于物理机的数据，我们是通过在业务程序运行过程中，实时更改时通过消息队列的方式推送到ES集群的索引中。而虚拟机的数据，则是通过我们公司自研的数据抽取工具，在数据更新后，即时抽取binlog的方式将数据同步到虚拟机集群中。
业务改造
在以上的背景下，我们在近期的一个版本中，我们对一份存于MySql的业务数据进行分表操作。该业务随着时间增长，其数据量已经达到一个量级，并且考虑到后期还是会不断增长，我们对该数据基于业务主键 OrderNo 进行了hash取模分表，分解成了100张表。
我们的上线策略是
第一步：新建100张分表
第二步：在代码中，对于数据的写入使用双写策略，即同时写入原始大表和分表，而读取操作则通过系统开关控制是读取大表还是分表。同时主动推送搜索系统的队列保持不变。
第三步：版本上线的当天晚上，我们通过定时任务的方式，将原始数据全量按逻辑存入分表中。
第四步：后续一个版本中，改变虚拟机集群抽取数据的数据源为分表。
第二第三步分开是为保证在一条链路稳定以后，再切另外一条链路。确保数据割接的稳定性。保证生产始终存在一条有效服务的链路。
同时我们对于数据保障还提供了诸多的维护工具，比如：
- 主表、分表查询比对页面
- 批量、单条按条件同步页面
- 主表数据推送搜索
- 分表数据推送搜索
这些工具主要是为了防止一旦数据出现问题，随时可以通过这些运维工具，对错误进行修正。
问题的发生和解决
发生
数据改造上线前，我们做了如此多的细致工作，发布前我们还经过了上线策略评审，一切万事俱备，发布当晚，我们很高兴地看到，数据迁移一切正常。业务验证也没有问题。
但是，第二天，产品就收到业务的反馈说，某些数据在前台无法查到。我们要了一条业务的数据，
通过后台查询，看到我们的数据库中是存在的。此时，我们根据业务提供的条件查询了搜索系统。发现物理机的集群上，这条数据不存在，而虚拟机上这条数据是存在的。起初以为是偶然现象，可能是数据通过消息队列推送到物理机集群时丢失了些数据。
幸好我们同步工具，我们通过同步工具将数据同步了一下，告知产品和业务验证，发现数据有了，以为事情结束，问题告一段落。
再次发生
过了没多久，产品又通知我们有一批这样的数据，还是同样的情况。
此时我们就开始怀疑，到底，是不是我们动到了业务中推送搜索这段代码。此时果断考虑需要将服务线路切换到虚拟机提供服务。在跟领导报备后，通过切换开关的方式，将业务查询切换到虚拟机，业务上恢复正常。
排查问题
此时我们开始进行一步步地问题排查的过程。
首先我们分两路来代码上是否有变化
看业务代码，发现我们的业务代码除了数据源上的改动，根本没有动过将数据发送搜索系统这段逻辑。经过多个开发人员反复确认，的确没有变化。
看搜索系统的同步存储代码，由于业务上对搜索系统本身没有改造，其实很明确的知道当前这个版本是没有改动的，这时只能细细查看是否有未知的Bug。反复确认后，认为没有问题。
经过前面俩个步骤的定位，没有找到问题所在。我们又将目光投向消息中间件平台，经过了解，消息平台表示没有发生平台性的问题，也没有遇到过我们这样的情况。
再将目光转向日志，我们后台打开debug日志后，查看，所有数据都是收到的，并且也是经过处理的。
因此给我们的结论是，我们的数据没有丢失？
矛盾
现状：我们的数据丢失了
结论：我们的数据没有丢失
客官：您认为还有什么可能。
再次排查
此时我们从这次改造本身去考虑问题，这次改造的是数据，当数据从一个表分解到100个表中去了以后，有什么变化？
从业务上讲，业务数据是没有变化的。
唯一变化的是数据的自增主键
此时，我们的小伙伴从代码中看出了端倪，在物理机的同步程序中，所有的数据是根据表的主键ID进行更新的。在原表中，主键ID的自增值已经到了500W，而分表以后，自增主键每个表中最大值也才4W多。也就是 我们的数据被覆盖了，当数据分布到各个分表中了以后，我们的唯一主键就不再是表的ID了。继续使用数据库ID进行数据更新，则产生的数据会因为主键ID的问题被相互覆盖。
我们在测试环境中已验证，果然没错。
解决问题
找到了问题，我们便知道该怎么做了。
我们修改了同步数据逻辑中的更新条件，改成了根据业务唯一主键 OrderNo进行更新。同时，将被覆盖的数据进行了一次定量的更新。最后，问题得以解决
总结
这次的问题发生的很出乎意料，但分析下来，这个问题也是必然的，在系统开发过程中，某些点没有想到，就一定会发生一些问题。作为开发，我们不要害怕发生问题，当问题发现以后，要迅速响应和及时解决。好在这次问题的发生和解决，没有带来很大的影响，还是归功于，我们在系统设计过程中，对于未知的风险做了足够的应对方案。
物理机和虚拟机的双备份方案，保证了业务上任何时候都不至于不可用。
两种同步方案使用不同的数据源，分先后两个版本切，保证在一个方案有问题的情况下，第二个方案仍然可用。
遇到问题时及时地切换，保证业务不受影响。
就事论事：在有可能会分库分表的业务中，一旦分库分表以后，自增id就不再是该数据的唯一主键。必须有一个全局性的唯一主键才行。
