Tyler 的个人博客

今天分享一个最近在业务开发中涉及使用到的很巧妙的小tip。

业务背景是有一张记录后台的DB主表，数据量达到百万级别。后台会涉及到一些字段筛选等，所以如果每次查询直接走DB的话会效率较慢。于是该业务采用的是当有用户或者后台运营进行数据变更时通过消息队列及时将DB变化及时同步至ES。此刻有一个新的业务后台开发，数据是从该百万级别数据量的DB中获取，某个字段符合一定条件时同步至该表，且主表信息变更需要同步至副表。

对于这样的需求，最简单暴力的解决方式就是可以通过定时脚本去进行数据同步，但是这样的方法有点太low啦。因为需要脚本启动之后才会进行数据更新，实时性很差。而且数据库数据量较大，每次全量查询影响性能。

那如果在所有涉及主表记录变更业务触发时，进行副表数据同步呢？当然，这也不是最优解。首先，对于这样庞大数据量的表，其字段和涉及业务也是众多的，你需要去穷尽所有对该表有影响的业务，并且去在每个业务中，增加同步新后台，很容易遗漏；其次，如果过了一段时间，又有新的业务后台也需要同步这张主表数据呢？并且随着后续该表相关业务的累加，很难保证后续的业务开发人员，在触及到主表字段修改的相关业务，或者同步该主表到另外一张新表时，能够完全对所有历史业务同样做增改。比如这次开发的新后台A，已经完美的在每一个主表字段改动处增加上了新表的数据同步，但是后续别人开发相关修改字段新需求时，并不知道有一个后台A这样的业务背景，就会导致数据的紊乱。

因此，我们不妨借用Kafka这样的工具。当主表有数据变更时，现有的业务会自动发送Kafka，并且有消费者实时去监听，将DB变更同步至ES。那么为了能实现主副表同步的同时，不影响ES数据的同步，我们可以再新起一个消费者去监听这个主表消息变更的topic。当有字段变更时，监听到Kafka消息，我们可以在这样的时机去进行主副表的数据同步。这样的方式不仅便于后期维护，而且也不影响其他历史业务。

更重要的是，业务的可拓展性也比较高。假设后期又有新的类似同步数据需求，我们都可以单独启动一个专属的消费者，首先根据业务背景对同步落表条件字段进行判断，若该字段不符合同步条件，则直接commit即可。大大节省了开销，且不容易出错。