消息队列的定义，以及引入消息队列可解决的问题

消息队列的定义，以及引入消息队列可解决的问题

 

1. 消息队列中的“消息”即指同一台计算机的进程间，或不同计算机的进程间传送的数据；
“消息队列”是在消息的传输过程中保存消息的容器。
消息被发送到队列中，消息队列充当中间人，将消息从它的源中继到它的目标。

2. 传统的进程通信模式如图1左所示：client调用service，等待service的响应。但是这种模式有很多弊端：
-网络情况不好时，client到Service的调用可能会丢失；
-或者service如果处理时间较长，那么client需要一直hold，甚至调用超时而失败；
-或者service的些许改动会带来client的代码修改等等。

3. 引入消息队列则可以避免这种传统模式的弊端，如图1右所示：

 

       图1（左） 典型的Invoke/Respond模型                                 图1（右） 典型的消息队列处理流程

 

4. 消息队列可以带来如下好处：
（1）保证消息的传递。
如果发送消息时接收者不可用，消息队列会保留消息，直到成功地传递它；

（2）提供异步的通信协议。
消息的发送者将消息发送到消息队列后可以立即返回，不用等待接收者的响应，消息会被保存在队列中，直到接收者取出它；

（3）解耦，降低两个进程间的耦合度。
只要消息格式不变，即使接收者的接口、位置、或者配置改变，也不会给发送者带来任何改变；
而且，消息发送者无需知道消息接收者是谁，使得系统设计更清晰；
相反的，例如，远程过程调用（RPC）或者服务间通过socket建立连接，如果对方接口改变了或者对方ip、端口改变了，那么另一方需要改写代码或者改写配置；

（4）提供路由。
发送者无需与接收者建立连接，双方通过消息队列保证消息能够从发送者路由到接收者，甚至对于本来相互网络不通的两个服务，也可以提供消息路由。

为什么需要分布式消息队列

 

可靠
分布式消息队列提供更好的可靠性，主要体现在：
1. 消息会被持久化到分布式存储中。这样避免了单台机器存储的消息由于机器问题导致消息的丢失；
2. 不佳的网络环境中，保证只有当消息的接收者确实收到消息时才从队列中删除消息。

可扩展
可扩展性体现在访问量和数据量两个方面：
访问量：分布式消息队列服务，会随着访问量的增减而自动增减逻辑处理服务器；
数据量：当数据量扩大时，后端分布式存储会自动扩容。

安全
安全体现在以下两个方面：
1. 同时使用消息队列的业务之间不会互相干扰
如果有多个业务同时在使用消息队列，对于单机的消息队列服务，一个业务的消息操作可能会影响其他业务的正常运行。
比如，一个业务的消息操作特别频繁，占据了消息队列的绝大部分服务时间，也占据了这台服务器的绝大部分网络IO，导致其他业务无法正常地与消息队列通信。
而且甚至可能由于服务控制不当，导致机器崩溃，服务停止，业务也跟着停止。
分布式消息队列则不会出现这个问题：
（1）监控措施完善，系统性能指数会控制在一定范围之内，而且有任何异常也会报警；
（2）当访问量和数据量增大时，分布式消息队列服务可以自动扩展。

2. 各业务的消息内容是安全存储的，其他业务不能访问到非自身业务的数据。
一方面是业务需要密钥来访问消息队列；另一方面，消息是被加密存储的。

简单实用
简单实用体现在：
1.透明：接收者和发送者无需知道具体的消息队列的服务器地址，服务器的增减对接收者和发送者透明。
2. 实用：对于两个服务之间不能通信的网络情况，消息队列为他们提供了恰到好处的桥梁。

CMQ的特性

 

消息队列中的“消息”即指同一台计算机的进程间，或不同计算机的进程间传送的数据；“消息队列”是在消息的传输过程中保存消息的容器。
消息被发送到队列中，消息队列充当中间人，将消息从它的源中继到它的目标。

腾讯云计算平台提供的分布式消息队列CMQ服务实现了消息队列的全部宗旨：
1. 保证消息的传递；
2. 提供异步的通信协议；
3. 解耦；
4. 提供路由。

同时，CMQ具有分布式消息队列的全部优势：安全、可靠、简单易用、透明、实用、可扩展，弥补了消息队列潜在的不足，以自己的方式提供更可靠、更安全、更易用、更实用的周到服务。

引入消息队列则可以避免传统进程通信模式的弊端，如下图所示：

 

       图1（左） 典型的Invoke/Respond模型                                 图1（右） 典型的消息队列处理流程

CMQ的优势

 

更可靠
（1）接收者接收消息后，CMQ服务并不立刻从队列中删除该消息，只有在接收者确认接到消息，主动发送删除消息请求时，才把消息删除；
（2）保证消息只被接收一次。实现方式是在消息被接收后锁住该条消息，锁有时效，当接收者在时效内没有来删除这条消息，则说明接收者出现异常，锁失效，该条消息可以被再次接收；
（3）应用发送消息，如果直接通过http协议访问消息队列，则消息必须经过base64编码，这样避免了消息的编码格式混乱造成的消息接收错误；CMQ SDK内部进行了base64编码的封装，应用可以传任意内容给SDK接口。

更安全
（1）应用必须登录开放平台，有自己的应用（即具有appid）才可以开通消息队列服务；
（2）开通消息队列时，会告诉用户一个AccessKey作为访问消息队列的密码，之后应用发送和接收消息都要使用该AccessKey；
（3）发送和接收消息时，除了使用AccessKey还要传入应用的appid，而且必须匹配；
（4）应用没有途径可以直接看到其他应用的消息内容。

更易用
（1）只需一键即可开通消息队列服务，只需一键即可创建、删除队列，不用按键即可查看应用已经创建的队列列表及信息。
（2）用户在可视化界面中创建队列后，只需通过http请求访问消息队列。
（3）接口简单，无需对复杂的网络环境进行处理和容错。

更实用
（1）切实解决开放平台中两个应用之间，甚至一个应用内部通信的复杂性。
云平台中各服务所在服务器地址不确定，所以服务需要比较复杂的配置才能通信，或者无法通信。但是应用可以轻松访问CMQ服务；
（2）访问速度快。
消息队列以其特有的设计方案，实现了单次请求响应快、高并发的特性。
平均单次请求10ms，支持单队列200次/每秒的访问量，单应用2万次/秒甚至更高（支持更高只需扩展服务器而已）的访问量。

CMQ适用的场景

 

异步通信
对于BS(Browser-Server 浏览器)架构，很多情景下server的处理时间较长。
如果浏览器发送请求后，保持跟server的连接，等待server响应，那么一方面会对用户的体验有负面影响；
另一方面，很有可能会由于超时，提示用户服务请求失败。

对于这种情景，消息队列提供了一个较好的解决方案，如图2所示：

 

                              图2 BS通信模型的优化方案

 

工作流程如下：
（1）浏览器向服务器发送请求后，服务器接到响应后立即返回；
（2）之后，服务器向消息队列发送已经完成的结果信息；
（3）浏览器端用js等技术循环请求该消息队列，检查是否有新的结果信息，如果有则获取消息，并将结果渲染到浏览器界面上。


命令下发/分布式处理模型
在分布式的应用系统中，经常会有master-worker的模型（Map-Reduce就是一个典型的例子）。
有任务到达时，master会将任务直接分配给worker或者切成子任务分配给worker，但是有一个原则就是一个任务或者子任务只希望被一个worker执行。

传统的处理方式是：
（1）master要维护worker的心跳，知道有哪些worker可以接受任务，然后master挑选一个worker，与其建立连接，并发送数据包（即命令）；
（2）worker收到数据包（命令）后，如果能够正常解析并执行，则反馈master；
（3）如果worker许久没有反馈，则master会做一系列工作，包括check该worker状态、确保死掉了之后再挑选一个worker分配任务。

这样的处理方式对master压力过大，也过于复杂。使用消息队列则可对master和worker进行有效解耦，如图3所示：

 

                            图3 master-worker命令下发模型的优化方案

 

CMQ中，master和worker的配置中都事先配置好两个队列名：1任务下发队列名，结果反馈队列名。
master有任务下发时，就向该“任务下发”队列中发送消息；
worker定期检查“任务下发”队列，发现队列有消息则获取（因为CMQ的特性保证了一条消息只会被一个接收者接收，所以一个任务只会被一个worker执行）。
之后worker执行的结果都发送到“结果反馈”队列中，master定期检查“结果反馈”队列，汇总执行结果。
所有这种一对多的通信，并且只希望这个“多”中只有一个真正接收到消息，则都可采用上述的解决方案。


数据上报模型
凡是多对一的通信都可以采用CMQ来解耦合，如下面例子所示：
1. 上文“命令下发/分布式处理模型”中给出的master-worker模型解决方案中，多个worker向同一个队列发送消息，master从该队列接收消息，就是一个典型的数据上报模型，即图3中的结果反馈的过程。

2. 监控服务中各个机器有后台进程定期汇报机器状态，中心服务收集各机器状态，进行计算和统计。也是一个典型的数据上报模型。
监控服务的后台进程可以将状态汇报到一个消息队列，中心服务从这个队列中接收消息，如图4所示：

 

                                图4 数据上报模型的优化方案

	

3. 在线游戏中，需要一个可以实时显示当前各团队比赛战况的界面，或者任何需要汇总信息的需求。
这些都可以从各个机器汇报状态到消息队列，汇总服务从队列获取数据、处理数据并显示。