中间件技术及双十一实践·消息中间件篇

标签: 产品和系列专题 | 发表时间:2014-03-05 09:08 | 作者:jm
出处:http://jm-blog.aliapp.com

消息中间件——分布式消息的广播员

综述

消息中间件是一种由消息传送机制或消息队列模式组成的最典型的中间件技术。通过消息中间件,应用程序或组件之间可以进行可靠的异步通讯来降低系统之间的耦合度,从而提高整个系统的可扩展性和可用性。

3.1、Notify

Notify是淘宝自主研发的一套消息服务引擎,是支撑双11最为核心的系统之一,在淘宝和支付宝的核心交易场景中都有大量使用。消息系统的核心作用就是三点:解耦,异步和并行。下面让我以一个实际的例子来说明一下解耦异步和并行分别所代表的具体意义吧:

假设我们有这么一个应用场景,为了完成一个用户注册淘宝的操作,可能需要将用户信息写入到用户库中,然后通知给红包中心给用户发新手红包,然后还需要通知支付宝给用户准备对应的支付宝账号,进行合法性验证,告知sns系统给用户导入新的用户等10步操作。
那么针对这个场景,一个最简单的设计方法就是串行的执行整个流程,如图3-1所示:
图3-1-用户注册流程.jpg
图3-1-用户注册流程

这种方式的最大问题是,随着后端流程越来越多,每步流程都需要额外的耗费很多时间,从而会导致用户更长的等待延迟。自然的,我们可以采用并行的方式来完成业务,能够极大的减少延迟,如图3-2所示。

图3-2-用户注册流程-并行方式
图3-2-用户注册流程-并行方式

但并行以后又会有一个新的问题出现了,在用户注册这一步,系统并行的发起了4个请求,那么这四个请求中,如果通知SNS这一步需要的时间很长,比如需要10秒钟的话,那么就算是发新手包,准备支付宝账号,进行合法性验证这几个步骤的速度再快,用户也仍然需要等待10秒以后才能完成用户注册过程。因为只有当所有的后续操作全部完成的时候,用户的注册过程才算真正的“完成”了。用户的信息状态才是完整的。而如果这时候发生了更严重的事故,比如发新手红包的所有服务器因为业务逻辑bug导致down机,那么因为用户的注册过程还没有完全完成,业务流程也就是失败的了。这样明显是不符合实际的需要的,随着下游步骤的逐渐增多,那么用户等待的时间就会越来越长,并且更加严重的是,随着下游系统越来越多,整个系统出错的概率也就越来越大。

通过业务分析我们能够得知,用户的实际的核心流程其实只有一个,就是用户注册。而后续的准备支付宝,通知sns等操作虽然必须要完成,但却是不需要让用户等待的。
这种模式有个专业的名词,就叫最终一致。为了达到最终一致,我们引入了MQ系统。业务流程如下:

主流程如图3-3所示:

图3-3-用户注册流程-引入MQ系统-主流程
图3-3-用户注册流程-引入MQ系统-主流程

异步流程如图3-4所示:

图3-4-用户注册流程-引入MQ系统-异步流程
图3-4-用户注册流程-引入MQ系统-异步流程

核心原理

Notify在设计思路上与传统的MQ有一定的不同,他的核心设计理念是
1. 为了消息堆积而设计系统
2. 无单点,可自由扩展的设计

下面就请随我一起,进入到我们的消息系统内部来看看他设计的核心原理

  • 为了消息堆积而设计系统在市面上的大部分MQ产品,大部分的核心场景就是点对点的消息传输通道,然后非常激进的使用内存来提升整体的系统性能,这样做虽然标称的tps都能达到很高,但这种设计的思路是很难符合大规模分布式场景的实际需要的。
    在实际的分布式场景中,这样的系统会存在着较大的应用场景瓶颈,在后端有大量消费者的前提下,消费者出现问题是个非常常见的情况,而消息系统则必须能够在后端消费不稳定的情况下,仍然能够保证用户写入的正常并且TPS不降,是个非常考验消息系统能力的实际场景。
    也因为如此,在Notify的整体设计中,我们最优先考虑的就是消息堆积问题,在目前的设计中我们使用了持久化磁盘的方式,在每次用户发消息到Notify的时候都将消息先落盘,然后再异步的进行消息投递,而没有采用激进的使用内存的方案来加快投递速度。
    这种方式,虽然系统性能在峰值时比目前市面的MQ效率要差一些,但是作为整个业务逻辑的核心单元,稳定,安全可靠是系统的核心诉求。
  • 无单点,可自由扩展的设计

图3-5-Notify系统组成结构
图3-5-Notify系统组成结构

图3-5展示了组成Notify整个生态体系的有五个核心的部分。

  • 发送消息的集群这主要是业务方的机器,这些APP的机器上是没有任何状态信息的,可以随着用户请求量的增加而随时增加或减少业务发送方的机器数量,从而扩大或缩小集群能力。
  • 配置服务器集群(Config server)这个集群的主要目的是动态的感知应用集群,消息集群机器上线与下线的过程,并及时广播给其他集群。如当业务接受消息的机器下线时,config server会感知到机器下线,从而将该机器从目标用户组内踢出,并通知给notify server,notify server 在获取通知后,就可以将已经下线的机器从自己的投递目标列表中删除,这样就可以实现机器的自动上下线扩容了。
  • 消息服务器(Notify Server)消息服务器,也就是真正承载消息发送与消息接收的服务器,也是一个集群,应用发送消息时可以随机选择一台机器进行消息发送,任意一台server 挂掉,系统都可以正常运行。当需要增加处理能力时,只需要简单地增加notify Server就可以了
  • 存储(Storage)Notify的存储集群有多种不同的实现方式,以满足不同应用的实际存储需求。针对消息安全性要求高的应用,我们会选择使用多份落盘的方式存储消息数据,而对于要求吞吐量而不要求消息安全的场景,我们则可以使用内存存储模型的存储。自然的,所有存储也被设计成了随机无状态写入存储模型以保障可以自由扩展。
  • 消息接收集群业务方用于处理消息的服务器组,上下线机器时候也能够动态的由config server 感知机器上下线的时机,从而可以实现机器自动扩展。

3.2、Notify双11准备与优化

在双11的整个准备过程中,Notify都承载了非常巨大的压力,因为我们的核心假定就是后端系统一定会挂,而我们需要能够承载整个交易高峰内的所有消息都会堆积在数据库内的实际场景。
在多次压测中,我们的系统表现还是非常稳定的,以60w/s的写入量堆积4.5亿消息的时候,整个系统表现非常淡定可靠。在真正的大促到来时,我们的后端系统响应效率好于预期,所以我们很轻松的就满足了用户所有消息投递请求,比较好的满足了用户的实际需要。

3.3、MetaQ

METAQ是一款完全的队列模型消息中间件,服务器使用Java语言编写,可在多种软硬件平台上部署。客户端支持Java、C++编程语言,已于2012年3月对外开源,开源地址是: http://metaq.taobao.org/。MetaQ大约经历了下面3个阶段

  • 在2011年1月份发布了MetaQ 1.0版本,从Apache Kafka衍生而来,在内部主要用于日志传输。
  • 在2012年9月份发布了MetaQ 2.0版本,解决了分区数受限问题,在数据库binlog同步方面得到了广泛的应用。
  • 在2013年7月份发布了MetaQ 3.0版本,MetaQ开始广泛应用于订单处理,cache同步、流计算、IM实时消息、binlog同步等领域。MetaQ3.0版本已经开源, 参见这里

综上,MetaQ借鉴了Kafka的思想,并结合互联网应用场景对性能的要求,对数据的存储结构进行了全新设计。在功能层面,增加了更适合大型互联网特色的功能点。

MetaQ简介

图3-6-MetaQ整体结构

如图3-6所示,MetaQ对外提供的是一个队列服务,内部实现也是完全的队列模型,这里的队列是持久化的磁盘队列,具有非常高的可靠性,并且充分利用了操作系统cache来提高性能。

  • 是一个队列模型的消息中间件,具有高性能、高可靠、高实时、分布式特点。
  • Producer、Consumer、队列都可以分布式。
  • Producer向一些队列轮流发送消息,队列集合称为Topic,Consumer如果做广播消费,则一个consumer实例消费这个Topic对应的所有队列,如果做集群消费,则多个Consumer实例平均消费这个topic对应的队列集合。
  • 能够保证严格的消息顺序
  • 提供丰富的消息拉取模式
  • 高效的订阅者水平扩展能力
  • 实时的消息订阅机制
  • 亿级消息堆积能力

MetaQ存储结构

MetaQ的存储结构是根据阿里大规模互联网应用需求,完全重新设计的一套存储结构,使用这套存储结构可以支持上万的队列模型,并且可以支持消息查询、分布式事务、定时队列等功能,如图3-7所示。

图3-7-MetaQ存储体系
图3-7-MetaQ存储体系

MetaQ单机上万队列

MetaQ内部大部分功能都靠队列来驱动,那么必须支持足够多的队列,才能更好的满足业务需求,如图所示,MetaQ可以在单机支持上万队列,这里的队列全部为持久化磁盘方式,从而对IO性能提出了挑战。MetaQ是这样解决的

  • Message全部写入到一个独立的队列,完全的顺序写
  • Message在文件的位置信息写入到另外的文件,串行方式写。

通过以上方式,既做到数据可靠,又可以支持更多的队列,如图3-8所示。

图3-8-MetaQ单机上万队列
图3-8-MetaQ单机上万队列

MetaQ与Notify区别

  • Notify侧重于交易消息,分布式事务消息方面。
  • MetaQ侧重于顺序消息场景,例如binlog同步。以及主动拉消息场景,例如流计算等。

3.4、MetaQ双11准备与优化

  • Notify 交易消息转 MetaQ 方案改进
    MetaQ 交易集群主要是 Notify 交易消息的一个镜像,旧有的方案是通过 Notify-Client 订阅 Notify 交易消息,然后再转投到 MetaQ 集群,这个方案的缺点:1. 通过消息订阅的方式给 Notify 集群带来比较大的压力 2. 一旦 MetaQ 集群处理不及时会给 Notify 造成消息的堆积,从而带来连锁不良效应。新的方案则是从Notify DB直接拉取binlog到MetaQ,它带来的优势: 1. 解放 NotifyServer 集群的压力;2. 通过 binlog 批量处理可以提升系统的吞吐量。
  • 交易集群低延迟优化
    天猫直播间,旨在通过实时获取活动当天的交易数据,通过实时流计算的方式,及时、准确的展示各业务数据。它的特点就是数据全而准确、实时性要求较高。而在全链路压测过程中发现从 Notify Mysql binlog 获取数据时,出现较大的延迟,最严重的延迟高达4h+,这显然是不合系统需求的。基于这些问题,我们在 Notify Mysql 端做了很多的优化:

    1. Mysql 数据库实例扩容,从而提高集群的整体吞吐量;
    2. 对 binlog 的存放位置进行优化,将数据存储以及 binlog 存储进行分离,从而发挥 DB 的最大写性能;
    3. 由于 MySQL 的 binlog 操作存在锁操作,优化了 MySQL 生成 binlog 的配置,保证了拉 binlog 无延时。
  • 针对不同集群运行参数调优
    根据业务的特点,对不同集群的运行参数调优,如批量拉取大小,刷盘方式,数据有效期等等;同时对io调度、虚拟内存等参数进行调优,以提供更为高效的堆积。
  • 监控与实时告警
    任何一个值得信赖的系统,最低限度是需要做到及时发现并处理异常,在第一时间排除故障发生的可能,从而提高产品的可用性。在双十一活动之前,我们实现了由 MetaQ 系统内部,根据集群状态,各消息的业务数据指标进行监控统计并主动告警,同时还能通过 Diamond 做到动态调整,从而提高监控的及时性以及灵活性。

回顾双十一活动当日,淘宝消息写入总量112亿,消息投递总量220亿,支付宝消息写入总量24亿,消息投递总量24亿。其中实时直播间集群消息写入峰值为13.1w,消息投递峰值为27.8w。

从总体上看,我们的前期准备还是比较充分的,MetaQ 各集群在高峰期表现稳定,全天表现很平稳,个别订阅组对消息进行重溯,部分消息有少量的堆积,但都没有对系统造成影响,效果还是非常好的。75%的交易在聚石塔上完成,实时直播间交易统计延迟在1s左右,加减库存做到零超卖。

小结

目前分布式消息中间件产品已经服务于整个集团,支持了阿里集团各个公司的500多个业务应用系统。每日处理海量消息超350亿次,保证所有交易数据高可靠,高性能,分布式事务处理,是中间件团队最老牌的中间件产品之一。

 

 

系列文章:

中间件技术及双十一实践之中间件总体介绍http://jm-blog.aliapp.com/?p=3359

中间件技术及双十一实践之软负载篇http://jm-blog.aliapp.com/?p=3450

中间件技术及双十一实践·服务框架篇http://jm-blog.aliapp.com/?p=3462

中间件技术及双十一实践·EagleEye篇http://jm-blog.aliapp.com/?p=3465

《中间件技术及双十一实践·消息中间件篇》http://jm-blog.aliapp.com/?p=3483

 

如果觉得内容还行,请分享给更多的人…

转发:中间件技术及双十一实践之中间件总体介绍

转发:中间件技术及双十一实践之软负载篇

转发:中间件技术及双十一实践·服务框架篇

转发:中间件技术及双十一实践·EagleEye篇

转发:中间件技术及双十一实践·消息中间件篇

相关 [中间件 技术 双十一] 推荐:

中间件技术及双十一实践·中间件总体介绍

- - 阿里中间件团队博客
本文发表在《程序员》2014年1月刊:11.11背后的技术 http://www.csdn.net/article/2013-12-23/2817882. 阿里巴巴中间件与稳定性平台团队,是一个给业务应用团队以提供低成本,高可用,可扩展的弹性互联网系统解决方案为己任的技术团队,前身是成立于7年之前的淘宝平台架构部,而后随着业务领域,尤其是针对性能和稳定性技术领域的成功探索与突破,目前已经发展为一个涵盖消息通信,数据处理,性能优化和稳定性等各类技术的互联网架构服务平台.

中间件技术及双十一实践·消息中间件篇

- - 阿里中间件团队博客
消息中间件——分布式消息的广播员. 消息中间件是一种由消息传送机制或消息队列模式组成的最典型的中间件技术. 通过消息中间件,应用程序或组件之间可以进行可靠的异步通讯来降低系统之间的耦合度,从而提高整个系统的可扩展性和可用性. Notify是淘宝自主研发的一套消息服务引擎,是支撑双11最为核心的系统之一,在淘宝和支付宝的核心交易场景中都有大量使用.

中间件技术及双十一实践·数据篇

- - 阿里中间件团队博客
数据层——分布式数据存储的桥梁. 大型互联网架构中,数据存储会面临读写容量瓶颈问题,像淘宝双十一活动,核心数据存储集群读写日访问量可以达到100亿以上,在这种场景下,单机数据库方式必定面临极大挑战,类似的场景也在一些传统使用IOE的企业中成为一种制约业务发展的致命要素. 而在阿里集团内,TDDL体系就是解决此种场景的利器, 这个体系是基于廉价pc和开源mysql、以客户端依赖方式、分库分表为主要手段、集中化数据库配置等几个关键要素构建起来, 成为阿里集团接入mysql的标准,提供整个集团上千个应用的数据库访问.

中间件技术及双十一实践·稳定性平台篇

- - 阿里中间件团队博客
稳定性平台——系统稳定运行的保障者. 大多数互联网公司都会根据业务对自身系统做一些拆分,大变小,1变n,系统的复杂度也n倍上升. 当面对几十甚至几百个应用的时候,再熟悉系统的架构师也显得无能为力. 稳定性平台从2011年就开始了依赖治理方面的探索,目前实现了应用级别和接口级别的依赖自动化治理. 在2013的双11稳定性准备中,为共享交易链路的依赖验证和天猫破坏性测试都提供了支持,大幅度减小了依赖治理的成本和时间.

中间件技术及双十一实践·应用服务器篇

- - 阿里中间件团队博客
应用服务器——系统运行的托管员. 阿里巴巴集团有国内最大规模的Java系统,几万台的应用服务器规模也空前庞大,目前主要使用的应用服务器有Tomcat,JBoss和Jetty三种. 阿里巴巴自从2004年开始转向Java技术平台后,先后经历了从WebLogic到Jboss和Tomcat迁移. 到了2008年,随着更为轻量级的Tomcat和Jetty容器的迅速发展,越来越多的应用系统开始尝试使用Tomcat或Jetty作为底层应用服务器.

阿里双十一数据库技术

- - Hello Database
真的很抱歉,我的博客已经很久没有更新了,因为花了太多的时间在微博和微信上,当然最主要的原因还是工作实在太忙了,仅剩的那点业余时间都用来陪娃了. 从2012年开始,工作重心转移到了淘宝和天猫,我的技术方向也发生了改变,2012年和2013年,经历了两次双十一,在这个过程中学到了很多东西. 尤其是2013年的双十一,系统准备的非常充分,技术上有很多创新,团队也得到了成长.

女人们,这些技术男真的被“双十一”逼“疯”了!

- - 博客园_新闻
每到“双十一”都是女人购物狂欢日,你家女人是不是都守到电脑前、手机上抢到手抖. 可是你有没有想过,这里面支撑这么多人疯狂购物的技术系统码农们都是怎么过的. 前些日子遇到了淘宝的一个技术小二庄卓然(南天),听他嘚啵嘚啵他那些被“双十一”逼疯的事,很有感触起来. 他和他的技术小二团队,是马云主动求合照的怪咖;是在辣妹热舞面前,也要忙着秒单的“死技术男”;婚礼当晚不是洞房,是赶回杭州加班“双十一”;在“双十一”让老婆怀上了孩子,还抽烟、喝红牛⋯⋯;因为一个系统错误,差点被逼得跳下 23 楼.

消息中间件的技术选型心得-RabbitMQ、ActiveMQ和ZeroMQ

- - haohtml's blog
RabbitMQ、ActiveMQ和ZeroMQ都是极好的消息中间件,但是我们在项目中该选择哪个更适合呢. 下面我会对这三个消息中间件做一个比较,看了后你们就心中有数了. RabbitMQ是AMQP协议领先的一个实现,它实现了代理(Broker)架构,意味着消息在发送到客户端之前可以在中央节点上排队.

mycat 数据库中间件

- - Oracle - 数据库 - ITeye博客
出处:http://blog.csdn.net/nxw_tsp/article/details/56277430. 实习的时候,在一个项目当中,项目经理要求把原先的MySQL数据连接基于mycat来进行改造. 当时就在想MyCat是什么东西. MyCat是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里.

淘宝双十一架构优化及应急预案

- - InfoQ cn
 每年的双十一,在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去IOE带来整体的扩展性和成本的控制能力. 今年在架构上做的比较大的优化有三点:. 第一是导购系统的静态化改造. 今年淘宝和天猫都分别根据自身的业务特性进行了Detail页面的静态化改造,但核心的思路都是通过CDN+nginx+JBoss+缓存的架构,将页面信息进行静态化缓存.