「数据的完整性、一致性和服务的稳定性，是数据存储类产品所需要特别关心的点。」
目前在做的广告检索系统，涉及到了广告信息存储，底层采用的是自研的类ES的存储引擎。因为全量索引的创建和更新一般都非常耗时，所以，增量更新是满足日常业务检索诉求必不可少的一环，具体是怎么实现的呢，如下图：
在ES上层，有一个builder进程，专门负责索引的构建、插入、更新操作。
而数据来源，是一个flow表，也可以叫做操作流水表，此表中的内容不会存储每个广告帖子的具体信息，只会记录某个帖子进行了操作这个简单的信息，是一个无状态的表。无状态的设计很重要，保证了数据处理的时效性和一致性.
而builder进程捞取到一条帖子的flow数据，就表明，该帖子在近期有过变动。所以，会实时的反查各个数据源，拿到帖子的最新信息，完成帖子索引的构建，保证相关数据最新。
「看到这个设计，是不是有种似曾相识的感觉。想起了什么，有没有想起mysql的redo log ,和 Redis的AOF。」
是的，作为数据存储类产品，他们三者，在数据一致性的设计上，有很多相通的地方，这里，我把他们放在一起做下横向比较：
类比下三种不同类别不同用途的存储类产品的数据一致性的实现方案，可以看到，他们基本都是一个思路。
用持久化的方式让数据损失达到最小，用缓冲和异步等方式，让主体服务稳定性影响最小 。我们这边的ES的实现策略，其实可以看成是aof或者redo log 的每个处理模块放大到了系统层面的表现。
或许在遇到类似问题的候，可以做个参考。
真是应了那句话，天下文章一大抄，看你会抄不会抄?
