标签:https tor 消息发送 情况 apache ons logs href 技术
Notify是淘宝自主研发的一套消息服务引擎,是支撑双11最为核心的系统之一,在淘宝和支付宝的核心交易场景中都有大量使用。消息系统的核心作用就是三点:解耦,异步和并行。下面让我以一个实际的例子来说明一下解耦异步和并行分别所代表的具体意义吧:
假设我们有这么一个应用场景,为了完成一个用户注册淘宝的操作,可能需要将用户信息写入到用户库中,然后通知给红包中心给用户发新手红包,然后还需要通知支付宝给用户准备对应的支付宝账号,进行合法性验证,告知sns系统给用户导入新的用户等10步操作。
那么针对这个场景,一个最简单的设计方法就是串行的执行整个流程,如图3-1所示:
图3-1-用户注册流程
这种方式的最大问题是,随着后端流程越来越多,每步流程都需要额外的耗费很多时间,从而会导致用户更长的等待延迟。自然的,我们可以采用并行的方式来完成业务,能够极大的减少延迟,如图3-2所示。
图3-2-用户注册流程-并行方式
但并行以后又会有一个新的问题出现了,在用户注册这一步,系统并行的发起了4个请求,那么这四个请求中,如果通知SNS这一步需要的时间很长,比 如需要10秒钟的话,那么就算是发新手包,准备支付宝账号,进行合法性验证这几个步骤的速度再快,用户也仍然需要等待10秒以后才能完成用户注册过程。因 为只有当所有的后续操作全部完成的时候,用户的注册过程才算真正的“完成”了。用户的信息状态才是完整的。而如果这时候发生了更严重的事故,比如发新手红 包的所有服务器因为业务逻辑bug导致down机,那么因为用户的注册过程还没有完全完成,业务流程也就是失败的了。这样明显是不符合实际的需要的,随着 下游步骤的逐渐增多,那么用户等待的时间就会越来越长,并且更加严重的是,随着下游系统越来越多,整个系统出错的概率也就越来越大。
通过业务分析我们能够得知,用户的实际的核心流程其实只有一个,就是用户注册。而后续的准备支付宝,通知sns等操作虽然必须要完成,但却是不需要让用户等待的。 这种模式有个专业的名词,就叫最终一致。为了达到最终一致,我们引入了MQ系统。业务流程如下:
主流程如图3-3所示:
图3-3-用户注册流程-引入MQ系统-主流程
异步流程如图3-4所示:
图3-4-用户注册流程-引入MQ系统-异步流程
核心原理
Notify在设计思路上与传统的MQ有一定的不同,他的核心设计理念是
1. 为了消息堆积而设计系统
2. 无单点,可自由扩展的设计
下面就请随我一起,进入到我们的消息系统内部来看看他设计的核心原理
图3-5-Notify系统组成结构
图3-5展示了组成Notify整个生态体系的有五个核心的部分。
METAQ是一款完全的队列模型消息中间件,服务器使用Java语言编写,可在多种软硬件平台上部署。客户端支持Java、C++编程语言,已于2012年3月对外开源,开源地址是: http://metaq.taobao.org/ 。MetaQ大约经历了下面3个阶段
综上,MetaQ借鉴了Kafka的思想,并结合互联网应用场景对性能的要求,对数据的存储结构进行了全新设计。在功能层面,增加了更适合大型互联网特色的功能点。
MetaQ简介
图3-6-MetaQ整体结构
如图3-6所示,MetaQ对外提供的是一个队列服务,内部实现也是完全的队列模型,这里的队列是持久化的磁盘队列,具有非常高的可靠性,并且充分利用了操作系统cache来提高性能。
MetaQ存储结构
MetaQ的存储结构是根据阿里大规模互联网应用需求,完全重新设计的一套存储结构,使用这套存储结构可以支持上万的队列模型,并且可以支持消息查询、分布式事务、定时队列等功能,如图3-7所示。
图3-7-MetaQ存储体系
MetaQ单机上万队列
MetaQ内部大部分功能都靠队列来驱动,那么必须支持足够多的队列,才能更好的满足业务需求,如图所示,MetaQ可以在单机支持上万队列,这里的队列全部为持久化磁盘方式,从而对IO性能提出了挑战。MetaQ是这样解决的
通过以上方式,既做到数据可靠,又可以支持更多的队列,如图3-8所示。
图3-8-MetaQ单机上万队列
MetaQ与Notify区别
标签:https tor 消息发送 情况 apache ons logs href 技术
原文地址:https://www.cnblogs.com/caijindou/p/13371579.html