江苏龙网

  1. 主页 > 生活百科 > >

常用消息队列框架与技术选型( 二 )

框架

  • RocketMQ消费失败支持定时重试，每次重试间隔时间顺延 。
    • 这里的重试指可靠的重试，即失败重试的消息不是因为consumer宕机而导致的消息丢失 。
    严格保证消息有序
    • kafka可保证同一个partition上的消息有序，但一旦broker宕机，就会产生消息乱序 。
    • Rocket支持严格的消息顺序，一台broker宕机，发送消息会失败，但不会乱序 。举例：MySQL的二进制日志分发需要保证严格的顺序 。
    定时消息
    • kafka不支持定时消息
    • 开源版本的RocketMQ仅支持定时级别，定时级别用户可定制
    分布式事务消息
    • kafka不支持分布式事务消息
    • RocketMQ支持分布式事务消息 。
    消息查询
    • Kafka本身不提供内置的消息查询功能
    • RocketMQ支持根据消息标识（发送消息时指定一个消息key, 任意字符串 ， 如指定为订单编号）查询消息，也支持根据消息内容查询消息 。
    消息回溯
    • kafka可按照消息的offset来回溯消息
    • RocketMQ支持按照时间来回溯消息 ， 精度到毫秒，例如从一天的几点几分几秒几毫秒来重新消费消息 。
    RocketMQ按时间做回溯消息的典型应用场景为，consumer做订单分析，但是由于程序逻辑或依赖的系统发生故障等原因 ， 导致今天处理的消息全部无效，需要从昨天的零点重新处理 。
    消息并行度
    • kafka的消息并行度，依赖于topic里配置的partition数，如果partition数为10，那么最多10台机器来消费，每台机器只能开启一个线程；或者一台机器消费 ， 最多开启10个线程 。消费的并行度与partition个数一致 。
    • RocketMQ并行消费分两种情况：1）顺序消费方式的并行度与kafka一致；2）乱序消费方式的并行度取决于consumer的线程数，如topic配置10个队列，10台机器消费 ， 每台机器100个线程，那么并行度为1000 。
    消息队列如何选型？
    • ActiveMQ 的社区算是比较成熟 ， 但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用 。
    • RabbitMQ 在吞吐量方面虽然稍逊于 Kafka、RocketMQ，由于它基于 Erlang 开发，所以并发能力很强，性能极其好，延时很低 ， 达到微秒级 。但是也因为基于 Erlang 开发，所以国内很少有公司有实力做 Erlang 源码级别的研究和定制 。如果业务场景对并发量要求不是太高（十万级、百万级），那这几种消息队列中，RabbitMQ 或许是你的首选 。
    • RocketMQ 阿里开源，久经双十一考验 ， 可以定制自己公司的 MQ 。且支持事务消息，对消息一致性要求比较高的场景优先考虑 。
    • Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量 ， ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展 。同时 Kafka 最好是支撑较少的 topic 数量即可 ， 保证其超高吞吐量 。Kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响 ， 在大数据领域中以及日志采集中 ， 这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集 。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 可谓是行业标准 。
    消息队列常见问题如何避免重复消费？如何保证幂等性?
    【常用消息队列框架与技术选型】幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用问题
    我们先来了解一下产生消息重复消费的原因，对于MQ的使用，有三个角色：生产者、MQ、消费者，那么消息的重复这三者会出现：

    上一篇：用了这么多年Docker，殊不知你还有这么多弯弯绕！

    下一篇：Redis数据类型与应用场景