消息中间件-基于metaq-zookeeper

消息中间件

  消息中间件在消息传输过程中保持消息的容器。消息中间件再讲消息从它的原中继到它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递；如果发送消息是接受者不可用，消息队列会保留消息，直到可以成功地传递它为止，当然，消息队列保存消息也是有期限的。

 

消息中间件特点

1 采用异步处理模式

消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一个虚拟的通道（主题或队列）上，消息接受者则订阅或是监听通道。一条消息可能最终转发给一个或多个消息队列接受者。这些接受者都无需对消息发送者做出同步回应。整个过程是异步的

 比如用户信息注册。注册完毕后过段时间发送邮件或者短信

2 应用程序和应用程序调用关系为松耦合关系

         发送者和接受者不了解对方，只需要确认消息

         发送者和接受者不必同时在线

比如在线交易系统为保证数据的最终一致性，在支付系统完成后会把支付结果放到消息中间件通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。

 

1 支付成功，向消息中间件写入成功     毫秒级别

2 支付未知 怎么解决？

 

消息传递服务模型

 

消息中间件的传递模型

1 点对点模型（PTP）

点对点模型用于消息生产者和消息消费者之间点到点通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对应于消费服务中的一个队列（Queue），在消息传递给消费者之前它被存储在这个队列中。队列消息可以放在内存中也可以持久化，以保证在消息服务出现故障时仍能传递消息。

一 每一个消息只用一个消费者

二 发送者和接受者没有时间依赖

三 接受者确认消息接受和处理成功

2 发布-订阅模型（Pub/Sub）

     发布者/订阅者模型支持向一个特定的消息主题生产消息。0或多个订阅者可以对接受来自特定消息主题的消息感兴趣。在这种模式下，发布者和订阅者彼此不知道对方。这种模式好比匿名公告板。这种模式被概括为：多个消费者可以获得消息。在发布者和订阅者之间存在依赖性。发布者需要建立一个订阅（subscription），以便能够消费者订阅。订阅者必须保持持续的活动状态以接受消息，除非订阅者建立了持久的订阅。在这种情况下，在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。

一 每个消息可以有多个订阅者

二 客户端只有订阅后才能接收到消息

三 持久订阅和非持久订阅

 

1 发布者和订阅者有时间依赖

   接受者和发布者只有建立订阅关系才能收到消息

2 持久订阅

         订阅关系建立后，消息就不会消息，不管订阅是否在线

3 非持久订阅

         订阅者对了接受消息，必须一直在线

         当只有一个订阅者时约等于点对点模式

 

 

中间件使用案例

用户注册异步处理案例

 

1 网站用户注册，注册成功后会过一会发送邮件确认或者短信

 

 

日志分析使用案例

 

1 把日志进行几种收集，用于计算PV，用户行为分析

 

 

数据复制案例

 

1 将数据从源头复制到多个目的地，一般是按要求按顺序或者保证因果序列

2 用于跨机房数据传输，搜索，离线数据计算等

 

延迟消息发送和暂存

 

1 把消息中间件当成可靠的消息暂存地

2 定时进行消息投递，比如模拟用户秒杀访问，进行系统性能压测

 

消息广播

 

1 缓存数据同步更新

2 往应用推送数据

 

比如更新本地缓存

 

 

消息中间件分类

1 （push） 推消息模型：消息生产者将消息发送给消息传递服务，消息传递服务又将消息推给消息消费者

2 （pull） 拉消息模型：消费者请求消息服务接受消息，消息生产者从消息中间件拉该消息

 

两种类型的区别

模型	Push	Pull
服务端	消息存储 处理请求 保持推送轨迹 保存订阅关系 消费者负载均衡 集中式	消息存储 处理请求 分布式
客户端	处理响应和请求	处理响应和请求 保存pull状态，如拉取位置的偏移量offset 异常情况下的消息暂存和recover
实时性	较好，收到数据后可立即发送给客户端	取决于pull的间隔时间
消费者故障	消费者故障情况下，服务端堆积消息，重复推送消耗资源。 保存推送轨迹压力很大	消费者故障，对服务端无影响
其他	对消息推送有更多控制，能实现多样化的推送机制。当消费者数量增多的时候，推送压力很大，性能天花板。 消费者处理能力差异，导致堆消息	需要在客户端实现消息过滤，浪费资源。 需要在不同客户端之间协调，做负载均衡

 

 

本文出自 “晴空” 博客，谢绝转载！