跨库聚合全文搜索的三种存储方案
Jensen约 3 分钟前言：ES（ElasticSearch）作为一个开源的准实时分布式全文搜索引擎，它使用了倒排索引的方式来建立关键字到文档的关系。对比传统关系型数据库，ES在全文搜索、分词、常规搜索、聚合统计方面性能高，是当前流行的企业级搜索引擎，主要提供分布式搜索服务。今天我们来聊聊ES与DB的数据同步方案。
场景假设
「假设」商品（SPU）下有多规格（SKU），业务方要求根据SKU号分页查询，以SPU的维度做聚合，同时有其它检索条件且需要分页展示商品信息。
「思路」涉及到跨库分页查询，传统的关系型数据库不灵了，那就采用数据冗余的设计来完成吧，在这里采用ES方案。ES聚合SPU+SKU等信息，应用直接查ES返回数据，这就需要维护ES与数据库的数据。前者没有太大问题，关键在于如何解决ES与数据库之间的数据一致性问题，以下是几种方案。
方案一：应用同步双写
应用写入DB，同时SPU聚合SKU存ES 后门批量刷ES修数 定时全量刷ES修数
此技术方案最简单，更新DB时同步更新ES。由于ES数据初始化、索引重建或数据异常（如应用上线单方面执行SQL）等原因，需要提供后门批量刷ES修数，同时根据业务特点考虑引入定时全量刷ES修数的机制。但缺点也很明显，附带问题最多，数据冲突、数据覆盖、数据丢失，处处是坑，谨慎选择。
方案二：应用异步双写
SPU聚合SKU存ES 通过MQ实时异步通知应用，增量刷ES 后门批量刷ES修数 定时全量刷ES修数
此方案引入了MQ消息队列，发送通知来代替执行ES更新操作，因此MQ需要高可用，保证消息被应用正确消费，允许冗余消费。同时增量更新需要开关控制，防止预发布环境重建ES索引被生产环境增量覆盖更新的情况。缺点和同步双写一样，与业务系统耦合严重，需要按照业务需求独立编写，且每个业务都需要专门编写相关代码，不利于快速响应需求。
方案三：CDC技术
全称Change Data Capture（变更数据捕捉），从数据库内部捕捉变更数据，将变更数据推送到中间程序中，中间程序逻辑实现同步推送到ES。
SPU聚合SKU存ES canal中间件捕捉binlog相关表的变更记录 数据库变更监控服务通过canal捕捉到的变更记录发送至MQ 通过MQ实时异步通知应用，增量刷新ES 后门批量刷ES重建索引
此方案由canal中间件捕捉到的binlog消息发送到MQ，应用只需消费增量变更MQ消息即可。CDC机制速度极快，数据精准，且与应用程序耦合少，可抽象脱离业务系统，适合大规模使用。由于额外引入了MQ与Canal，因此需要保证MQ与Canal高可用，必要时还需要后门批量重建索引。
总结
方案一不推荐；在业务不复杂的情况下，方案二可以支撑百万以下的数据体量，对业务有一定的侵入性。方案三需要多维护一个中间件，同时需要开启数据库同步机制，对业务系统侵入性较低，适用于业务较复杂的场景。具体还需要根据业务评估优劣。
关注后，回复「题库」领取海量算法题库
喜欢本文的朋友点个「在看」吧↓↓↓