RabbitMQ

背景

RabbitMQ是用Erlang实现的高并发,高可靠AMQP消息队列服务器
AMQP定义了一套消息系统规范,这个规范描述了在一个分布式的系统中各个子系统如何通过消息交互。子系统之间不再相互依赖,子系统仅依赖于消息,不关心消息的发送者和接受者。

AMQP

AMQP是一个面向消息中间件的开放式标准应用层协议,它定义了以下特性

  • 消息方向
  • 消息队列
  • 消息路由
  • 可靠性
  • 安全性

RabbitMQ基本原理

RabbitMQ中的基本概念:

  • ConnectionFactory:与RabbitMQ服务器连接的管理器
  • Connection:与RabbitMQ服务器的TCP连接
  • Channel:一个Connection可以包含多个Channel。因为tcp连接的建立是释放都是昂贵的,为了多路复用,应该尽量共用Channel
  • Exchange:接收生产者的消息,并按照一定的规则路由给服务器中的队列
  • Message Queue:消息队列,用于存储还未被消费者消费的消息
  • RoutingKey:指定当前消息被谁接受
Exchage类型

在上面提到了Exchange,RabbitMq提供了四种Exchange:fanout,direct,topic,header,我们只讨论前三种,性能:fanout>direct>topic

  • Fanout Exchage:不处理路由键,任何发送到Fanout Exchage上的消息都会被转发到与该Exchange绑定的多个Queue上,不需要指定RoutingKey
  • Direct Exchage:这种模式下不需要Exchage进行任何绑定操作,消息传递时只需要一个RoutingKey,即只需要知道消息被谁接收
  • Topic Exchage:这种模式较为复杂,简单来说就是每个队列都有其关心的主题,所有消息都带有一个标题(RouteKey),Exchage会把消息转发到所有关注主题与RouteKey模糊匹配的队列

消息队列常见应用场景

  • 异步处理
  • 流量削峰
  • 日志处理
  • 应用解耦

分发策略

默认情况下,rabbitmq会按顺序分发消息给下一个消费者,平均而言,每个消费者会得到相同数量的消息,这种发消息的策略称为轮询分发策略

消息应答

如果一个消费者执行了一个很长的任务只执行了一部分就死掉了,我们不想丢失掉那些还没有处理完成的消息;rabbitmq支持了消息应答,当消息被消费者接受并处理完成之后,消费者会向rabbitmq发送应答,rabbitmq收到应答后才会删除掉这条消息。如果一个消费者死掉了,这样就没有应答,rabbitmq会理解为消息没有被处理完毕,它会重新将消息扔回到队列中。

消息持久化

上面讲解了如何确保一个消费者在死掉之后任务不会丢失。但是我们的任务在rabbitmq停掉之后仍会丢失,当rabbitmq退出或挂掉之后,它会遗忘掉队列和队列中的消息。我们要将Exchange和消息队列都设为持久化的

  • 设置Exchange和MessageQueue的durable属性为true进行持久化
  • 消息什么时候需要持久化:1.消息本身在publish的时候就要求写入磁盘 2.内存紧张,需要将部分内存中的消息转移到磁盘
    将消息标记为持久化并不能完全保证消息不会丢失。这里仍然会有一个短时间的错失窗口:rabbitmq已经接受消息但是还没对他进行保存。而且rabbitmq可能仅仅把消息保存到缓存中并不是真正的写入到磁盘中。

公平调度

有的消息很重量级,有的消息是轻量级的。负责重量级的会一直忙碌不停,负责轻量级的基本不工作。这种情况发生的原因在于rabbitmq在一个消息进入队列之后仅仅调度消息,仅仅盲目的每n个消息轮询给每n个消费者。为了解决这种问题,我们可以在消费者处理并应答上条消息之前不要为其分发新的消息

事务

Rabbitmq提供了txRollback()命令用于回滚某个事务

生产者消息投递可靠性-Confirm机制

rabbitmq提供了一个轻量级的的机制来保证生产者可以感知消息已经被路由到正确的队列中-Confirm
如果设置channel为confirm状态,则通过该channel发送的消息都会被分配一个唯一的ID,一旦该消息被正确路由到队列中后就返回给生产者一个confirm,该confirm包含了这个ID,这样就知道消息被正确分发。对于持久化消息,只有在消息被持久化后才返回confirm
confirm最大的优点在于异步,生产者在发送消息后就可以执行其他任务,而服务器返回confirm之后会触发生产者的回调函数去处理confirm消息。如果消息服务器发生异常导致该消息丢失,会返回给生产者一个nack,表示消息已经丢失,这样生产者就可以重发消息。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,451评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,172评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,782评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,709评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,733评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,578评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,320评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,241评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,686评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,878评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,992评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,715评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,336评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,912评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,040评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,173评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,947评论 2 355

推荐阅读更多精彩内容