一位打工仔的博客

官网：https://kafka.apache.org/documentation/

举个例子，我们以前做过一个 mysqlbinlog同步的系统，压力还是非常大的，日同步数据 要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（mysql -> mysql）。常见的一点在于说比如大数据 team，就需要同步一个 mysql 库过来，对公司的业务 系统的数据做各种复杂的操作。你在 mysql 里增删改一条数据，对应出来了增删改 3 条binlog日志，接着这三条binlog。

这个是肯定的，用 MQ 有个基本原则，就是，不能多，就是 前面说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考 虑一下。如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这 个 MQ 传递过程中。数据的丢失问题，可能出现在生产者、MQ、消费者中，咱们从 RabbitMQ 和 Kafka 分别来分析 一下吧。

但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启 了，如果碰到点着急的，直接 kill 进程了，再重启。但是你要是消费到第二次的时候，自己判断一 下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确 性。，会把自己消费过的消息的offset提交一下，表示“我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的offset来继续消费吧”。幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不 会改变的，不能出错。

跟普通集群模式不一样的是，在镜像集群模 式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说， 每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。其实很简单，RabbitMQ 有很好的管理控制台，就是在后 台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有 节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自 动将数据同步到其他的节点上去了。

通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。