0


[个人感悟] 消息队列应该考察哪些问题?

在这里插入图片描述


前言

消息队列. 不论是Java内部提供的LinkedBlockingQueue, 还是当下主流的中间件RabbitMQ, Kafka, RockMQ. 其本质上都是一个削峰填谷的工具.

我们都知道, 请求和流量都有可能瞬间很高, 或者很低. 所以, 很多时候, 我们需要请求存储起来, 或者使用异步的方式, 来匀速的处理过量的请求.


问题

问题-基础

  • 什么是消息队列? 消息队列有什么作用? 你常用的消息队列有哪些?

问题-特性问题

  • 如何保证消息队列消息不丢失?
  • 如何保证消息集群的高可用性?
  • 如何保证消息不重复消费? 如何保证消息的幂等性?
  • 如何实现延迟消息队列, 类似DelayQueue?
  • 消息存在失效时间?如何处理这部分类型的消息?
  • 如何保证消息的顺序性? 全局顺序性 or 局部顺序性?

问题-Kafka

  • 聊聊Kafka的基本架构?
  • Kafka 为何性能效率那么高?

问题-场景问题

  • 如何解决开发过程中等等消息积压问题?
  • 消息队列是否可以作为分布式事务的解决方案? 如何进行处理?

回答

问题-基础

  • 什么是消息队列? 消息队列有什么作用? 你常用的消息队列有哪些?
  1. 消息队列是一个队列. 主要用于削峰填谷. 缓解即时流量瞬发. 可以使整体请求处理匀速进行.(漏斗限流算法)
  2. 消息队列有JDK原生的Queue之外, 还有一些第三方消息队列框架. RabbitMQ RocketMQ Kafka.

问题-特性问题

  • 如何保证消息队列消息不丢失?

消息不丢失需要从, 发送端, 服务端, 消费端.

  1. 发送端. Kafka 消息发送有ISR. -1, 1, 2. 这3种模式. 要求限制高的消息需要设置为-1, 且需要设置重发策略.
  2. 服务端. 服务端Linux操作系统, 需要将内存数据落盘. 脏页. / RabbitMQ是内存的, 无法落盘.
  3. 消费端. 消息事务成功后, 在进行消息消费的提交操作. 不要AutoCommit, 需要手动Commit.
  • 如何保证消息集群的高可用性?
  1. 服务端.去中心化思想. 将一个Topic进行分片, 将其中心调度节点均匀分布多个节点.
  2. 消费端. 消费端-负载均衡.
  • 如何保证消息不重复消费? 如何保证消息的幂等性? 如何实现消息的精准一次消费? 1.2.3点和前面消息不丢失一致. 幂等操作, 消息去重, 乐观锁 MVCC. (个人不是特别认可)
  • 如何实现延迟消息队列, 类似DelayQueue?
  1. RocketMQ 可以设置延时队列. 时间轮, 定时调度.
  • 消息存在失效时间?如何处理这部分类型的消息?
  1. RabbitMQ 死信队列.
  2. RocketMQ 延时队列. 设置延时检查和取消的检查的消息, 触发检查机制.
  • 如何保证消息的顺序性? 全局顺序性 or 局部顺序性?
  1. 全局顺序. 单节点. 数据不要分片, 使用一个分区.
  2. 局部顺序. 消息设置正确的发送路由算法, 消费设置正确的消费算法.

问题-Kafka

  • 聊聊Kafka的基本架构?
  1. Broker. Topic. Partition.
  2. Leader. Follower.
  3. Producer, Server, Consumer.
  4. 物理文件映射. index, log.
  • Kafka 为何性能效率那么高?
  1. mmap. 内存映射. 系统内存映射, 无需socket流相互转换. 内核和用户进行相互切换.
  2. Netty的select, epoll的网络IO交互模型.
  3. 顺序读写. 内存块预分配. 128M硬盘空间.

问题-场景问题

  • 如何解决开发过程中等等消息积压问题?
  1. 部门沟通. 先发现当前是上游, 下游, 自身问题. 消费加速时, 需要通知依赖部门, 防止其他服务宕机.
  2. 加速消费. Topic多分片, 或者新建Topic, 多分片. 起多个Consumer加速消费.
  • 消息队列是否可以作为分布式事务的解决方案? 如何进行处理?
  1. RocketMQ 在4.0版本实现了分布式事务的解决方案. 2PC模式.
标签: Java 消息队列 Kafka

本文转载自: https://blog.csdn.net/u010416101/article/details/140254104
版权归原作者 在风中的意志 所有, 如有侵权,请联系我们删除。

“[个人感悟] 消息队列应该考察哪些问题?”的评论:

还没有评论