消息中间件 — 使用场景

原文地址：消息队列及常见消息队列介绍

消息队列在实际应用中包括以下四个场景：

• 应用耦合：多应用间经过消息队列对同一消息进行处理，避免调用接口失败致使整个过程失败；
• 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减小处理时间；
• 限流削峰：普遍应用于秒杀或抢购活动中，避免流量过大致使应用系统挂掉的状况；
• 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；

应用耦合

具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，通常的作法是，服务器接收到图片后，图片上传系统当即调用人脸识别系统，调用完成后再返回成功，以下图所示：

该方法有以下缺点：

1. 人脸识别系统被调失败，致使图片上传失败；
2. 延迟高，须要人脸识别系统处理完成后，再返回给客户端，即便用户并不须要当即知道结果；
3. 图片上传系统与人脸识别系统之间互相调用，须要作耦合；

若使用消息队列：

客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。

此时图片上传系统并不须要关心人脸识别系统是否对这些图片信息的处理、以及什么时候对这些图片信息进行处理。事实上，因为用户并不须要当即知道人脸识别结果，人脸识别系统能够选择不一样的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。

异步处理

具体场景：用户为了使用某个应用，进行注册，系统须要发送注册邮件并验证短信。对这两个操做的处理方式有两种：串行及并行。

• 串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信；

  

  在这种方式下，须要最终发送验证短信后再返回给客户端。

• 并行处理：新注册信息写入后，由发短信和发邮件并行处理；

  

  在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。

假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：

串行：50+50+50=150ms 并行：50+50 = 100ms

• 若使用消息队列

并在写入消息队列后当即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间自己是能够很快的，基本能够忽略不计，所以总的处理时间相比串行提升了2倍，相比并行提升了一倍

限流削峰

具体场景：购物网站开展秒杀活动，通常因为瞬时访问量过大，服务器接收过大，会致使流量暴增，相关系统没法处理请求甚至崩溃。而加入消息队列后，系统能够从消息队列中取数据，至关于消息队列作了一次缓冲。

该方法有以下优势：

1. 请求先入消息队列，而不是由业务处理系统直接处理，作了一次缓冲,极大地减小了业务处理系统的压力；
2. 队列长度能够作限制，事实上，秒杀时，后入队列的用户没法秒杀到商品，这些请求能够直接被抛弃，返回活动已结束或商品已售完信息；

消息驱动的系统

具体场景：用户新上传了一批照片， 人脸识别系统须要对这个用户的全部照片进行聚类，聚类完成后由对帐系统从新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列链接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。

该方法有以下优势：

1. 避免了直接调用下一个系统致使当前系统失败；
2. 每一个子系统对于消息的处理方式能够更为灵活，能够选择收到消息时就处理，能够选择定时处理，也能够划分时间段按不一样处理速度处理；

---

若是读完以为有收获的话，欢迎点赞、关注、加公众号【牛觅技术】，查阅更多精彩历史！！！：