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

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