后端面试反复问的MySQL与ES双写问题_哔哩哔哩_bilibili

分享一个上个月面试被反复问且最近工作又遇到的问题视频文档： https://docs.qizong007.top/system-design/mysql-sync-es（这是重新录制的版本，感谢指出原版视频问题的小伙伴🙏）, 视频播放量 3652、弹幕量 3、点赞数 113、投硬币枚数 36、收藏人数 437、转发人数 26, 视频作者 _王帅真, 作者简介 前字节后端，分享编程与思维认知 https://blog.qizong007.top，相关视频：面试官:MySQL中IN是全表扫描吗？，网易云一面系统设计题：直播弹幕系统，美团二面：说说15种慢SQL的优化方式？两次面试都问到了，每日一题471：Ribbon的原理是什么？，美团二面：当面对MySQL查询超过1000万条数据导致查询变慢的情况时，你是如何做优化的？，强推！2024最强Java面试八股文，狂刷15天直接面试上岗，存下吧！面试通过率猛涨！，每日一题473：什么是Cache Aside机制？，面试官：大文件上传有什么问题？如何解决，2024版最全数据库缓存面试教程，900分钟吃透MySQL调优+Redis分布式锁+ShardingSphere分库分表实战，系统设计面试：如何设计一个通知系统

https://www.bilibili.com/video/BV1xT421C76T/?spm_id_from=333.999.0.0

场景引入

方案一：同步双写

优点

• 简单粗暴

• ES 同步写入快

缺点

• 业务耦合，扩展性差，代码侵入性强（要在写 MySQL 的地方后写 ES 的代码，要在代码设计上做好收敛）

• 影响性能，写入两个存储，响应时间变长（本来 MySQL 的写入性能不是很高，再加一个 ES，系统的性能必然会下降），吞吐也会下降

• 存在双写失败丢数据风险（比如写完MySQL，ES 就挂了）

方案二：异步双写

优点

• 性能高

• 不易出现数据丢失问题，主要基于 MQ 消息的消费保障机制，比如 ES 宕机或者写入失败，还能重新消费 MQ 消息

• 多源写入之间相互隔离（业务侧只管发消息），解耦数据生产者和消费者，便于扩展更多的数据源写入

缺点

• 同样存在业务耦合的问题，写完 DB 之后，还需要发个 MQ（代码设计上做好收敛，也可以关注一下所用 orm 框架有没有 hook 之类的能力，支持你“写后 xxx”）

• 接入新的数据源需要实现新的消费者代码

• 系统复杂度增加，引入了消息中间件

• MQ是异步消费模型，存在延迟问题

方案 2.1：使用内存队列

如 golang 的 channel

1. 把数据写入DB

2. 把数据写入内存队列

3. 消费线程异步从队列中消费数据写入ES（可以做批量优化，定时+定量）

优点

缺点

方案 2.2：使用分布式消息队列

如 RocketMQ、RabbitMQ、Kafka 一类的 MQ 中间件

1. 把数据写入DB

2. 把数据写入MQ

3. 消费线程异步从MQ中消费数据写入ES

优点

缺点

方案三：定时同步

开定时任务回扫

优点

• 实现简单

• 适合作为其他方案的补充兜底，用于处理双写中的失败情况

缺点

• 无法保证数据的实时性，存在较大的同步延迟

• 对数据库的存储和计算压力较大，尤其是在数据量大时

方案四：数据订阅

如阿里的 Canal，订阅 MySQL 的 binlog（伪装成DB从节点），发 MQ 消息

优点

• 业务入侵较少

• 实时性较好

缺点

• 系统复杂度增加，引入了消息中间件和额外组件，有一定维护成本（至少得保证 Canal 不能挂掉）