大规模消息系统的架构设计.pptVIP

大规模消息系统的架构设计 业务为核心的架构 黄冬 huangdong@ 八年 完美的JMS 现实的业务 近五千万用户使用数百项服务 单项服务（订阅）用户达到三千万 移动网关的流出速度仅为数千条/秒 不同的省、不同的网关速度不同 业务与服务有着完全不同的优先级 一起来说说解决方案？！ 2002年的事 2002年的容量 单日发送量过千万 订购关系过千万项 9台服务器 2009年的重构 SD的数据库化（读写分离） TD缓冲区内存化 接收与发送分离 Task支持 2009年的容量 单日发送过四千万 订购关系过五千万 4台服务器 沉淀 让数据靠近CPU 缓冲池的内存化 队列的内存遍历 慢I/O是应用的杀手 消减重复的计算 集合共性，消息包而不是单条消息 Task 重复做相同的事是愚蠢的，即使它是计算机 让计算前置 Route ID的计算 Task 事情总是越早干完越好，路总是越近越轻松 更多... 成熟的协议有很多 长连接（HTTP 1.1） /Protocols/rfc2616/rfc2616-sec8.html#sec8 异步并发（MSN、ISO 8583） /docs/msn/ietf_draft.txt /wiki/ISO_8583 网络能做到更多 二层（CARP） 三层（OSPF） 四层（TCP） 七层（HTTP、SMTP） 优秀产品的核心 水泥+鼠标 软件+运营 代码+系统 谢谢 1.最简单的消息传送操作。MyQueueSender 向队列目标 MyQueue1 发送 Msg1。然后，MyQueueReceiver 从 MyQueue1 获得该消息。 2.一个更为复杂的点对点消息传送图，以说明该域中的可能情况。两个发送者 MyQSender1 和 MyQSender2 使用同一连接向 MyQueue1 发送消息。MyQSender3 使用另一连接向 MyQueue1 发送消息。在接收端，MyQReceiver1 使用 MyQueue1、MyQReceiver2 和 MyQReceiver3 中的消息，共享一个连接以使用 MyQueue1 中的消息。 多个生成方可向一个队列发送消息。生成方可共享连接或使用不同连接，但它们均可访问同一队列。 多个接收者可使用一个队列中的消息，但每条消息只能由一个接收者使用。所以，Msg1、Msg2 和 Msg3 由不同接收者使用。（这是对 Message Queue 的扩展。） 接收者可共享连接或使用不同连接，但它们均可访问同一队列。（这是对 Message Queue 的扩展。） 发送者和接收者之间不存在时间上的相关性：客户端发送一条消息后，无论接收者是否正在运行，都能取出该消息。 可在运行时动态添加和删除发送者和接收者，这样，即可根据需要扩展或收缩消息传送系统。 消息在队列中的放置顺序与发送顺序相同，但它们的使用顺序则取决于消息失效期、消息优先级以及使用消息时是否使用选择器等因素。 3.虽然发布/订阅模型不需要存在多个订户，但图中显示了两个订户，这是为了强调在该域中可以广播消息。一个主题的所有订户均可获得发布到该主题的任何消息的副本。订户可以是非长期的，也可以是长期的。代理会为所有活动订户保留消息，但对于非活动订户，则只为那些长期订户保留消息。 4.更为复杂的发布/订阅消息传送图，以说明该模式提供的可能情况。多个生成方向 Topic1 目标发布消息。多个订户使用来自 Topic1 目标的消息。除非订户使用选择器来过滤消息，否则每个订户均可获得发布到所选主题的所有消息。 多个生成方可向一个主题发布消息。生成方可共享连接或使用不同连接，但它们均可访问同一主题。 多个订户可使用一个主题中的消息。订户可检索发布到一个主题中的所有消息，除非它们使用选择器过滤掉消息或消息在使用之前已过期。 订户可共享连接或使用不同连接，但它们均可访问同一主题。 长期订户可能处于活动状态，也可能处于非活动状态。在它们处于非活动状态时，代理会为它们保留消息。 可在运行时动态添加和删除发布者和订户，这样，即可根据需要扩展或收缩消息传送系统。 消息发布到主题的顺序与发送顺序相同，但它们的使用顺序则取决于消息失效期、消息优先级以及使用消息时是否使用选择器等因素。 发布者与订户之间存在时间上的相关性：主题订户只能使用在它创建订阅后发布的消息。 系统接收消息处理流程： 1.由外部系统发送到TD（或由一个TD连接到外部系统取来），TD将其存入TD的缓存中。 2.由AD对缓存中的消息进行分析，得到它的回程路由信息（RID），并算出它的去向路由信息（RID）。 3.依据去向路由信息，将消息中转到目标的TD（它处理将此消息发送给此消息应对的PD）待发送缓冲中。 3.由TD将消息交送给它对应的PD进行消息处理工作。 4.PD对消息进