`
lygle
  • 浏览: 23704 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

(转)IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

 
阅读更多

1、前言

在IM这种讲究高并发、高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色,当然MQ消息中间件的作用远不止于此,它的价值不仅仅存在于技术上,更重要的是改变了以往同步处理消息的思路(比如进行IM消息历史存储时,传统的信息系统作法可能是收到一条消息就马上同步存入数据库,这种作法在小并发量的情况下可以很好的工作,但互联网大并发环境下就是灾难)。

 

MQ消息中间件可以理解一个水池,水池的这头是消息生产者,水池的那头是消息消费者,生产者和消息者无需直接对接,这将带来很多好处:业务解耦、架构分布式化等,生产者和消费者互相完全透明。

但市面上的MQ消息中间件产品很多,作为IM系统中必不可少的一环,我们该如何选型?那么请继续阅读本文。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-1647-1-1.html

2、关于作者

朱忠华:主要从事消息中间件相关的研发工作,著有《RabbitMQ实战指南》一书,作者的博客是:https://blog.csdn.net/u013256816/article/details/78785569

 

3、内容概述

消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位。

 

目前开源的消息中间件可谓是琳琅满目,能让大家耳熟能详的就有很多,比如 ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ 等。不管选择其中的哪一款,都会有用的不趁手的地方,毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验,其消息队列的使用场景也相对稳定固化,或者目前市面上的消息中间件无法满足自身需求,并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子,那么选择一款合适自己的消息中间件显得尤为重要。就算是前者,那么在自研出稳定且可靠的相关产品之前还是会经历这样一个选型过程。

在整体架构中引入消息中间件,势必要考虑很多因素,比如成本及收益问题,怎么样才能达到最优的性价比?虽然消息中间件种类繁多,但是各自都有各自的侧重点,选择合适自己、扬长避短无疑是最好的方式。如果你对此感到无所适从,本文或许可以参考一二。

4、各类消息队列简述

ActiveMQ 是 Apache 出品的、采用 Java 语言编写的完全基于 JMS1.1 规范的面向消息的中间件,为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。不过由于历史原因包袱太重,目前市场份额没有后面三种消息中间件多,其最新架构被命名为 Apollo,号称下一代 ActiveMQ,有兴趣的同学可行了解。

RabbitMQ 是采用 Erlang 语言实现的 AMQP 协议的消息中间件,最初起源于金融系统,用于在分布式系统中存储转发消息。RabbitMQ 发展到今天,被越来越多的人认可,这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。

Kafka 起初是由 LinkedIn 公司采用 Scala 语言开发的一个分布式、多分区、多副本且基于 zookeeper 协调的分布式消息系统,现已捐献给 Apache 基金会。它是一种高吞吐量的分布式发布订阅消息系统,以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。

RocketMQ 是阿里开源的消息中间件,目前已经捐献个 Apache 基金会,它是由 Java 语言开发的,具备高吞吐量、高可用性、适合大规模分布式系统应用等特点,经历过双 11 的洗礼,实力不容小觑。

ZeroMQ 号称史上最快的消息队列,基于 C 语言开发。ZeroMQ 是一个消息处理队列库,可在多线程、多内核和主机之间弹性伸缩,虽然大多数时候我们习惯将其归入消息队列家族之中,但是其和前面的几款有着本质的区别,ZeroMQ 本身就不是一个消息队列服务器,更像是一组底层网络通讯库,对原有的 Socket API 上加上一层封装而已。

目前市面上的消息中间件还有很多,比如腾讯系的 PhxQueue、CMQ、CKafka,又比如基于 Go 语言的 NSQ,有时人们也把类似 Redis 的产品也看做消息中间件的一种,当然它们都很优秀,但是本文篇幅限制无法穷极所有,下面会针对性的挑选 RabbitMQ 和 Kafka 两款典型的消息中间件来做分析,力求站在一个公平公正的立场来阐述消息中间件选型中的各个要点。

5、选型要点概述

衡量一款消息中间件是否符合需求需要从多个维度进行考察,首要的就是功能维度,这个直接决定了你能否最大程度上的实现开箱即用,进而缩短项目周期、降低成本等。如果一款消息中间件的功能达不到想要的功能,那么就需要进行二次开发,这样会增加项目的技术难度、复杂度以及增大项目周期等。

6、具体技术选型指标1:功能维度

功能维度又可以划分个多个子维度,大致可以分为以下这些。

优先级队列:

优先级队列不同于先进先出队列,优先级高的消息具备优先被消费的特权,这样可以为下游提供不同消息级别的保证。不过这个优先级也是需要有一个前提的:如果消费者的消费速度大于生产者的速度,并且消息中间件服务器(一般简单的称之为 Broker)中没有消息堆积,那么对于发送的消息设置优先级也就没有什么实质性的意义了,因为生产者刚发送完一条消息就被消费者消费了,那么就相当于 Broker 中至多只有一条消息,对于单条消息来说优先级是没有什么意义的。

延迟队列:

当你在网上购物的时候是否会遇到这样的提示:“三十分钟之内未付款,订单自动取消”?这个是延迟队列的一种典型应用场景。延迟队列存储的是对应的延迟消息,所谓“延迟消息”是指当消息被发送以后,并不想让消费者立刻拿到消息,而是等待特定时间后,消费者才能拿到这个消息进行消费。延迟队列一般分为两种:基于消息的延迟和基于队列的延迟。基于消息的延迟是指为每条消息设置不同的延迟时间,那么每当队列中有新消息进入的时候就会重新根据延迟时间排序,当然这也会对性能造成极大的影响。实际应用中大多采用基于队列的延迟,设置不同延迟级别的队列,比如 5s、10s、30s、1min、5mins、10mins 等,每个队列中消息的延迟时间都是相同的,这样免去了延迟排序所要承受的性能之苦,通过一定的扫描策略(比如定时)即可投递超时的消息。

死信队列:

由于某些原因消息无法被正确的投递,为了确保消息不会被无故的丢弃,一般将其置于一个特殊角色的队列,这个队列一般称之为死信队列。与此对应的还有一个“回退队列”的概念,试想如果消费者在消费时发生了异常,那么就不会对这一次消费进行确认(Ack), 进而发生回滚消息的操作之后消息始终会放在队列的顶部,然后不断被处理和回滚,导致队列陷入死循环。为了解决这个问题,可以为每个队列设置一个回退队列,它和死信队列都是为异常的处理提供的一种机制保障。实际情况下,回退队列的角色可以由死信队列和重试队列来扮演。

重试队列:

重试队列其实可以看成是一种回退队列,具体指消费端消费消息失败时,为防止消息无故丢失而重新将消息回滚到 Broker 中。与回退队列不同的是重试队列一般分成多个重试等级,每个重试等级一般也会设置重新投递延时,重试次数越多投递延时就越大。举个例子:消息第一次消费失败入重试队列 Q1,Q1 的重新投递延迟为 5s,在 5s 过后重新投递该消息;如果消息再次消费失败则入重试队列 Q2,Q2 的重新投递延迟为 10s,在 10s 过后再次投递该消息。以此类推,重试越多次重新投递的时间就越久,为此需要设置一个上限,超过投递次数就入死信队列。重试队列与延迟队列有相同的地方,都是需要设置延迟级别,它们彼此的区别是:延迟队列动作由内部触发,重试队列动作由外部消费端触发;延迟队列作用一次,而重试队列的作用范围会向后传递。

消费模式:

消费模式分为推(push)模式和拉(pull)模式。推模式是指由 Broker 主动推送消息至消费端,实时性较好,不过需要一定的流制机制来确保服务端推送过来的消息不会压垮消费端。而拉模式是指消费端主动向 Broker 端请求拉取(一般是定时或者定量)消息,实时性较推模式差,但是可以根据自身的处理能力而控制拉取的消息量。

广播消费:

消息一般有两种传递模式:点对点(P2P,Point-to-Point)模式和发布 / 订阅(Pub/Sub)模式。对于点对点的模式而言,消息被消费以后,队列中不会再存储,所以消息消费者不可能消费到已经被消费的消息。虽然队列可以支持多个消费者,但是一条消息只会被一个消费者消费。发布订阅模式定义了如何向一个内容节点发布和订阅消息,这个内容节点称为主题(topic),主题可以认为是消息传递的中介,消息发布者将消息发布到某个主题,而消息订阅者则从主题中订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立,不需要进行接触即可保证消息的传递,发布 / 订阅模式在消息的一对多广播时采用。RabbitMQ 是一种典型的点对点模式,而 Kafka 是一种典型的发布订阅模式。但是 RabbitMQ 中可以通过设置交换器类型来实现发布订阅模式而达到广播消费的效果,Kafka 中也能以点对点的形式消费,你完全可以把其消费组(consumer group)的概念看成是队列的概念。不过对比来说,Kafka 中因为有了消息回溯功能的存在,对于广播消费的力度支持比 RabbitMQ 的要强。

消息回溯:

一般消息在消费完成之后就被处理了,之后再也不能消费到该条消息。消息回溯正好相反,是指消息在消费完成之后,还能消费到之前被消费掉的消息。对于消息而言,经常面临的问题是“消息丢失”,至于是真正由于消息中间件的缺陷丢失还是由于使用方的误用而丢失一般很难追查,如果消息中间件本身具备消息回溯功能的话,可以通过回溯消费复现“丢失的”消息进而查出问题的源头之所在。消息回溯的作用远不止与此,比如还有索引恢复、本地缓存重建,有些业务补偿方案也可以采用回溯的方式来实现。

消息堆积 + 持久化:

流量削峰是消息中间件的一个非常重要的功能,而这个功能其实得益于其消息堆积能力。从某种意义上来讲,如果一个消息中间件不具备消息堆积的能力,那么就不能把它看做是一个合格的消息中间件。消息堆积分内存式堆积和磁盘式堆积。RabbitMQ 是典型的内存式堆积,但这并非绝对,在某些条件触发后会有换页动作来将内存中的消息换页到磁盘(换页动作会影响吞吐),或者直接使用惰性队列来将消息直接持久化至磁盘中。Kafka 是一种典型的磁盘式堆积,所有的消息都存储在磁盘中。一般来说,磁盘的容量会比内存的容量要大得多,对于磁盘式的堆积其堆积能力就是整个磁盘的大小。从另外一个角度讲,消息堆积也为消息中间件提供了冗余存储的功能。援引 纽约时报的案例,其直接将 Kafka 用作存储系统。

消息追踪:

对于分布式架构系统中的链路追踪(trace)而言,大家一定不会陌生。对于消息中间件而言,消息的链路追踪(以下简称消息追踪)同样重要。对于消息追踪最通俗的理解就是要知道消息从哪来,存在哪里以及发往哪里去。基于此功能下,我们可以对发送或者消费完的消息进行链路追踪服务,进而可以进行问题的快速定位与排查。

消息过滤:

消息过滤是指按照既定的过滤规则为下游用户提供指定类别的消息。就以 kafka 而言,完全可以将不同类别的消息发送至不同的 topic 中,由此可以实现某种意义的消息过滤,或者 Kafka 还可以根据分区对同一个 topic 中的消息进行分类。不过更加严格意义上的消息过滤应该是对既定的消息采取一定的方式按照一定的过滤规则进行过滤。同样以 Kafka 为例,可以通过客户端提供的 ConsumerInterceptor 接口或者 Kafka Stream 的 filter 功能进行消息过滤。

多租户:

也可以称为多重租赁技术,是一种软件架构技术,主要用来实现多用户的环境下公用相同的系统或程序组件,并且仍可以确保各用户间数据的隔离性。RabbitMQ 就能够支持多租户技术,每一个租户表示为一个 vhost,其本质上是一个独立的小型 RabbitMQ 服务器,又有自己独立的队列、交换器及绑定关系等,并且它拥有自己独立的权限。vhost 就像是物理机中的虚拟机一样,它们在各个实例间提供逻辑上的分离,为不同程序安全保密地允许数据,它既能将同一个 RabbitMQ 中的众多客户区分开,又可以避免队列和交换器等命名冲突。

多协议支持:

消息是信息的载体,为了让生产者和消费者都能理解所承载的信息(生产者需要知道如何构造消息,消费者需要知道如何解析消息),它们就需要按照一种统一的格式描述消息,这种统一的格式称之为消息协议。有效的消息一定具有某种格式,而没有格式的消息是没有意义的。一般消息层面的协议有 AMQP、MQTT、STOMP、XMPP 等(消息领域中的 JMS 更多的是一个规范而不是一个协议),支持的协议越多其应用范围就会越广,通用性越强,比如 RabbitMQ 能够支持 MQTT 协议就让其在物联网应用中获得一席之地。还有的消息中间件是基于其本身的私有协议运转的,典型的如 Kafka。

跨语言支持:

对很多公司而言,其技术栈体系中会有多种编程语言,如 C/C++、JAVA、Go、PHP 等,消息中间件本身具备应用解耦的特性,如果能够进一步的支持多客户端语言,那么就可以将此特性的效能扩大。跨语言的支持力度也可以从侧面反映出一个消息中间件的流行程度。

流量控制:

流量控制(flow control)针对的是发送方和接收方速度不匹配的问题,提供一种速度匹配服务抑制发送速率使接收方应用程序的读取速率与之相适应。通常的流控方法有 Stop-and-wait、滑动窗口以及令牌桶等。

消息顺序性:

顾名思义,消息顺序性是指保证消息有序。这个功能有个很常见的应用场景就是 CDC(Change Data Chapture),以 MySQL 为例,如果其传输的 binlog 的顺序出错,比如原本是先对一条数据加 1,然后再乘以 2,发送错序之后就变成了先乘以 2 后加 1 了,造成了数据不一致。

安全机制:

在 Kafka 0.9 版本之后就开始增加了身份认证和权限控制两种安全机制。身份认证是指客户端与服务端连接进行身份认证,包括客户端与 Broker 之间、Broker 与 Broker 之间、Broker 与 ZooKeeper 之间的连接认证,目前支持 SSL、SASL 等认证机制。权限控制是指对客户端的读写操作进行权限控制,包括对消息或 Kafka 集群操作权限控制。权限控制是可插拔的,并支持与外部的授权服务进行集成。对于 RabbitMQ 而言,其同样提供身份认证(TLS/SSL、SASL)和权限控制(读写操作)的安全机制。

消息幂等性:

对于确保消息在生产者和消费者之间进行传输而言一般有三种传输保障(delivery guarantee):At most once,至多一次,消息可能丢失,但绝不会重复传输;At least once,至少一次,消息绝不会丢,但是可能会重复;Exactly once,精确一次,每条消息肯定会被传输一次且仅一次。对于大多数消息中间件而言,一般只提供 At most once 和 At least once 两种传输保障,对于第三种一般很难做到,由此消息幂等性也很难保证。

Kafka 自 0.11 版本开始引入了幂等性和事务,Kafka 的幂等性是指单个生产者对于单分区单会话的幂等,而事务可以保证原子性地写入到多个分区,即写入到多个分区的消息要么全部成功,要么全部回滚,这两个功能加起来可以让 Kafka 具备 EOS(Exactly Once Semantic)的能力。

不过如果要考虑全局的幂等,还需要与从上下游方面综合考虑,即关联业务层面,幂等处理本身也是业务层面所需要考虑的重要议题。以下游消费者层面为例,有可能消费者消费完一条消息之后没有来得及确认消息就发生异常,等到恢复之后又得重新消费原来消费过的那条消息,那么这种类型的消息幂等是无法有消息中间件层面来保证的。如果要保证全局的幂等,需要引入更多的外部资源来保证,比如以订单号作为唯一性标识,并且在下游设置一个去重表。

事务性消息:

事务本身是一个并不陌生的词汇,事务是由事务开始(Begin Transaction)和事务结束(End Transaction)之间执行的全体操作组成。支持事务的消息中间件并不在少数,Kafka 和 RabbitMQ 都支持,不过此两者的事务是指生产者发生消息的事务,要么发送成功,要么发送失败。消息中间件可以作为用来实现分布式事务的一种手段,但其本身并不提供全局分布式事务的功能。

下表是对 Kafka 与 RabbitMQ 功能的总结性对比及补充说明:

 
 
 

7、具体技术选型指标2:性能

功能维度是消息中间件选型中的一个重要的参考维度,但这并不是唯一的维度。有时候性能比功能还要重要,况且性能和功能很多时候是相悖的,鱼和熊掌不可兼得,Kafka 在开启幂等、事务功能的时候会使其性能降低,RabbitMQ 在开启 rabbitmq_tracing 插件的时候也会极大的影响其性能。消息中间件的性能一般是指其吞吐量,虽然从功能维度上来说,RabbitMQ 的优势要大于 Kafka,但是 Kafka 的吞吐量要比 RabbitMQ 高出 1 至 2 个数量级,一般 RabbitMQ 的单机 QPS 在万级别之内,而 Kafka 的单机 QPS 可以维持在十万级别,甚至可以达到百万级。

消息中间件的吞吐量始终会受到硬件层面的限制。就以网卡带宽为例,如果单机单网卡的带宽为 1Gbps,如果要达到百万级的吞吐,那么消息体大小不得超过 (1Gb/8)/100W,即约等于 134B,换句话说如果消息体大小超过 134B,那么就不可能达到百万级别的吞吐。这种计算方式同样可以适用于内存和磁盘。

时延作为性能维度的一个重要指标,却往往在消息中间件领域所被忽视,因为一般使用消息中间件的场景对时效性的要求并不是很高,如果要求时效性完全可以采用 RPC 的方式实现。消息中间件具备消息堆积的能力,消息堆积越大也就意味着端到端的时延也就越长,与此同时延时队列也是某些消息中间件的一大特色。那么为什么还要关注消息中间件的时延问题呢?消息中间件能够解耦系统,对于一个时延较低的消息中间件而言,它可以让上游生产者发送消息之后可以迅速的返回,也可以让消费者更加快速的获取到消息,在没有堆积的情况下可以让整体上下游的应用之间的级联动作更加高效,虽然不建议在时效性很高的场景下使用消息中间件,但是如果所使用的消息中间件的时延方面比较优秀,那么对于整体系统的性能将会是一个不小的提升。

8、具体技术选型指标3:可靠性 + 可用性

消息丢失是使用消息中间件时所不得不面对的一个同点,其背后消息可靠性也是衡量消息中间件好坏的一个关键因素。尤其是在金融支付领域,消息可靠性尤为重要。然而说到可靠性必然要说到可用性,注意这两者之间的区别,消息中间件的可靠性是指对消息不丢失的保障程度;而消息中间件的可用性是指无故障运行的时间百分比,通常用几个 9 来衡量。

从狭义的角度来说,分布式系统架构是一致性协议理论的应用实现,对于消息可靠性和可用性而言也可以追溯到消息中间件背后的一致性协议。对于 Kafka 而言,其采用的是类似 PacificA 的一致性协议,通过 ISR(In-Sync-Replica)来保证多副本之间的同步,并且支持强一致性语义(通过 acks 实现)。对应的 RabbitMQ 是通过镜像环形队列实现多副本及强一致性语义的。多副本可以保证在 master 节点宕机异常之后可以提升 slave 作为新的 master 而继续提供服务来保障可用性。Kafka 设计之初是为日志处理而生,给人们留下了数据可靠性要求不要的不良印象,但是随着版本的升级优化,其可靠性得到极大的增强,详细可以参考 KIP101。就目前而言,在金融支付领域使用 RabbitMQ 居多,而在日志处理、大数据等方面 Kafka 使用居多,随着 RabbitMQ 性能的不断提升和 Kafka 可靠性的进一步增强,相信彼此都能在以前不擅长的领域分得一杯羹。

同步刷盘是增强一个组件可靠性的有效方式,消息中间件也不例外,Kafka 和 RabbitMQ 都可以支持同步刷盘,但是笔者对同步刷盘有一定的疑问:绝大多数情景下,一个组件的可靠性不应该由同步刷盘这种极其损耗性能的操作来保障,而是采用多副本的机制来保证。

这里还要提及的一个方面是扩展能力,这里我狭隘地将此归纳到可用性这一维度,消息中间件的扩展能力能够增强其用可用能力及范围,比如前面提到的 RabbitMQ 支持多种消息协议,这个就是基于其插件化的扩展实现。还有从集群部署上来讲,归功于 Kafka 的水平扩展能力,其基本上可以达到线性容量提升的水平,在 LinkedIn 实践介绍中就提及了有部署超过千台设备的 Kafka 集群。

9、具体技术选型指标4:运维管理

在消息中间件的使用过程中难免会出现各式各样的异常情况,有客户端的,也有服务端的,那么怎样及时有效的进行监测及修复。业务线流量有峰值又低谷,尤其是电商领域,那么怎样前进行有效的容量评估,尤其是大促期间?脚踢电源、网线被挖等事件层出不穷,如何有效的做好异地多活?这些都离不开消息中间件的衍生产品——运维管理。

运维管理也可以进行进一步的细分,比如:申请、审核、监控、告警、管理、容灾、部署等。

申请、审核很好理解,在源头对资源进行管控,既可以进行有效校正应用方的使用规范,配和监控也可以做好流量统计与流量评估工作,一般申请、审核与公司内部系统交融性较大,不适合使用开源类的产品。

监控、告警也比较好理解,对消息中间件的使用进行全方位的监控,即可以为系统提供基准数据,也可以在检测到异常的情况配合告警,以便运维、开发人员的迅速介入。除了一般的监控项(比如硬件、GC 等)之外,对于消息中间件还需要关注端到端时延、消息审计、消息堆积等方面。对于 RabbitMQ 而言,最正统的监控管理工具莫过于 rabbitmq_management 插件了,但是社区内还有 AppDynamics, Collectd, DataDog, Ganglia, Munin, Nagios, New Relic, Prometheus, Zenoss 等多种优秀的产品。Kafka 在此方面也毫不逊色,比如:Kafka Manager, Kafka Monitor, Kafka Offset Monitor, Burrow, Chaperone, Confluent Control Center 等产品,尤其是 Cruise 还可以提供自动化运维的功能。

不管是扩容、降级、版本升级、集群节点部署、还是故障处理都离不开管理工具的应用,一个配套完备的管理工具集可以在遇到变更时做到事半功倍。故障可大可小,一般是一些应用异常,也可以是机器掉电、网络异常、磁盘损坏等单机故障,这些故障单机房内的多副本足以应付。如果是机房故障就要涉及异地容灾了,关键点在于如何有效的进行数据复制,对于 Kafka 而言,可以参考 MirrorMarker、uReplicator 等产品,而 RabbitMQ 可以参考 Federation 和 Shovel。

10、具体技术选型指标5:社区力度及生态发展

对于目前流行的编程语言而言,如 Java、Python,如果你在使用过程中遇到了一些异常,基本上可以通过搜索引擎的帮助来得到解决,因为一个产品用的人越多,踩过的坑也就越多,对应的解决方案也就越多。对于消息中间件也同样适用,如果你选择了一种“生僻”的消息中间件,可能在某些方面运用的得心应手,但是版本更新缓慢、遇到棘手问题也难以得到社区的支持而越陷越深;相反如果你选择了一种“流行”的消息中间件,其更新力度大,不仅可以迅速的弥补之前的不足,而且也能顺应技术的快速发展来变更一些新的功能,这样可以让你以“站在巨人的肩膀上”。在运维管理维度我们提及了 Kafka 和 RabbitMQ 都有一系列开源的监控管理产品,这些正是得益于其社区及生态的迅猛发展。

11、消息中间件选型误区总结

在进行消息中间件选型之前可以先问自己一个问题:是否真的需要一个消息中间件?在搞清楚这个问题之后,还可以继续问自己一个问题:是否需要自己维护一套消息中间件?很多初创型公司为了节省成本会选择直接购买消息中间件有关的云服务,自己只需要关注收发消息即可,其余的都可以外包出去。

很多人面对消息中间件时会有一种自研的冲动,你完全可以对 Java 中的 ArrayBlockingQueue 做一个简单的封装,你也可以基于文件、数据库、Redis 等底层存储封装而形成一个消息中间件。消息中间件做为一个基础组件并没有想象中的那么简单,其背后还需要配套的管理运维整个生态的产品集。自研还有会交接问题,如果文档不齐全、运作不规范将会带给新人噩梦般的体验。是否真的有自研的必要?如果不是 KPI 的压迫可以先考虑下这 2 个问题:1. 目前市面上的消息中间件是否都真的无法满足目前业务需求? 2. 团队是否有足够的能力、人力、财力、精力来支持自研?

很多人在做消息中间件选型时会参考网络上的很多对比类的文章,但是其专业性、严谨性、以及其政治立场问题都有待考证,需要带着怀疑的态度去审视这些文章。比如有些文章会在没有任何限定条件及场景的情况下直接定义某款消息中间件最好,还有些文章没有指明消息中间件版本及测试环境就来做功能和性能对比分析,诸如此类的文章都可以唾弃之。

消息中间件犹如小马过河,选择合适的才最重要,这需要贴合自身的业务需求,技术服务于业务,大体上可以根据上一节所提及的功能、性能等 6 个维度来一一进行筛选。更深层次的抉择在于你能否掌握其魂,笔者鄙见:RabbitMQ 在于 routing,而 Kafka 在于 streaming,了解其根本对于自己能够对症下药选择到合适的消息中间件尤为重要。

消息中间件选型切忌一味的追求性能或者功能,性能可以优化,功能可以二次开发。如果要在功能和性能方面做一个抉择的话,那么首选性能,因为总体上来说性能优化的空间没有功能扩展的空间大。然而对于长期发展而言,生态又比性能以及功能都要重要。

很多时候,对于可靠性方面也容易存在一个误区:想要找到一个产品来保证消息的绝对可靠,很不幸的是这世界上没有绝对的东西,只能说尽量趋于完美。想要尽可能的保障消息的可靠性也并非单单只靠消息中间件本身,还要依赖于上下游,需要从生产端、服务端和消费端这 3 个维度去努力保证,《RabbitMQ 消息可靠性分析》这篇文章就从这 3 个维度去分析了 RabbitMQ 的可靠性。

消息中间件选型还有一个考量标准就是尽量贴合团队自身的技术栈体系,虽然说没有蹩脚的消息中间件只有蹩脚的程序员,但是让一个 C 栈的团队去深挖 PhxQueue 总比去深挖 Scala 编写的 Kafka 要容易的多。

消息中间件大道至简:一发一存一消费,没有最好的消息中间件,只有最合适的消息中间件。

附录:更多相关技术文章

[1] 有关IM架构设计方面:

浅谈IM系统的架构设计

简述移动端IM开发的那些坑:架构设计、通信协议和客户端

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

一套原创分布式即时通讯(IM)系统理论架构方案

从零到卓越:京东客服即时通讯系统的技术架构演进历程

蘑菇街即时通讯/IM服务器开发之架构选择

腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

微信后台基于时间序的海量数据冷热分级架构设计实践

微信技术总监谈架构:微信之道——大道至简(演讲全文)

如何解读《微信技术总监谈架构:微信之道——大道至简》

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

17年的实践:腾讯海量产品的技术方法论

移动端IM中大规模群消息的推送如何保证效率、实时性?

现代IM系统中聊天消息的同步和存储方案探讨

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

WhatsApp技术实践分享:32人工程团队创造的技术神话

微信朋友圈千亿访问量背后的技术挑战和实践总结

王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等

IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

>> 更多同类文章 ……

[2] IM开发热点问题文章:

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

腾讯技术分享:社交网络图片的带宽压缩技术演进之路

IM开发基础知识补课:正确理解前置HTTP SSO单点登陆接口的原理

移动端IM中大规模群消息的推送如何保证效率、实时性?

移动端IM开发需要面对的技术问题

开发IM是自己设计协议用字节流好还是字符流好?

请问有人知道语音留言聊天的主流实现方式吗?

IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

IM消息送达保证机制实现(二):保证离线消息的可靠投递

如何保证IM实时消息的“时序性”与“一致性”?

一个低成本确保IM消息时序的方法探讨

IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

IM群聊消息如此复杂,如何保证不丢不重?

谈谈移动端 IM 开发中登录请求的优化

移动端IM登录时拉取数据如何作到省流量?

浅谈移动端IM的多点登陆和消息漫游原理

完全自已开发的IM该如何设计“失败重试”机制?

通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

微信对网络影响的技术试验及分析(论文全文)

即时通讯系统的原理、技术和应用(技术论文)

开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀

QQ音乐团队分享:Android中的图片压缩技术详解(上篇)

QQ音乐团队分享:Android中的图片压缩技术详解(下篇)

腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率

腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)

腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源

基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

为什么说即时通讯社交APP创业就是一个坑?

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1647-1-1.html

分享到:
评论

相关推荐

    MQ介绍与选型.docx

    MQ(Message Queue)是一种消息队列中间件,用于在分布式系统中实现异步通信、解耦、冗余、扩展性、过载保护、可恢复性、顺序保证、缓冲等功能。常见的MQ有RabbitMQ、ZeroMQ、ActiveMQ、Redis、Kafka、RocketMQ等,...

    Dify智能体:JSON 修复.yml

    Dify智能体:JSON 修复.yml

    陕西省2025年初中学业水平考试实验操作考试试题及评分细则.zip

    陕西省2025年初中学业水平考试实验操作考试试题及评分细则.zip

    西门子S7-1200 PLC污水处理系统:博途V17版KTp1200屏程序设计与优化

    内容概要:本文详细介绍了西门子S7-1200 PLC在污水处理项目中的应用,涵盖模拟量处理、设备轮换、Modbus通讯以及事件记录等多个方面。文中展示了如何利用博途V17进行程序设计,包括具体的SCL代码实例,如液位检测的滑动窗口滤波法、提升泵的轮换逻辑、Modbus TCP对变频器的控制以及报警信息管理等。此外,还分享了一些实用技巧,如防止信号跳变、避免设备过度磨损、确保通讯稳定性和提高报警记录效率的方法。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是熟悉西门子PLC和博途软件的从业者。 使用场景及目标:适用于污水处理项目的PLC编程和系统集成,旨在提高系统的稳定性和可靠性,减少维护成本并优化设备性能。 其他说明:文中不仅提供了详细的代码示例,还分享了许多来自实际项目的经验教训,帮助读者更好地理解和应用相关技术。

    基于PLC的自动药片装瓶机控制系统设计与仿真

    内容概要:本文详细介绍了基于PLC(西门子S7-1200)的自动药片装瓶机控制系统的设计与仿真过程。涵盖了硬件选型(伺服电机、光电传感器)、软件编程(梯形图、结构化文本)、关键算法(传送带定位、振动盘控制、药片计数)、异常处理以及仿真测试等方面的内容。重点讨论了如何通过精确的硬件配置和优化的控制逻辑来确保系统的稳定性和高效性。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对PLC编程和机电一体化感兴趣的读者。 使用场景及目标:适用于制药行业及其他需要自动化包装设备的企业。主要目标是提高生产效率、减少人工干预、提升产品质量和稳定性。 其他说明:文中提供了大量实际案例和调试经验,帮助读者更好地理解和应用相关技术和方法。同时强调了仿真测试的重要性,为后续的实际部署提供了宝贵的经验和改进建议。

    基于元启发式算法优化四级倒立摆系统的LQR控制器设计与应用

    内容概要:本文介绍了一种利用元启发式算法(如粒子群优化,PSO)优化线性二次调节器(LQR)控制器加权矩阵的方法,专门针对复杂的四级倒立摆系统。传统的LQR控制器设计中,加权矩阵Q的选择往往依赖于经验和试错,而这种方法难以应对高维度非线性系统的复杂性。文中详细描述了如何将控制器参数优化问题转化为多维空间搜索问题,并通过MATLAB代码展示了具体实施步骤。关键点包括:构建非线性系统的动力学模型、设计适应度函数、采用对数缩放技术避免局部最优、以及通过实验验证优化效果。结果显示,相比传统方法,PSO优化后的LQR控制器不仅提高了稳定性,还显著减少了最大控制力,同时缩短了稳定时间。 适合人群:控制系统研究人员、自动化工程专业学生、从事机器人控制或高级控制算法开发的技术人员。 使用场景及目标:适用于需要精确控制高度动态和不确定性的机械系统,特别是在处理多自由度、强耦合特性的情况下。目标是通过引入智能化的参数寻优手段,改善现有控制策略的效果,降低人为干预的需求,提高系统的鲁棒性和性能。 其他说明:文章强调了在实际应用中应注意的问题,如避免过拟合、考虑硬件限制等,并提出了未来研究方向,例如探索非对角Q矩阵的可能性。此外,还分享了一些实践经验,如如何处理高频抖动现象,以及如何结合不同类型的元启发式算法以获得更好的优化结果。

    LLC谐振变换器设计与仿真的关键技术解析及实战工具应用

    内容概要:本文详细介绍了LLC谐振变换器的设计方法及其仿真模型的应用。首先,通过参数设计程序,如Excel表格和Matlab脚本,进行关键参数的计算,确保设计符合预期性能。其次,利用Matlab/Simulink构建闭环控制仿真模型,优化PID控制器和PWM生成模块,提高系统的稳定性和响应速度。最后,提供了详细的模态分析和波形解读,帮助理解和规避常见设计陷阱。文中强调了参数选择的重要性,如电感比k值、死区时间和谐振元件的实际测量值,并分享了多个实战经验和调试技巧。 适合人群:从事电力电子设计的技术人员,尤其是对LLC谐振变换器感兴趣的工程师。 使用场景及目标:适用于需要高效、稳定的电源转换解决方案的研发项目。主要目标是掌握LLC谐振变换器的设计原理和技术要点,能够独立完成从参数计算到闭环调试的全过程。 其他说明:文中提供的工具和方法不仅有助于初学者快速入门,也能为有经验的工程师提供宝贵的参考资料。特别提到了一些容易忽视的细节和常见的错误,帮助读者避免不必要的损失。

    深度强化学习在电力系统中的应用:多智能体自主电压控制框架的Python实现

    内容概要:本文探讨了利用深度强化学习(DRL)解决现代电网复杂控制问题的方法,特别是针对自主电压控制(AVC)的应用。文中介绍了多智能体系统(MAS)与深度确定性策略梯度(MADDPG)相结合的MA-AVC算法,展示了如何将电网划分为多个子区域,每个子区域由一个智能体负责,通过集中训练和分散执行的方式进行电压控制。文章详细解释了智能体网络的设计、训练过程、奖励机制以及在伊利诺伊200总线系统上的实验验证。结果显示,相比传统方法,该算法在处理负荷突变、N-1故障和通信延迟等方面表现出显著优势。 适合人群:对深度强化学习、电力系统自动化感兴趣的科研人员和技术开发者,尤其是希望了解如何将AI应用于实际工业场景的研究者。 使用场景及目标:适用于需要提高电网稳定性和响应速度的实际应用场景,特别是在可再生能源接入和快速需求响应的要求下。目标是通过智能化手段提升电网的自适应能力和鲁棒性。 其他说明:文章提供了详细的代码示例和实验结果,帮助读者理解和复现相关算法。特别强调了奖励函数设计和电网仿真的重要性,指出了一些常见的实现陷阱及其解决方案。

    MIMO通信系统中空间编码、系统容量与信道仿真的Matlab实现

    内容概要:本文详细介绍了MIMO通信系统的三个重要方面:空间编码、系统容量计算以及信道特性仿真。首先探讨了Alamouti空时编码的具体实现方法及其在接收端的解码过程,展示了如何通过共轭转置排列实现分集增益。其次,深入讲解了MIMO系统容量公式的推导及其在Matlab中的高效实现,特别强调了使用奇异值分解提高数值稳定性的技巧。最后,讨论了信道矩阵的条件数对系统性能的影响,并提出了应对病态信道的方法如MMSE检测。 适合人群:具备一定通信理论基础和技术背景的研究人员、工程师及高校学生。 使用场景及目标:适用于希望深入了解MIMO通信系统内部机制的人群,帮助他们掌握空间编码、系统容量计算和信道建模的实际应用技能,为后续研究提供理论支持和技术储备。 其他说明:文中提供了大量实用的Matlab代码片段,便于读者快速理解和实践。同时提醒读者注意实际工程中可能遇到的问题,如数值稳定性、信道相关性和噪声增强等。

    【工业自动化】西门子PLC与测量光栅Modbus通讯实现:硬件配置、软件调试及参数设置详解文档的主要内容

    内容概要:本文档详细介绍了西门子PLC与意普测量光栅通过Modbus RTU协议进行通信的方法。硬件方面,使用了1214DC/DC/DC PLC、CB1214通讯板、ESM4810NQ-2测量光栅以及USB转485串口线缆等设备。软件部分采用博图V18进行编程,并利用调试助手modbuSCAN和sscom来辅助配置与测试。文中具体描述了创建MASTER_COMM_LOAD指令、添加MB_MASTER主站指令及轮询程序编写的步骤,包括详细的报文格式解析如站号、功能码、寄存器地址、内容及CRC校验码等信息。此外,还提供了针对光栅的初始化、波特率、奇偶校验和停止位等参数配置示例及其对应的报文解释。; 适合人群:熟悉PLC编程并希望深入了解Modbus通讯协议的应用工程师和技术人员。; 使用场景及目标:①实现PLC作为主站与测量光栅之间的稳定通信;②掌握Modbus RTU协议的具体应用细节,包括报文结构的理解与配置;③解决实际项目中可能遇到的通信问题,如线路连接、参数设置等。; 阅读建议:建议读者在阅读时结合实际硬件设备进行操作练习,同时注意文中提到的一些常见问题及其解决方案,如线序连接错误导致的乱码现象等。

    工业通信基于Qt的Modbus协议开发详解:涵盖协议原理、开发流程及应用案例

    内容概要:本文详细介绍了基于Qt的Modbus协议开发,涵盖协议原理、Qt框架支持、开发流程、代码示例及常见问题解决方案。Modbus协议支持串行通信(RTU/ASCII)和以太网(TCP/IP)两种传输方式,具有功能码定义、数据模型和通信模式等核心功能。Qt通过Qt Serial Bus模块提供对Modbus的支持,主要类有QModbusDevice、QModbusClient(含QModbusTcpClient和QModbusRtuSerialMaster)、QModbusDataUnit和QModbusReply。开发环境配置需在Qt项目的.pro文件中添加相应模块,并准备硬件设备。文中给出了Modbus客户端(TCP)的连接、读取和写入寄存器的代码示例,以及Modbus服务器的实现步骤。还列举了常见的问题与调试技巧,包括通讯不稳定、数据异常和性能优化的方法。最后介绍了该技术在工业自动化、能源管理和智能家居的应用场景。; 适合人群:具备一定Qt编程基础,对工业通信协议感兴趣的开发者。; 使用场景及目标:①学习Modbus协议的基本原理及其在Qt中的实现方法;②掌握Qt Modbus框架的核心类及其用法;③能够独立开发Modbus客户端和服务器程序,解决常见问题。; 阅读建议:本文内容详实,涉及多个知识点和技术细节,在阅读过程中应结合实际开发环境进行实践操作,以便更好地理解和掌握相关技术。

    2021 SEO新手入门:掌握谷歌优化策略

    本书《SEO for Beginners 2021》旨在向读者介绍如何使用搜索引擎优化(SEO)技术,在谷歌上提升网站排名,吸引新客户,从而实现业务增长。作者加里·戈丁和阿伦·肯尼迪通过实例和策略指导,帮助读者了解SEO的基础知识,包括关键词研究、网站设置、链接构建、社交媒体SEO优化以及如何使用谷歌分析工具来监控SEO效果。书中还特别强调了SEO在商业世界中的重要性,并提供了在谷歌广告平台上进行有效广告投放的技巧和策略。此外,作者还分享了如何通过解决SEO常见问题、设置广告账户、撰写广告文案、创建着陆页以及监控转化率等方法,进一步优化搜索引擎营销效果。

    基于Logistic映射的混沌系统图像加密算法:循环移位扰乱与扩散技术的应用

    内容概要:本文详细介绍了利用混沌系统进行图像加密的方法,重点探讨了Logistic映射生成混沌序列用于图像加密的具体实现。首先,通过Python代码生成混沌序列,确保其随机性和不可预测性。然后,采用循环移位扰乱技术对图像像素进行重新排列,使图像的像素位置发生改变。接着,通过水平和垂直扩散技术进一步打乱像素之间的关联性,增加加密强度。文中还展示了加密效果评估方法,如直方图分析、信息熵计算以及相关系数测量,验证了加密算法的有效性。 适合人群:对图像加密技术和混沌系统感兴趣的科研人员、信息安全专家及有一定编程基础的研究者。 使用场景及目标:适用于需要高强度图像加密保护的场合,如军事、医疗等领域的重要图像资料保护。目标是提供一种高效、安全的图像加密解决方案。 其他说明:文中提供了详细的Python代码示例,便于读者理解和实践。同时强调了实际应用中需要注意的问题,如参数选择和性能优化等。

    FLAC3D中双线隧道与临近基坑开挖的数值模拟及关键技术实现

    内容概要:本文详细介绍了利用FLAC3D软件进行双线隧道开挖和临近既有隧道的基坑开挖的数值模拟方法和技术要点。首先,针对隧道开挖部分,采用反力支撑法控制应力释放,并使用shell壳单元模拟喷射混凝土支护结构。其次,在基坑开挖过程中,采用了地连墙加对撑的方式,分层开挖并及时安装水平对撑。文中还提供了多个关键代码片段,展示了具体的实现步骤。此外,文章强调了监测点数据采集和处理的重要性,以及如何通过调整接触面参数解决潜在问题。最后,作者分享了一些实用技巧,如固定云图色标范围、正确设置接触面摩擦系数等。 适合人群:从事地下工程、岩土工程及相关领域的研究人员和工程师。 使用场景及目标:适用于需要进行复杂地质条件下隧道和基坑开挖数值模拟的研究人员和工程师,旨在帮助他们更好地理解和掌握FLAC3D软件的应用,提高模拟精度和效率。 其他说明:文章不仅提供了详细的代码示例,还结合实际案例进行了深入分析,有助于读者将理论知识应用于实际工程项目中。

    Android多数据类型传输(数据的交互)

    实现多数据类型的传输

    《2024年中国物联网产业创新白皮书》

    内容概要:《2024年中国物联网产业创新白皮书》由深圳市物联网产业协会与AIoT星图研究院联合编制,汇集了全国30多个省市物联网组织的智慧。白皮书系统梳理了中国物联网产业的发展历程、现状及未来趋势,涵盖了物联网的概念、产业结构、市场规模、投融资情况、面临的问题与机遇。书中详细分析了感知层、传输层、平台层及应用层的关键技术,探讨了智慧城市、智能工业、车联网、智慧医疗等九大产业物联网应用领域,以及消费物联网的发展特征与热门单品。此外,白皮书还关注了物联网数据安全、法规遵从、人才短缺等挑战,并提出了相应的解决方案。 适用人群:物联网从业者、企业决策者、政策制定者及相关研究机构。 使用场景及目标:①帮助从业者深入了解物联网产业的现状和发展趋势;②为企业决策者提供战略规划依据;③为政策制定者提供政策支持和法规制定参考;④为研究机构提供详尽的数据和案例支持。 其他说明:白皮书不仅限于技术科普,更从宏观角度结合市场情况,多维度讨论了物联网产业生态,旨在为物联网企业、从业者找到最适合的技术应用场景,促进产业健康发展。报告还特别鸣谢了参与市场调研的企业,感谢他们提供的宝贵行业信息。由于时间和资源的限制,报告可能存在信息不充分之处,欢迎各界人士提出宝贵意见。

    车辆动力学中质心侧偏角-横摆角速度相平面法的Simulink实现与应用

    内容概要:本文介绍了如何利用Simulink实现‘质心侧偏角-横摆角速度’相平面法,用于分析车辆的动力学行为。作者详细描述了模型的构建过程,包括输入模块、车辆动力学模型以及相平面生成模块的设计。通过调整车辆速度、路面附着系数和前轮转角等参数,可以直观地观察到车辆稳定性的变化。此外,文中还提供了详细的代码示例和结果分析,帮助读者更好地理解和应用这一方法。 适合人群:对车辆动力学感兴趣的工程师和技术人员,特别是那些希望通过Simulink进行车辆稳定性分析的人。 使用场景及目标:适用于需要评估车辆在不同行驶条件下稳定性的场合,如汽车制造商的研发部门、交通安全研究机构等。目标是通过相平面法直观展示车辆动态响应,辅助优化车辆设计和改进驾驶安全性能。 其他说明:附带完整代码和Simulink模型文件,便于读者动手实践。同时,文中提到的一些调试技巧和常见问题解决方法也非常有价值。

    Minecraft PEB 1.21.90.20 v8a原版.apks

    Minecraft PEB 1.21.90.20 v8a原版.apks

    【Python毕设】p116基于Flask的酒类数据分析可视化系统.zip

    项目资源包含:可运行源码+sql文件+; mysql5.7+Flask+html+jieba+pandas+pillow+scikit-learn+wordcloud+matplotlib 适用人群:学习不同技术领域的小白或进阶学习者;可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 系统功能介绍: 数据可视化:品牌数据可视化、城市价格可视化、地址销量可视化、品牌付款可视化 词云图:商品、地址、商家词云图 价格预测:模型训练、参数调整、模型预测、线性回归预测 用户模块:用户登陆/注册、个人信息修改、添加日志 管理员模块:登陆、个人信息修改、用户管理、日志管理、价格预测、酒类数据维护

    C++数据结构与算法分析解题手册

    本书是《Data Structures and Algorithm Analysis in C++》第三版的解答手册,包含了该教科书中许多练习题的答案。这些答案反映了第三版第一次印刷时书籍的状态。特别排除了一般编程问题和任何解决方案在章节末尾有参考文献的问题。解决方案在完整性程度上有所不同;通常,细节留给读者。存在的少量代码段落应该是伪-C++代码,而不是完全完美的代码。本书适合已经学习过《Data Structures and Algorithm Analysis in C++》的学生或读者使用,作为理解和掌握数据结构与算法分析的辅助材料。

Global site tag (gtag.js) - Google Analytics