消息中间件在大型分布式系统的应用.pptVIP

消息中间件在大型分布式系统的应用 马震(锋寒)@淘宝网 2011-11-26 个人简介 2008年——至今 淘宝网技术专家 负责消息中间件的研发 之前在Ericsson和金蝶中间件工作 感兴趣领域： 并发和网络编程 大型分布式系统的构建 海量数据的分析和处理 微博：/mz1999 Outline 淘宝消息中间件概览 消息中间件应用场景 分布式事务 数据复制 日志同步 delay queue 广播通知 总结 消息中间件 应用程序或组件之间的一种通讯方式 可靠性 异步 松散耦合 发送者和接收者不必了解对方，只需要认识消息 发送者和接收者不必同时在线 Messaging Models Point-to-Point (PTP) 每个消息只有一个消费者 发送者和接收者没有时间依赖 接收者确认消息处理成功 Publish/Subscribe 每个消息可以有多个订阅者 客户端只有订阅后才能收到消息 淘宝消息中间件 Notify Push模式，消息存储转发 支持分布式事务 订阅者集群 支持多种安全级别的存储 淘宝消息中间件 Metamorphosis 开源MQ-kafka的Java版本 消息都是持久的，保存在磁盘 客户端pull，利用sendfile系统调用，零拷贝 吞吐量第一 支持消息顺序 淘宝消息中间件 Broker: Shared nothing architecture 发布者、订阅者都支持集群 Publisher Publisher Publisher Broker Broker Subscriber Subscriber Subscriber 集群 集群 集群 ConfigServer ZooKeeper Notify——分布式事务 通用的消息中间件支持XA分布式事务 优点 跨越多个资源ACID的保证 编程模型简单一致 缺点 性能和可用性都不高 故障难于恢复 Notify——分布式事务 Publisher Broker Storage T1 发送half消息 T3业务操作 T4提交/回滚 T2存储half消息 T5 提交:更新数据库 标识消息可发送 回滚：删除消息 S1 定期检查未提交的消息 S2提交/回滚 本地事务域 本地事务域 业务操作 S3 提交:更新数据库 标识消息可发送 回滚：删除消息 Notify——订阅者集群 订阅者集群：消息的一个逻辑上的订阅者是有多个物理节点组成的一个集群 Broker Publisher A1 A2 A3 应用A B1 B2 B3 应用B Notify——消息存储 多种安全级别的存储 File Oracle+小型机+存储 MySQL MySQL + Replication 同步写入两个存储节点 支持存储节点的动态变化 Meta——跟kafka有什么不同? 用java替换scala Consumer API没有采用kafka的stream方式，而是同时实现同步获取和异步订阅两种方式 存储结构上采用自定义结构，更简洁紧凑 客户端的连接复用 实现HA复制 实现发送的软负载 支持本地和XA事务 支持http协议 数据迁移、扩容对用户透明 Outline 淘宝消息中间件概览 消息中间件应用场景 分布式事务 数据复制 日志同步 delay queue 广播通知 总结 场景（一）分布式事务 为面向服务架构（SOA）提供分布式事务支持 保证全局数据的一致性 交易中心 Broker 商品管理 物流 CRM … 付款成功消息 store store store store 场景（二）数据复制 利用消息中间件将数据从源头复制到多个目的地 满足搜索、离线分析和分表规则变化等需求 DB DB Sync binlog Broker Search hadoop DB 场景（三）日志同步 应用通过可靠异步方式将日志同步到消息中间件 可以对日志做实时或离线分析 Broker App App App HBase Storm App App 场景（四）delay queue 把消息中间件当做可靠的延迟队列 分布式环境下的定时器 Broker Publisher Subscriber recover 延迟投递 场景（五）广播通知 可靠的集群内广播通知 用于通知cache失效等事件 Broker App App App App App ①发布通知 ②广播通知 总结 消息中间件对于大型分布式系统非常重要 扩展性 可用性 自动流量调节 开源产品的选择 谨慎对待标准产品和企业级解决方案 KISS原则 业务操作和消息存储都在本地事务域进行，不存在跨资源的事务。 提交/回滚消息有可能失败，系统会处于短暂的不一致状态 Broker会主动发送Check消息，确认消息是否提交或回滚 最终一致 将分布式