消息中间件之从零开始

消息中间件的作用

消息中间件的作用可以概括如下:

  • 解耦:消息中间件在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要事先这一接口,这允许你独立地扩展或修改两边的处理过程,只要确保他们遵守同样的接口约束即可。
  • 冗余(储存):有些情况下,处理数据的过程会失败。消息中间件可以把数据持久化直到它们已经完全处理,通过这一范式规避了数据丢失风险。
  • 扩展性:因为消息中间件解耦了应用的处理过程,所以提高了消息入队和处理的效率和容易的,只要另外增加处理过程即可,不需要改变代码,也不需要调节参数。
  • 消峰:在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。使用消息中间件能够使关键组件支撑突发访问压力,不会因为突发的超负荷请求而完全崩溃。
  • 可恢复性:即使一个处理消息的进程挂掉,加入消息中间件中的消息仍然可以在系统恢复后进行处理。
  • 顺序保证:消息中间件支持一定程度上的顺序性
  • 缓冲:消息中间件通过一个缓冲层来帮助任务最高效率的执行,写入消息中间件的处理会尽可能快速。该缓冲层有助于控制和优化数据流经过系统的速度。
  • 异步通信:消息中间件提供了异步处理机制。

AMQP

AMQP,即 Advanced Message Queuing Protocol,一种提供统一消息服务的应用层标准高级
消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端和消息中间件可传递消息,并不受客户端/中间件不同产品,不同的开放语言等条件的限制。基于此协议的消息中间件有RabbitMQ。

各种MQ的比较

目前业界有很多MQ产品,比如 RabbitMQ、RocketMQ、Kafka、ActivceMQ等。其中ActiceMQ现在社区活跃度不是很高,已经被很多人弃用了。其中RabbitMQ 是基于erlang语言的,虽然其实开源的,但是如果需要定制化的话,维护是一件很麻烦的事情。Kafka 和 RocketMQ ,前者是Scala,后者是阿里出品的,基于Java开发的。所以,我们一般选择MQ的时候,主要从RabbitMQ、Kafka、RocketMQ这几个主流MQ中选择一个适合的。

Kafka

Kafka 主要定位在日志等方面,因为Kafka 设计的初衷就是为了处理日志。

优点

  • 性能卓越,单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。
  • 时效性:ms级
  • 可用性:非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
  • 消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
  • 有优秀的第三方Kafka Web管理界面Kafka-Manager;
  • 在日志领域比较成熟,被多家公司和多个开源项目使用;
  • 功能支持:功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用

缺点

  • Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长
  • 使用短轮询方式,实时性取决于轮询间隔时间;
  • 消费失败不支持重试;
  • 支持消息顺序,但是一台代理宕机后,就会产生消息乱序

RabbitMQ

RabbitMQ 结合 erlang 语言本身的性质,高并发,高可用等特性。

优点

  • 由于erlang语言的特性,mq 性能较好,高并发
  • 吞吐量到万级,MQ功能比较完备
  • 健壮、稳定、易用、跨平台、支持多种语言、文档齐全

缺点

  • erlang 语言开放,比较难维护
  • RabbitMQ的吞吐量相对另外两个MQ低很多

RocketMQ

RocketMQ 适合互联网金融领域,支持可靠性要求高的场景。

优点

  • 单机吞吐量:十万级
  • 可用性:非常高,分布式架构
  • 消息可靠性:经过参数优化配置,消息可以做到0丢失
  • 功能支持:MQ功能较为完善,还是分布式的,扩展性好
  • 支持10亿级别的消息堆积,不会因为堆积导致性能下降

缺点

  • 支持的客户端少
博主 wechat
钟意作者
客官,赏一杯coffee嘛~~~~
0%