导读：应对高可用及极端峰值，每个技术团队都有自己的优秀经验，但是这些方法远没有得到体系化的讨论。高可用架构在6月25日举办了『高压下的架构演进』专题活动，进行了闭门私董会研讨及对外开放的四个专题的演讲，期望能促进业界对应对峰值的方法及工具的讨论，本文是去哪儿网余昭辉介绍设计电商消息中间件的设计经验。
余昭辉，去哪儿网基础架构部架构师，年加入去哪儿网，经历过去哪儿网从小到壮大，服务拆分的过程。现负责去哪儿网基础架构部，参与设计和开发去哪儿大大小小各种基础组件。本人对互联网电商中间件，并发和异步编程尤为感兴趣，是一个自我标榜ClanCodr。热衷于与同行技术交流。
我来自去哪儿的基础架构部，我们部门负责公司的公共组件和基础服务，包括敏感信息存储、发号器、身份证认证、监控中心、任务调度、Rdis等。
今天主要给大家分享一下消息队列基础组件的设计。
我们是年初开始自研消息队列和消息中间件的，当时也是契合公司背景，原来公司有一些庞大的单模块系统，如机票交易系统和酒店交易系统等。为了对系统进行拆分，面临着系统拆分之后事务处理的问题，于是自研了消息中间件。（小编：上文滴滴passport设计之道:帐号体系高可用的7条经验也多次提到了大系统做小的经验与实践，感兴趣的读者可以参阅）现在去哪儿网基本所有交易环节都通过消息的方式流转，使用了一种消息驱动的架构，像订单的流转、支付等，消息中间件已经成为核心基础设施，对交易系统非常关键。最初设计消息中间件是为了满足交易场景，后来大家觉得API使用非常方便，现在其他业务包括部分搜索等等功能也切到这个上面来。
截止目前，除了部分搜索场景是AMQ，公司其他业务的都使用了自研的消息中间件，一些基本数据如下：
承载公司1万多个subjct平均接收消息量QPS12万+峰值QPS50万最多的一个消息subjct有个消费组来消费消息中间件模型说简单也很简单，最小单元就是一条消息，所以伸缩、扩展非常容易，只要根据消息进行hash。当中间件承受不住压力的候，扩展是非常简单的。另外一方面说它复杂也很复杂，消息中间件作为一个公司的基础组件，如果它出问题就是一个很严重的事情。消息中间件出一次故障，就是6~7个部门报P1故障。这便是它的复杂所在，如何保证它的正常运行，那么在介绍内容之前，先说明一下上下文：今天讲的仅仅是适用交易环节的消息中间件，跟通常所说的社交领域的消息中间件有很大的不同。在交易环节，需要考虑3个方面：不能丢消息。丢消息意味着掉单，意味着支付成功但是没给人家出票，这是不能接受的。
稳定。消息中间件一旦出问题，交易不能进行，也是严重的故障。
性能。
在电商的场景前面两条要高于性能要求，也是今天要重点讨论的部分。
典型的消息中间件包含3部分：producr（发布者）、brokr（消息中间件）、consumr（消费者），是一个比较简单的模型，下图展示了把消息发送给consumr的全过程。
Producr发布端设计
Producr消息发布端主要北京白癜风的权威专家北京白癜风医院
