消息中间件-Notify的概念和原理

淘宝-Java中间件淘宝消息中间件简介Agenda•消息中间件概览•淘宝消息中间件简介•总结淘宝中间件产品线前端应用业务代码Webx容器后端应用业务代码容器DBTaobaoMQHSFTDDLConfigServer/DiamondDBTDDL消息中间件•Message-orientedmiddleware(MOM)issoftwareinfrastructurefocusedonsendingandreceivingmessagesbetweendistributedsystems.---fromwikipedia.org•MOM的特点–松散耦合•发送者和接收者不必了解对方，只需要讣识消息•发送者和接收者不必同时在线–异步处理消息中间件–应用程序或组件之间的一种通讯方式•可靠性•异步•松散耦合MessagingModels•Point-to-Point(PTP)–每个消息只有一个消费者–发送者和接收者没有时间依赖–接收者确讣消息处理成功Client1Msg发送QueueClient2Msg消费确讣MessagingModels•Publish/Subscribe–每个消息可以有多个订阅者–客户端只有订阅后才能收到消息–持久订阅–非持久订阅Client1Msg发布TopicClient2Msg订阅投递确讣Client3订阅投递确讣Publish/Subscribe•发布者和订阅者有时间上的依赖。–客户端只有建立了订阅关系后，才能收到消息•非持久订阅–订阅者为了接收消息，必须一直在线•持久订阅–订阅关系建立后，消息就不会丢失，不管订阅者是否在线–当只有一个订阅者时，≈PTP非持久订阅持久订阅Taobao消息中间件•具有互联网特征的消息中间件–消息发送和业务操作的一致性–订阅者集群–扩展性–可靠性–稳定性–高性能消息发送和业务操作的一致性•通用的MQ产品支持XA分布式事务–优点•跨越多个资源ACID的保证•编程模型简单一致–缺点•性能和可用性都不高•故障难于恢复消息发送和业务操作的一致性PublisherBrokerStorageT1发送half消息T3业务操作T4提交/回滚T2存储half消息T5提交:更新数据库标识消息可发送回滚：删除消息S1定期检查未提交的消息S2提交/回滚本地事务域本地事务域业务操作S3提交:更新数据库标识消息可发送回滚：删除消息消息发送和业务操作的一致性•业务操作和消息存储都在本地事务域进行，不存在跨资源的事务。•提交/回滚消息有可能失败，系统会处于短暂的不一致状态•Broker会主动发送Check消息，确认消息是否提交或回滚•最终一致•将分布式事务分解在两个本地事务中•客户端需要付出的代价–实现CheckMessageListener接口订阅者集群•订阅者集群：消息的一个逻辑上的订阅者是有多个物理节点组成的一个集群•A1和A2是SystemA中的两个机器•A1和A2共同来消费投递到SystemA的消息•B1和B2也是类似的关系PublisherMOMA1A2SubscriberAB1B2SubscriberB扩展性•Broker--Sharednothingarchitecture•发布者、订阅者都支持集群PublisherPublisherPublisherBrokerBrokerSubscriberSubscriberSubscriber集群集群集群扩展性•支持存储节点的动态变化BrokerStoreStoreStoreStore可靠性•服务质量(QOS)级别–Exactly-once•投递一次且仅一次–At-least-once•最少会投递一次，有可能会重复投递–At-most-once•最多投递一次，有可能丢失•不能丢消息可靠性•消息的投递分为两个阶段–发布者向Broker发送消息–Broker向订阅者投递消息•因此，消息有可能在三个地方丢失–发布者到Broker之间–Broker本身–从Broker到订阅者可靠性•Publisher-Broker–Broker收到消息，放入存储节点中，才会返回“成功”给Publisher•存储的可靠性–没有绝对的可靠，需要定义级别•File•Oracle+小型机+存储•Mysql•Mysql+Replication•同步写入两个节点•Broker-Subscriber–Subscriber处理消息结束后回应处理结果稳定性•监视–Broker内存使用–消息收发功能–消息堆积情况–存储的插入速度–各个任务队列长度–其他各项即时统计数据等•控制–自劢移除失效存储节点–优雅降级的控制–添加新存储节点–添加新Broker高性能•KISS–采用能够满足需求的尽量简单的方案来实现–例如：基于消息属性的过滤的实现•SEDA–Broker的内部处理流水线化，分为多个阶段来进行•LocalCache–降低对于存储节点的压力•采用DB作为存储时的优化限制•有可能产生重复消息•对订阅者的要求–幂等性f(f(x))=f(x)–重复调用多次产生的业务结果与调用一次产生的业务结果相同什么时候需要引入消息中间件•解除应用组件的紧密耦合–可扩展性–可用性•提高应用的响应时间•可靠的异步调用淘宝消息中间件产品•Notify–支持事务–完善的重试机制–实时性高•Metamorphosis–消息都是持久的，保存在磁盘–吞吐量第一–消费状态保存在客户端–支持消息顺序–生产者、服务器和消费者都可分布淘宝消息中间件产品NotifyMetamorphosis模型PushPull服务端消息存储处理请求保存推送轨迹保存订阅关系消费者负载均衡集中式消息存储处理请求分布式客户端处理响应和请求处理响应和请求保存pull状态，如拉取位置的偏移量offset异常情况下的消息暂存和recover实时性较好，收到数据后可立即发送给客户端取决于pull的间隔时间消费者故障消费者故障情况下，服务端堆积消息，重复推送耗费资源。保存推送轨迹压力很大。消费者故障，对服务端无影响其他对消息推送有更多控制，能实现多样化的推送机制。当消费者数量增多的时候，推送压力大，性能天花板。消费者处理能力差异，导致堆消息需要在客户端实现消息过滤，浪费资源。需要在不同客户端之间协调，做负载均衡。总结•具有互联网特征的消息中间件–消息发送和业务操作的一致性–订阅者集群–扩展性–可靠性–稳定性–高性能•限制–有可能产生重复消息进一步了解•Notify–•Metamorphosis–