共勉
"诸君离学校而去了。在社会上立身的困难,恐怕比在学校里求学还要加甚。若非立志奋斗,则以前所受的教育,反足以增加人生的苦恼,或转为堕落的工具。这是诸君所当特别注意的。事业的成功,须经过长时间的辛苦艰难——成功的代价,走过了许多荆棘的路,方才能寻获康庄大道。立志是砍荆棘斧斤,奋斗是劳力。万不可希望以最少的劳力,获最大的成功。" -- 蒋梦麟
Knight's Blog
滴滴海浪技术主管, 前百度资深研发工程师,现居上海。 擅长于大规模的系统平台服务架构。在

- 亿级别搜索平台(sov5.cn)
- 大规模分布式爬虫
- 中间件架设(disconf,CanalX)
- 广告平台(百度联盟广告)
- 租车平台(滴滴租车)
- 语言招聘平台(51tra.com)
- 内容平台(100weidu.com)
- 社区平台(python88.com)
- 资源下载平台(misou.com)
- 计算机图形图像技术(一篇一作)
- 机器学习(一篇一作)

等领域具有颇有经验。
联系方式: knightliao AT gmail.com
联系
Knight's Blog » 工作

rabbitmq消息一致性问题

2015-02-26 15:58

在使用rabbitmq中,消息的一致性是非常重要的一个话题。下面我们来研究一下,在数据一致性方面,有哪些需要关注的。

发送问题:重复消息的问题

发送者发送消息出来,在数据一致性的要求下,我们通常认为必须达到以下条件

  1. broker持久化消息
  2. publisher知道消息已经成功持久化

首先,我们可以采用事务来解决此问题。每个消息都必须经历以上两个步骤,就算一次事务成功。

事务是同步的。因此,如果采用事务,发送性能必然很差。官方给出来的性能是:

It takes a bit more than 4 minutes to publish 10000 messages.

我们可以采用异步的方式来解决此问题。publisher发送消息后,不进行等待,而是异步监听是否成功。这种方式又分为两种模式,一种是return,另一种是confirm. 前一种是publisher发送到exchange后,异步收到消息。第二种是publisher发送消息到exchange,queue,consumer收到消息后才会收到异步收到消息。可见,第二种方式更加安全可靠。

http://ww3.sinaimg.cn/bmiddle/60c9620fjw1epmt7nicy0j20fp08kjs2.jpg

异步的方法的效率是事务方法效率的100倍

It takes a bit more than 2 seconds to publish 10000 messages.

但是,异步也存在些局限性。如果一旦出现broker挂机或者网络不稳定,broker已经成功接收消息,但是publisher并没有收到confirm或return.

这时,对于publisher来说,只能重发消息解决问题。而在这里面,我们会发生

重复消息的问题。

当然,如果业务类型要求数据一致性非常高,可以采用低效率的事务型解决方案

引用:http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/

本文链接地址:rabbitmq消息一致性问题
9737 次点击