商品检索
大家应该都在各种电商网站检索过商品，检索商品一般都是通过什么实现呢？搜索引擎Elasticsearch。
那么问题来了，商品上架，数据一般写入到MySQL的数据库中，那么用于检索的数据又是怎么同步到Elasticsearch的呢？
MySQL同步ES
1.同步双写
这是能想到的最直接的方式，在写入MySQL，直接也同步往ES里写一份数据。
同步双写
对于这种方式：
优点：实现简单
缺点：
业务耦合，商品的管理中耦合大量数据同步代码
影响性能，写入两个存储，响应时间变长
不便扩展：搜索可能有一些个性化需求，需要对数据进行聚合，这种方式不便实现
2.异步双写
我们也很容易想到异步双写的办法，上架商品的时候，先把商品数据丢进MQ，为了解耦合，我们一般会拆分一个搜索服务，由搜索服务去订阅商品变动的消息，来完成同步。
异步双写
前面说的，一些数据需要聚合处理成类似宽表的结构怎么办呢？例如商品库的商品品类、spu、sku表是分开的，但是查询是跨维度的，在ES里再聚合一次效率就低一些，最好就是把商品的数据给聚合起来，在ES里以类似大宽表的形式存储，这样一来查询效率就高一些。
多维度多条件查询
这种其实没什么好办法，基本上还是得搜索服务直接查库，或者远程调用，再查询一遍商品的数据库，就是所谓的回查。
回查完成聚合
这种方式：
优点：
解耦合，商品服务无需关注数据同步
实时性较好，使用MQ，正常情况下，同步完成在秒级
缺点：
引入了新的组件和服务，增加了复杂度
3.定时任务
假如我们要快速搞搞，数据量有没那么大，怎么办呢？定时任务也可以。
定时任务
定时任务，最麻烦的一点是频率不好选，频率高的话，会非自然地形成业务的波峰，导致存储的CPU、内存占用波峰式上升，频率低的话实时性比较差，而且也有波峰的情况。
这种方式：
优点：实现比较简单
缺点：
实时性难以保证
对存储压力较大
4.数据订阅
还有一种方式，就是最时兴的数据订阅。
MySQL通过binlog订阅实现主从同步，各路数据订阅框架比如canal就依据这个原理，将client组件伪装成从库，来实现数据订阅。
MySQL主从同步
我们以应用最广泛的canal为例，canal通过canal-adapter，支持多种适配器，其中就有ES适配器，通过一些配置，启动之后，就可以直接把MySQL数据同步到ES，这个过程是零代码的。
canal同步数据
虽然我们听从老板的建议，使用canal进行同步工作，但实际上我们还是需要编写代码。为什么呢？
由于canal的支持有限，前文提到的多张表数据聚合仍需通过回查方式实现。这时候用canal-adapter就不合适了，需要自己实现canal-client，监听和聚合数据，写入ES：
数据订阅+回查
这种看起来和异步双写比较像，但是第一降低了商品服务的耦合，第二数据的实时性更好。
所以使用数据订阅：
优点：
业务入侵较少
实时性较好
至于数据订阅框架的选型，主流的大体上是这些：
开源方阿里巴巴Zendesk社区开发语言JavaJavaPython活跃度活跃活跃活跃高可用支持支持不支持客户端Java/Go/PHP/Python/Rust无Python消息落地Kafka/RocketMQ 等Kafka/RabbitNQ/Redis 等自定义消息格式自定义JSON自定义文档详略详细详细详细Boostrap不支持支持不支持
MySQL同步到其他数据存储，如HBase，基本上都是采用相似的几种方法。
以上就是MySQL数据同步Elasticsearch的方案有哪些的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/148814.html
微信扫一扫 
支付宝扫一扫 
