`
xinklabi
  • 浏览: 1590858 次
  • 性别: Icon_minigender_1
  • 来自: 吉林
文章分类
社区版块
存档分类
最新评论

可靠消息队列浅谈

 
阅读更多

转自:http://www.open-open.com/lib/view/open1429583249182.html

综述

消息队列系统是大型分布式系统中常见的组成部分之一,目前市面上也已经出现了大量非常优秀的消息队列或者具有消息队列特征的数据流系统,它们各自有各自的特点,却也同样会有自己的不足,在某些特定的应用场景下,既有的消息队列用起来总是欠那么点火候,这也是为什么redis作者也在写一个全新的消息队列系统的原因。本文的写作目的,不是为了讨论市面上已有消息队列的优缺点,更不是为造轮子洗地,而只是从一个实际需求出发,完整地记录我是如何从零开始实现一个自己用着顺手的消息队列系统的过程。如果我所做的这个东西刚好戳中了你的痛点,欢迎尝试使用并提出自己的意见和建议。

目标

新浪和微博有大量系统严重依赖于我们老大@stvchu 所写的memcacheQ,mcq 已经在大量线上业务中服务了好多年,其性能和稳定性无需置疑。我们组开发维护的图片存储和视频存储系统,也都是依靠mcq进行消息同步的。在多年的使用中,渐渐暴露出来一些可靠性和易用性上的不足,于是我们计划开发一款全新的消息队列,既保留mcq的优点,又能满足一些新的需求。

  1. 可靠性

    目前的mcq是单点的,一旦一台mcq服务器故障,所有队列的消息都将丢失。由于mcq非常稳定,目前并没有这样的事故发生,尽管如此,我们还是希望能够从根本上杜绝这种情况,开发一个可靠性非常高的消息队列,无需为单点问题担忧。

  2. 多条消费者队列

    在mcq中,一个消息入队之后,消费者只能从队列里取出来一次,在某些场景下,一个消息可能需要被多个消费者系统消费,比如微博图片传上来之后,需要被压缩系统拿来进行压缩,同时还要被分类系统拿去进行分类,还会被审核系统拿去审查,等等。目前的做法是,一个消费者先从队列里拿到消息,处理完之后再重新入队,这样其他系统就可以继续拿出来消费。弊端是将一个并行的任务生生做成了串行,而且更严重的是,一旦某个消费者系统拿了消息之后发生故障,未能将消息塞回来,那么后续的消费者就无法处理这个消息了。

    因此我们的一个目标是支持多个消费者队列,它们之间互不影响,各自消费各自队列里的消息。

  3. 消息确认和重新入队

    消息确认也是保证消息可靠性的一个重要方面,目前mcq并不支持消息确认机制。试想一个消息被某个消费者拿走之后,还没来得及处理,这个消费者系统就挂了,那么这个消息就丢失了,任何其他消费者都无法对它进行处理。之前看到别的部门同事介绍这种问题的处理方案,他们自己又开发了一个模块,从mcq里拿到消息之后如果长时间没有处理好,就重新写入mcq中,也是挺不方便的。

    所以我们的新系统中,必须支持消息确认机制,未确认的消息一段时间之后将会自动重新进入队列中,无需使用者操心。

开发过程

接到这个项目是去年11月份,本以为只是一个简单的东西很快就能搞完,没想到最后越搞越复杂,一直到春节过后才找到靠谱的方案,最近才开发完成。

  1. 基于raft协议的可靠性消息队列Express

    为了达到上面列出的第一个目标,我们选择了在消息队列系统中引入raft一致性协议进行消息同步,简单地说,我们的系统一次起N个实例,客户端可以连到任意一个实例上进行入队和出队操作,只要集群中有N/2+1个节点存活且确认拿到消息,即可认为消息处理成功;即使有少部分实例挂掉,系统依然可以对外提供服务;当挂掉的这些实例重启或者新加入几个实例之后,它们也可以自动同步到最新的状态,然后继续对外服务。

    在数据库领域谈可用性、一致性之类的问题已经谈了很多年,大家都觉得raft已经是论文论证过,工业可用,而且比paxos简单一万倍的东西,应该是很好实现的,包括我自己也这么想。然而理想很丰满,现实很骨干,消息队列的应用场景跟数据库是完全不同的,引入raft一个最大的问题就是处理能力严重不足!

    MQ这种东西,本来就是解决生产者和消费者速度不匹配的问题而诞生的,那么MQ系统一个最最基本的要求就是写入速度必须要快,哪怕出队速度慢点也无所谓,因为业务高峰期持续时间是有限的,高峰结束之后有的是时间让消费者慢慢消化,更别说简单粗暴多加几台消费者就好了。而一旦引入raft一致性协议,每个消息都要等半数以上的express实例确认之后才能返回成功,延时非常之高!要达到50ms左右(这个延时可以通过设置raft heartbeat来降低,但同时会提高系统负载,效果不明显)。

    再加上,MQ系统在队列堵塞的时候,短时间内累积的消息数量非常之多,以峰值10亿条,每条消息200字节算,如果存在内存里,需要200GB的内存,对我们公司来说太奢者了,所以必须落地存储。而raft协议同步的基础是增量日志(WAL),这就导致每一个消息会带来两次磁盘写入,大家都知道磁盘 I/O是非常慢的操作,更进一步降低了系统入队速度。

    为了克服这个困难,我们一度改写了raft库对WAL的操作逻辑,将WAL同时作为我们MQ的落地存储模块,依靠记录log ID之类的方法,改写了raft生成snapshot时的操作流程,使得一个消息写入只会带来一次磁盘I/O。虽然提高了一点点性能,但是开发成本实在高得离谱。

    再后来我们发现导致延时高更重要的原因是多个实例之间同步消息过程。举例来说,集群入队一个消息需要50ms的话,实例之间通过raft库相互同步和确认就需要花掉40ms以上,与这样的消耗相比,上面说到的两次磁盘写操作根本不值一提。正在这个时候,etcd发布了它们的首个正式版本,并在博客中大肆吹嘘了一番他们自己开发的raft库,由于goraft优化无望,我们开始尝试使用etcd的raft库重新进行开发。

    这个过程按下不表,总之找到了一些捷径之后很快就实现了MQ的业务逻辑,进行测试之后性能也确实有较大改观,看来goraft真的是不行。考虑到上面分析的性能瓶颈所在的结论,和对etcd/raft进行改造带来的巨大工作量,我们改回了双写落地的方案,也并没有慢多少。

    到此时,关于可靠性这个目标已经实现了。但是不管怎么说,raft所带来的延时是无法避免的,即使是etcd本身,处理能力也就1000qps而已。最终结果就是,express只能用于我们自己的业务线上,因为我们更看重可靠/可用性,性能要求不是特别高。

  2. Topic(话题)和Line(消费线路)

    为了支持多条消费者队列,在express中,存在topic和line这两个概念。一个topic可以拥有多条line,所有的消息入队的目标是 topic,只需要入队一次;而消息出队只能从line里拿,每个line都有自己的名字,代表这条消费线路的具体用途,以图片上传举例:

    • 所有消息入队到名叫wb_img_upload的topic中
    • 压图模块从名叫img_to_compress的line中拿属于自己的消息并进行压缩
    • 同时,分类模块从名叫img_to_analysis的line中拿属于自己的消息并进行分类
    • 其他各种模块比如审核、统计等等,也从各自的line中拿消息,它们之间互不影响

    这种设计类似于nsq的topic和channel,但是nsq中为了使多个channel之间相互独立,采用复制消息的方案,也就是说,入队的消息,有几个channel就得多复制几次。而在express中,line里面其实只是存了消息的游标,实际消息还是存在topic中的,入队也只需要写入一次即可。

  3. 消息确认

    消息确认是针对line来说的,每条line在创建的时候就需要设定一个recycle(回收)时间,从line里拿走一个消息时,会同时得到该消息的ID,当你处理完之后,需要明确地告诉express以确认这条消息已经消费完毕,否则,超过recycle时间之后,该消息会重新加入到这条 line的消息队列中,可以被其他消费者再次消费。由于重新入队这个机制的存在,会打乱消息入队的顺序,甚至导致消息重复消费,从而引出时序性和幂等性的问题,这个我们在下一节进行探讨。

时序性和幂等性

消息队列系统的时序性也是一个常见的问题了,在某些场景下,我们确实需要非常严格的按时序排列的消息,比如微博的feed,当然是需要先入队的消息先展示,后入队的消息后展示。那么如果MQ本身是严格时序的,当然是最好了(其实对MQ来说也是最简单的了,比如mcq就是),但问题是,你可以保证MQ 按时间顺序出队,却无法保证消费者按时间顺序消费完毕啊。注意我说的是消费完毕,毕竟每个消费者遇到的情况都是不同的,总有干的快的也总有干的慢的。解决办法也很简单,在消息体内包含消息生成的时间即可,所有消息在需要展示的时候才按生成时间再排序,即可严格时序输出。

那么,实际上来说就是,真正保证时序性的,并不是消息队列,而是消费者!

除非有一种情况,消费者只有一个,所有出队的消息都由它来展示,那在消费者这一层面就不可能打乱消息顺序,只需要MQ按时序出队即可。以我目前贫瘠的知识量来看,这种场景是小作坊产品才会遇到的,根本不可能出现在需要解决流量高峰问题的互联网产品中;再者,如果只需要一个消费者就能顺序处理的话,你还有必要引入一个消息队列吗?当然,由于视野所限,这一段内容不一定正确,总之核心思想就是这种只有一个消费者的场景太罕见了,直接忽略掉算了。

接上面的结论继续说,由于严格时序性需要靠消费者这一层来保证,那么对于MQ来说,只需要在一定程度上保证时序性即可。为了能够实现消息确认和重入来保证消息不丢失,是不可能同时保证严格时序性的。事实上,redis作者Antirez在介绍他的disque时,也基本上是这么说的。

接下来说幂等性,MQ里的幂等性指的是一个消息如果被消费者多次消费,对于消费者来说效果应该是一样的。比如,用户上传了一张图片,这个图片需要被压图模块压缩成缩略图,压图服务器A取到了消息并压图完毕,但是在跟express确认消息的时候由于网络故障没成功,过了一段时间之后express让这条消息重新入队,压图服务器B又拿到了这个消息并压图完毕,这个时候,对于整个压图模块来说,是没有影响的,因为B压好的图,文件名和路径跟A之前压好的是完全一样的,只是把那个图覆盖了而已,用户依然可以看到,这就叫幂等消费者。

在某些消费者逻辑中,消息不是幂等的,重复处理同一个消息会造成数据错乱。这种情况下就不适合依靠MQ的消息重入机制来保证消息不丢了,而因该消费者自己制定策略。那么在express中创建line的时候,只需要设置recycle为空即可。

这儿再插入一块关于丢消息的内容。在我们的系统中,消息一旦被确认入队,就不可能丢失,因为入队时已经落地存储完成,只可能多次出队,这样的设计是为了最大程度保证消息不丢。而有些MQ并不能保证不丢消息,比如NSQ,有一部分消息是在内存里的,如果这时候NSQ宕机,消息就没了。这是速度和安全取舍的问题,并无优劣之分。

简化版本UQ

上面一大篇密密麻麻的文字,主要记录了我设计和实现一款基于raft的,非常可靠的消息队列系统express的过程。相信我们遇到的问题应该也戳中了很多同学的痛点。但是老实来说,保证了可靠性但损失了性能的express并不适合大家使用,因此我把express中关于队列的逻辑拆出来,只保留那些好用的功能,牺牲了高可用这一部分,做成一个新的持久化消息队列开源出来,取名UQ,希望有需要的朋友可以拿去试用:

https://github.com/buaazp/uq

UQ的具体功能和用法在github上有详细的介绍,本文中就不浪费篇幅了,只列出我认为能吸引到你的几个亮点:

  • 支持topic、line
  • 支持消息确认和重新入队
  • 支持超多协议,memcached, redis, http RESTful
  • 支持多种存储后端,goleveldb, memory
  • 支持集群以提高可用和吞吐,通过etcd同步topic和line
  • 不错的性能
  • 可以用来替代memcacheQ

更多的信息请访问github查看,我这人不喜欢拉票,但是如果你觉得UQ还不错,请记得给我加个星。

最后

以上这些东西算是对我近几个月来的工作做一个小的总结,俗话说,站在巨人的肩膀上,你自然就看得远,致谢名单如下:

  • 首先是我的领导@马健将,真正低调的大牛,express的设计碰壁的时候全靠小马哥帮我拨乱反正
  • 然后是我的更大的领导@stvchu,更是低调的大牛,还能说啥,mcq作者,在队列功能的设计上给我直击要害的点拨
  • 最后是好基友@Xscape,在时间紧迫的毕业找工作期间还抽空帮我修改语法错误

送给我一直看不惯的嘴炮们,写代码真的不容易,嘴上说起来都是头头是道,真能写出来的才算数。

玩得开心!

来自:http://blog.buaa.us/talk-about-mq/

分享到:
评论

相关推荐

    浅谈Java消息队列总结篇(ActiveMQ、RabbitMQ、ZeroMQ、Kafka)

    2. 消息确认模式:使用消息队列的确认模式,确保消息的完整性和可靠性。 3. 扩展流程:使用消息队列实现扩展流程,如发短信、配送处理等。 Java 消息队列技术的优点: 1. 提高系统性能:使用消息队列可以提高系统...

    浅谈消息队列

    消息队列列的⼀一些要点:服务质量量(QOS)、性能、扩展性等等,下⾯面⼀一⼀一探索这些概念,并谈谈在特定 的消息队列列如kafka或者mosquito中是如何具体实现这些概念的。 服务质量量服务语义 服务质量量⼀一般可以...

    浅谈《数据结构》的重要性.pdf

    在这篇文章中,邓满英老师深入浅出地探讨了数据结构课程的重要性,并阐述了学习这门课程对于程序设计员的意义。 首先,数据结构的概念来源于对数据对象特点的深入理解和数据的组织与实现方法的学习。在计算机科学...

    浅谈分布式事务实现技术及应用场景探讨.pdf

    "浅谈分布式事务实现技术及应用场景探讨" 分布式事务是指在分布式系统中,多个节点之间的数据访问和更新操作集合,需要保证事务的原子性、一致性、隔离性和持久性。随着软件系统支持用户数的不断提高,对其架构的...

    浅谈消息中间件IBM WebSphere MQ

    如果传输过程中出现问题,消息会保留在传输队列中,等待重新发送,确保消息的可靠传递。 **双向通信配置应用** 在实际应用中,可以通过配置两个队列管理器来实现双向通信。例如,QM1和QM2分别定义本地队列和远程...

    浅谈Laravel队列实现原理解决问题记录

    在实际部署时,还需要考虑对队列任务的监控和错误处理机制,确保队列任务能够稳定可靠地执行。Laravel提供了任务失败记录和重试机制,这些机制对于保证长时间运行的应用程序的健壮性和可维护性至关重要。

    浅谈Springboot整合RocketMQ使用心得

    RocketMQ是阿里巴巴开源的一款分布式消息中间件,它提供了高可用、高可靠、低延迟的消息服务。Springboot作为轻量级的框架,简化了Java应用的开发流程。下面我们将分步骤介绍整合过程中的关键点。 首先,我们需要在...

    浅谈分布式消息技术Kafka

    3. **Partition**:Topic被逻辑划分为多个Partition,每个Partition是有序且不可变的消息队列。Partition的引入提高了并发处理能力和系统扩展性。 4. **Segment与Offset**:Partition由多个Segment文件组成,...

    浅谈路由器qos技术.pdf

    通过合理应用IntServ和DiffServ,网络管理员可以有效地管理网络资源,平衡不同服务之间的需求,从而提供更稳定、更可靠的服务体验。同时,随着多协议标签交换(MPLS)等其他技术的发展,路由器QoS技术也在不断演进,...

    浅谈基于8051的嵌入式实时操作系统

    ### 浅谈基于8051的嵌入式实时操作系统 #### 1. 引言 自1946年第一台电子计算机诞生以来,计算机技术和电子技术的不断发展极大改变了人们的生活和工作方式。嵌入式系统作为一种重要的计算平台,在日常生活、科学...

    浅谈Vuejs中nextTick()异步更新队列源码解析

    总结来说,`Vue.nextTick()` 是 Vue.js 中的关键工具,它帮助开发者在正确的时间进行 DOM 操作,避免直接操作 DOM 可能带来的复杂性和错误,从而实现更高效、更可靠的前端应用。了解其工作原理和源码实现,有助于...

    浅谈磁盘控制器的驱动

    现代磁盘控制器还支持高级特性,如SATA(串行ATA)的NCQ(队列命令提交)技术,提升磁盘访问效率。 第二章:IAR驱动原理 IAR(Integrated Automation Real-time)是一种实时操作系统,其驱动程序是系统与硬件设备...

    AtomicInteger 浅谈

    《AtomicInteger 浅谈》 在Java编程中,原子性操作是并发编程中非常关键的一环,它确保了在多线程环境下数据的正确性和一致性。AtomicInteger是Java并发包java.util.concurrent.atomic中的一个类,提供了对单个整型...

    浅谈Spring Boot 整合ActiveMQ的过程

    浅谈Spring Boot 整合ActiveMQ的过程 Spring Boot 是一种流行的Java框架,用于快速构建基于Spring的应用程序。ActiveMQ是一个流行的开源消息队列系统,用于在分布式系统中实现消息传递。本文将介绍如何在Spring ...

    从哲学层面浅谈计算机学习方法论(csdn)————程序.pdf

    无论是传统的关系型数据库,还是新兴的NoSQL存储,甚至消息队列和搜索引擎,它们的设计和实现都基于类似的状态机原理。理解分布式系统的原理,有助于我们更好地构建和管理大规模的系统架构,以及应对数据一致性和...

    浅谈基于Oracle高级复制实现数据库同步热备.pdf

    综上所述,通过细致规划和配置,基于Oracle高级复制实现数据库同步热备不仅可以提高数据的可用性和可靠性,还能有效应对各种潜在风险。这不仅需要对Oracle数据库的基本操作有所了解,还需要深入理解高级复制机制的...

    浅谈Redis在分布式系统中的协调性运用

    这种方式比传统的消息队列更简洁,且能实时传播消息,但请注意,Redis的Pub/Sub不保证消息的可靠传递,只适合用于非关键信息的传递。 再者,Redis的消息队列功能,如`RPOP`和`LPUSH`等,可用于构建先进先出(FIFO)...

    传送指令和移位指令在PLC编程中的应用.pdf

    此外,对于不同型号的PLC,其指令集和编程方式可能会有所差异,因此在进行编程时还需要参考对应的PLC编程手册或用户指南,以确保程序的正确性和可靠性。 总的来说,传送指令和移位指令是PLC编程中的基础,它们为...

    浅谈Java多线程处理中Future的妙用(附源码)

    "浅谈Java多线程处理中Future的妙用" 在Java多线程处理中,Future是一个非常重要的概念,它可以帮助我们更好地处理并发任务。Future是一个未来对象,里面保存着线程处理结果,它像一个提货凭证,拿着它你可以随时去...

    浅谈redis在项目中的应用

    它是一个高性能的NoSQL数据库解决方案,广泛应用于各种项目中,用于数据库、缓存和消息队列等多种场景。以下是Redis在项目中应用的一些关键知识点: 1. 键值存储:Redis的核心特性是提供键值存储,即每个数据项通过...

Global site tag (gtag.js) - Google Analytics