我们知道RabbitMQ可以配置成Queue做主从复制(按照官方的说法叫配置mirror queue),对master queue的写操作会被复制到其他slave上去(也就是复制到mirror queue上去)。这对rabbitmq的这个特性,有些人会问这样的问题,rabbitmq的主从复制是同步的还是异步的?
为什么有些人会问这个问题那?主要这些人往往是将rabbitmq这个主从复制过程和mysql的主从复制做类比。我们知道mysql主从同步是支持同步、半同步、异步3种模式的。采用哪种模式,决定了mysql的数据可靠性。如果是异步方式主从同步,client发请求给主,当主将数据写入后,从就复制主上的这条的数据,与此同时,主就会告知客户端数据保存成功,但是这时从可能还没有成功的存储这条数据。如果这时主挂掉了,我们进行主从切换就会丢数据。在要求保证数据可靠性的场景下,我们不能采用异步模式,我们需要采用同步模式或者半同步模式,这里我们就不再展开同步模式和半同步模式了。这些人将mysql的分析方式放到了rabbitmq,用同样的方式分析rabbitmq的数据可靠性,所以就提出了这样的问题。
实际上,rabbitmq的主从复制是异步的,但是rabbitmq并不存在mysql这种场景的丢数据(这句话不是说rabbitmq保证不丢数据)。在这里,我们来分析一下RabbitMQ的副本复制的过程。
首先,我们来说一下mysql和rabbitmq的使用接口是不同的,这时很关键的一点。mysql是同步的接口,也就是说client将sql发给server,server处理sql后将结果返回给client,在server返回client结果前,client不能发起下一个sql的请求。对于rabbitmq来说,访问接口是异步的。client(我们这里说的是publisher)向rabbitmq server publish一条消息,在默认的情况下server是不返回成功还是失败的,也就是说client在不到成功还是失败的情况下就可以发起下一个请求。如果client关心server是否成功处理完这条消息,可以开启confirm模式,server会异步的返回ack通知client消息投递成功还是失败。但是client仍然不必等待收到当前消息的ack就可以继续发下一条。
接下来,我们来说rabbitmq的主从复制过程。实际上,RabbitMQ主从之间的数据复制是异步的,但是在rabbitmq中不会出现mysql那种丢数据的情况,这是因为rabbitmq的接口也是异步的,主收到一条消息写入本地存储,然后在发起写入从的请求。当所有从写入成功后,主才会给client返回ack说这次写入成功了。所以可以看出,虽然rabbitmq的主从复制是异步的,但是并且不会出现mysql丢数据的场景。只要客户端收到ack,就说明这条消息已经写入主和从了。
所以需要强调的一点是,同步和异步并非是决定数据可靠性的关键点。客户端收到成功通知时,所有副本是否写入成功才是判断数据可靠的关键点。因为mysql的接口是同步,所以才需要在主从复制同步还是异步上做出选择。rabbitmq的接口本身就是异步的接口,所以rabbitmq的主从复制就自然而然的是异步的方式。