开篇吐槽
在做搜索的过程中，最痛苦的从来都不是和全文索引，和什么solr/elasticsearch之间的战斗。其实对于大多数问题来说，当个“谷歌工程师”完全能应付平时的工作需求。常规的错误直接贴谷歌框一查基本就心里有数了，API怎么用贴谷歌框看一眼也基本清楚。但是最为头疼和麻烦的事还是数据同步这个问题。
问题背景
通常情况下，业务数据的落地方式一般会选择关系型数据库，比如mysql，oracle等产品。此类产品经过了长久的时间考验，在容灾，主从，性能，安全等等方面都有着非常全面的解决方案。简单的说，很难有前人没有遇到过的场景，解决不了的问题了。
但是毕竟关系型数据库有着局限性，在设计的初衷上就不是为了解决全文搜索这种场景，此时需要像solr/elasticsearch这样的lucene衍生产品来解决此类问题。像这两种产品，某种意义上，他们就是“非关系型数据库”。和关系型数据库的行式存储不同，主要是以列式存储的方式来存储，在字段为空的时候不会占用空间，牺牲高一致性，换取获得可用性或可靠性。
啰啰嗦嗦一大堆，其实就是为了说明，大部分站内搜索的构建，都是需要面对mysql(oracle,postgres)->lucene(solr,elasticsearch)这样一个过程。那么问题就来了：
怎么能保证两边介质的数据一致性？
没有现成的解决方案可以解决一次性完成这个过程的方案。在过去的经验中主要的解决方案主要如下
- 实时数据：服务端将埋点日志写入kafka队列中，由进程一消费队列后的数据并写入mongo做为索引库备份，再由进程二定时将数据写入elasticsearch
-
历史数据： 编写程序一次性读取所有mysql库数据后写入elasticsearch，数据mapping自定义_id，id相同的情况下会覆盖。
如下图所示：
问题描述
这么做目前会带来几个很难解决的问题：
- 数据丢失：数据流向经过了多个环节，完全一致几乎是不可能的，比如在更新时候数据的补录，比如kafka本身数据遗失，一小部分数据丢失是难以避免的。
- 数据不一致：数据依赖服务端的埋点，而埋点无法涵盖所有的情况，比如服务端有“创建内容”的埋点，但是可能没有“修改内容”的埋点，时间一长，数据开始出现对不上的情况。
- 沟通困难：在上面的问题也说了，依赖服务端。但是部门之间的沟通问题本来就不是特别容易的事情，大家互相之间的排期也不一致，说白了产生依赖这种事情本身就是程序员尽量想要避免的状态。
新的方案
针对上面所提到的痛点，现在开始重新梳理业务，用新的方案来代替老的这一套数据同步方案。
首先要提到的是一个新的产品，叫做canal
当前搜索/推荐场景下增量数据均由前端业务端手工触发，其实现原理是当有更新数据到来，先更新主库（MySQL）然后发给后端业务端Kafka。随着后端业务端对增量消费需求的增加，会造成前端业务逻辑非常复杂，容易造成中间环节消息无故丢失，从而给后端搜索/推荐业务造成数据不同步等一系列问题。
2010年开始，阿里公司开始逐步尝试基于数据库日志解析来捕获增量事件/数据，由此衍生出了增量订阅/消费的业务。
简单的说，这是一个可以监控mysql库的curd事件（增删改查），监控事件来自于哪个库和哪张表，并由事件触发消息的产品。也就是说，我们转变了思路，直接对mysql数据库进行监控。将解析mysql的binlog后的结果封装成约定格式的消息生产到kafka队列，然后再写入mongo和elasticsearch。
这样的一个方案优点在于化被动为主动，由我主动去监控我需要使用的库表字段，通过触发类型的机制来反馈给索引，对于以上的三个问题来说都得到了比较好的解决。比如数据不一致的情况，原本需要通过和服务端沟通埋点的增加，还需要跟随服务端的版本上线。当主动去监控mysql数据的时候，可以主动根据库表的变化来去访问。
最大的好处，和别的部门“解耦”了
参考下图
程序设计可以参考我的这套代码
incr-dump
