13.app后端为什么要用到消息队列

很多没有实际项目经验的小伙伴,对消息队列系统非常陌生,看着很多架构的介绍中,都提到消息队列。但是,不知道为什么要用消息队列?什么是消息队列?常见的消息队列产品有哪些?

  通过阅读本文,帮你解开以上的疑惑。

1. 为什么要用消息队列?

  假设一个老大,接到一个任务要处理完。在处理这个任务时,把这个任务分解为几个小任务,只要分别完成了这几个小任务,整个任务也就完成了。

  做到某个小任务时,发现这个小任务需要花很多时间完成,而且这个小任务迟点完成也不影响整个任务的完成进度。于是,老大把这个小任务交个一个小弟去做,自己去接着完成其他的任务。

  在上面的例子中,老大就是后台系统,小弟就是消息队列系统,当后台系统发现完成某些小任务需要花很多时间,而且迟点完成也不影响整个任务的,就会把这些小任务交给消息队列系统。

  在实际的app后端中,发送邮件,发送短信,推送等这些任务,都非常适合在消息队列系统中做的。大家想想,这些任务是不是都需要花比较多的时间,而且迟点完成也不影响的。把这些任务放在队列中,可加快请求的响应时间。

2. 消息队列是怎么工作?

  消息队列系统,一般都包含3个角色:队列服务端,队列的生产者,队列的消费者。

  消息队列系统类似于这个场景:有一条信息传送带不停地运转。在传送带的起点,工人a不断地把信息放在一个盒子,把盒子放到传送带上,盒子被传送带传送到终点。在终点上,工人b把盒子上的信息取出来,进行处理。

  在上面的场景中,不停运转的传送带就是队列服务端,在传送带起点不断放盒子的工人a就是队列的生产者,在传送带终点不断取盒子的工人b就是队列的消费者。

  消息队列的服务端,现在有大量的开源的应用,例如RabbitMQ ,ZeroMQ ,redis等。

  队列的生产者和服务者,是针对消息队列服务端开发的客户端,例如,RabbitMQ就有针对java,php等语言开发的客户端。

  例如,在app后端中,用代码调用 java客户端,把要发送的短信信息放在ZeroMQ中,这里java客户端是充当队列的生产者。

  写一个守护进程,在守护进程中,通过代码调用 java客户端把要发送的短信信息不断地从ZeroMQ取出来,然后发送出去。

3. 常见的一些消息队列产品

  RabbitMQ:

  是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了一个经纪人(Broker)构架,这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing),负载均衡(Load balance)或者数据持久化都有很好的支持。

  同时,RabbitMQ自带了一个web监控界面,可方便监控队列的情况。

  Redis:

  虽然是一个key-value系统,但自身也支持队列这种数据结构,可看做是一个轻量级的消息队列系统。

  在app后端架构中,redis是被广泛使用,如果同时把它作为消息队列使用,就减少了运维上的成本。

  ZeroMq:

  号称最快的消息队列系统,尤其针对大吞吐量的需求场景。

  ActiveMQ:

  是Apache下的一个子项目。 类似于ZeroMQ,它能够以代理人和点对点的技术实现队列。

---------------------------------------------------------------------------------------------------------------------------

打开链接  app后端系列文章总目录 总目录 ,能查看本人发表过的所有原创“app后端”文章。

【作者】曾健生

【QQ】190678908

【qq群】254659220

【微信公众号】 appbackend

【新浪微博】 @newjueqi

【博客】http://blog.csdn.net/newjueqi

时间: 2024-11-05 14:57:47

13.app后端为什么要用到消息队列的相关文章

13张PPT带你了解主动式消息队列处理集群

前言 偷偷和你们说,我搞了一份内部资料,该内部资料共有13张PPT,据作者透露,该PPT至少花了整整1周时间才编写完成,其内容简洁明了,内容深度足够,易于初学者理解,也给深度开发人员分享了不一样的消息队列的玩法.特别重要的是,该架构目前已大面积的稳定应用于生产环境. PPT的内容我作了脱敏处理,经作者审核后分享给大家. 特点 该消息队列的主要特点是:主动式.其架构主要由3大部分组成,分别是:消息生产者.消息处理集群.消息消费者,该架构和一般的消费队列最大的区别就是:消息生产者和消费者不直接接触消

app后端设计--总目录 (转)

特此说明,我转载的!!! app后端设计(1)--api app后端设计(2)--xmpp的使用 app后端设计(3)--短信,邮件,推送服务 app后端设计(4)-- 通讯的安全性 app后端设计(5)-- 表情的处理 app后端设计(6)-- LBS app后端设计(7)-- 项目管理 app后端设计(8)-- 数据库分表 app后端设计(9)-- 动态通知 app后端设计(10)--数据增量更新 app后端设计(11)-- 系统架构 app后端设计(12)--图片的处理 app后端设计(1

消息队列最大数目

消息队列: 1.每次msgrcv一个消息,1.那个消息会在内核中移除 2.每次msgrcv都只会给一个消息出来,不管你rcv用多大的buf来接收,都是可以的.如果msgrcv的bufSize小于实际的该消息的大小,那么可以设置一个标志:表示截断. 如果不设置,那么会报错.取不出来. 2.消息满了,则默认0为阻塞,直到有了空间位置,才能snd消息进入到内核. 消息空了,则默认为0阻塞,直到有了一个消息位置,才能 rcv消息进入到进程内存. 3.如果指定msgflg:MSG_NOERROR,如果函数

app后端设计(13)--IM4JAVA+GraphicsMagick实现中文水印

在app的后台中,有时候为了标示版权,需要给图片加上水印. 在liunx中,IM4JAVA+GraphicsMagick是个高效处理图片的方案,图片的裁剪是使用了这个技术方案,为了减少不必要的开发成本和运维成本,对应水印,我们是打算继续采用这个方案. 但在开发的过程中,发现这个方案对中文水印支持得不好. 根据网上的搜索结果,就算采用了im4java的GMOperation,并将水印的字符串转成GBK的编码,添加中文水印时,对于奇数个数的中文,没问题:但对于偶数个数的中文,就出现乱码了. 试了多次

新闻APP后端系统架构成长之路

前言:一年来从接受APP后端工作到现在可谓一路艰辛,中间踏过无数坑坑洼洼,也从中学到很多很多,之前领导也多次提醒,平时多总结.把经验形成系统,但平时大部分时间一直在忙于开发.处理问题,天天马不停蹄的往前走.眼看着春节将至,16年又过去了,业务有了很大发展,我们系统也愈加完善.之前一直也没有时间静下心来后头看看,眼下随着6.0版本开发上线完毕,稍得片刻喘息,自己也想想,也是时候回头看看.总结一下了. 1,初入圣地 2,筑基:完全重构 3,金丹:踩坑..而且是踩大坑 4,元婴:面临挑战,流量来袭 5

8.app后端和web后端的区别

很多从web后端转到app后端的小伙伴经常很茫然,不知道这两者之间有啥区别.本文通过例子,分析web后端和app后端的区别,使各位更好地把握app后端的架构. (1) app后端要慎重考虑网络传输的流量,主要是api设计,图片处理上 现阶段,手机上网的资费还是要按照流量算的,一般的3G用户,每个月的流量几百M,4G用户,每个月的流量也就几G. 如果不考虑网络传输的流量,一张图片就占了几百K,流量用得飞快的. 在前面的文章<7.app和app后端的通讯>中提到,api的返回结果一般是json格式

app 后端技术

app 后端技术 一直以来工作的方向是web server,对app server没有什么了解.虽然没有接触过移动app开发,但对app后端技术还是挺有探索欲望的,app应用和web应用在前端的用户习惯不同,相信后端也会有很多不太一样的地方.开此文记录一些网上收集到的app后端技术体系,以备了解. 下面就app server在业务设计上通常需要考虑的几个方面: 1.api风格 如何设计一套合理且优雅的api接口集,可以参考Restful分格: api采用http(s)协议与前端通信: 每个uri

27.app后端搭建聊天服务器的经历

现在,聊天功能已经成了社交app的标配了.但是,众多web开发出生的程序员对聊天相关的服务的不了解,带来了很多开发上的困扰.在这篇文章中,根据下面3个方面,谈谈聊天服务. 1.      聊天服务的技术选型 2.      开发社交app中,实现聊天服务踩过的坑 3.      那些著名app的聊天服务 1. 聊天服务的技术选型 需要开发聊天服务,首先要选择用到的协议,现在,常用的聊天协议有: (1)      xmpp,一个基于xml的消息协议,被广泛应用于Gtalk,Facebook,但缺点

26.app后端怎么架设推送服务

推送服务已经是app的标配了.架设推送服务,除了可以使用第三方服务商外,也有大量的开源技术可以选择. 现在推送主要分两块,android推送和ios推送,在下面分别论述: 1.    Android推送 Android手机由于没有系统的限制,当app进入了后台后,也能运行服务,所以android的推送可以基于长连接,这就注定了android的推送服务器和一般的app后端是不一样,技术细节上,架构上也不一样,幸好,现在有大量的开源软件可以轻松地实现推送. 下面深入研究过的开源推送软件:gopush