01消息中间件在大规模分布式系统应用.pptx

指导教师：詹剑锋研究员专业：计算机软件与理论答辩人：明子鉴消息中间件在大规模分布式系统中的应用王越

Outline1消息中间件的产生背景消息通信范型典型应用代表系统未来趋势

背景1传统同步通信机制同步紧耦合单点通信异步通信机制异步松耦合性多对多通信大规模分散控制动态改变分布式消息系统松耦合，异步的多对多通信模式应用完全独立于底层结构具有良好的可扩展性

背景1消息生产者股票报价在线新闻消息中间件消息过滤消息路由消息事件处理消息消费者发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同

背景1覆盖网络技术(OverlayNetwork)

消息通信范型：P2P2客户端1Queue消息消息发送消费确认客户端2点对点模型点对点模型用于消息生产者和消费者之间点到点的通信消息生产者将消息发送到由某个名字标识的特定消费者，这个名字对应消息服务的一个队列每个消息只有一个消费者

消息通信范型：发布订阅2客户端1发布消息topicbroker消息订阅分发订阅消息分发客户端2客户端3发布订阅模型用主题为消息做了分层，发布者为发送的消息指定主题，只有订阅了该主题的消费者才会收到消息

消息通信范型：发布订阅2电影院发布消息电影院发布消息：新电影上映，价格40元（主题指定为电影）客户端了订阅了电影主题topic消息订阅分发客户端

SubscriberPublisher1.Subscribe2.publish2消息通信范型：发布订阅

典型应用3消息分发分布式事务日志同步延迟队列广播通知

消息分发3微博关注某人消息中间件推荐系统搜索系统feed系统统计系统HadoopMySQL

分布式事务3store交易中心付款成功消息Broker商品管理物流CRMstorestorestore利用消息中间件实现分布式事务支持

日志同步3AppAppApp消息中间件HBaseStorm离线分析实时处理日志：监控日志、系统日志、搜索日志等

延迟队列3Publisher消息中间件Subscriberrecover延迟投递消息中间件作为可靠的延迟队列

广播通知3App消息中间件AppAppAppApp①发布通知②广播通知可靠的集群内广播通知用于通知cache失效等事件

代表系统4ActiveMQRabbitMQZeroMQApacheKafkaRedis阿里巴巴：Notify和MetaQ

ApacheKafka4最初由LinkedIn公司开发分布式消息系统(使用Zookeeper协调管理)同时为发布和订阅提供高吞吐量将消息持久化到磁盘，可用于批量消费

ApacheKafka4Kafka架构：将topic分为多个分区，每个代理存储一个或多个分区

ApacheKafka4Kafka的存储架构

消息中间件的主要异同4通信模型：P2Pvs.Publish/Subscribe是否对消息做持久化推模型vs.拉模型是否支持顺序消息消息QoS机制(可靠性、事务性、安全性)

P2Pvs.Publish/Subscribe4P2P模式下每个消息只有一个消费者发布/订阅模型可以根据订阅主题将消息发送给多个订阅者

消息的持久化4持久消息队列：基于数据库或文件系统，提供消息持久存储功能，同时又具有最小的内存开销，适合于消息需要可靠传输的应用环境。内存队列：基于内存的消息队列。不提供消息持久功能，完全基于内存来进行消息的缓存和分发。适合对性能要求非常苛刻，但是消息无需可靠持??久的应用环境。高速缓存队列：基于数据库和内存Cache的持久。提供可靠持久功能，同时又使用内存作为Cache，因此具有最大的资源开销，同时又具有很高的性能。适合于大部分应用场合。

Pushvs.Pull4拉模型是由消息的消费者发起的，主动权把握在消费者手中，它会根据自己的情况对生产者发起调用。拉模型的消费者通常以BatchJob的形式，根据事先设定的时间间隔，定期侦听通道的情况。一旦发现有消息传递进来，就会转而将消息传递给真正的处理器（例如ApacheKafka）推模型的主动权常常掌握在生产者手中，消费者被动地等待生产者发出的通知，这就要求生产者必须了解消费者的相关信息(例如阿里的Notify)

Pushvs.Pull4推模型优势?Consumer扩容方便，不受分区数限制?支持复杂的过滤（因为订阅关系在server端）?一个分区可以为多个consumer服务，分区数不会是瓶颈拉模型优势?Consumer端控制方便，便于业务方根据自己需要去获取消息?顺序消息支持方便?允许长时间消费一条消息

是否支持顺序消息4消费者消费消息的顺序跟消息的发送顺序是否一致的。比如，我发送消息的顺序是A、B、C，那么消费者消费的