知识分享,个人笔记本,欢迎大家来扯犊子。
1、消息队列的作用(使用场景):
解耦:解决代码之中跨系统业务调用的耦合性。发送发只管消息正常发出,消费放只管消费关心的主题。
异步:消息发送成功后即可进行后续操作,无需等待消费方处理。
削峰:通过控制MQ每秒的写入量和消费端每秒的消费量,避免瞬时流量打垮后端服务。
2、消息队列的缺点:
由于引入新的组件,导致意外发生的可能性变大,使整个系统的可用性降低了。
使系统的复杂度变高。带来了诸如消息丢失,消息重复消费以及消息顺序性等一系列的问题。
3、常用的消息队列以及他们各自的优缺点:
ActiveMQ | RabbitMQ | RocketMQ | Kafka | |
吞吐量(单机) | 万级 | 万级 | 十万级 | 十万级 |
topic数量对吞吐量的影响 | topic支持千级别的量。topic数量的增加对吞吐量影响不大 | topic支持百级别的量。从几十到几百个时候,吞吐量会大幅度下降 | ||
时效性 | 毫秒级 | 微秒级 | 毫秒级 | 毫秒级 |
可用性实现方式 | 主从 | 主从 | 分布式 | 分布式 |
消息可靠性 | 存在丢失的概率 | 基本不会丢失数据 | 能做到0丢失 | 能做到0丢失 |
4、消息队列的高可用(HA):
RabbitMQ:使用主从形式来保证高可用。
RabbitMQ支持下列启动模式:
单机模式:单节点启动
普通集群模式:多台机器,每台机器启动一个实例组成集群。由于queue只会放在其中一个节点中,所以消费时如果不是连接到指定queue所在的实例,会发生数据同步。
镜像集群模式:多台机器,每台机器启动一个实例组成集群。每台机器对外来说都是一模一样的,每个实例都包含你所创建的queue,同时你向queue发送的消息将自动同步到各个实例的对应queue中。
Kafka:天然的分布式。多台机器,每台机器启动一个实例,并且按照topic的分片数量将这些机器进行分组。每组包含一个leader节点以及其余的replica节点(统称为follower)。写的时候,leader 会负责把数据同步到所有 follower 上去,读的时候就直接读 leader 上的数据即可。leader宕机时会从follower中重新选举出一个leader。
5、消息的幂等性问题:
常见的从业务上保证幂等性手段有如下这些:
数据入库前先进行查询,如果存在则不继续插入改为更新。
让发送方添加一个唯一的key,收到消息后检查key有没有存在(可以放入redis)。
数据库使用唯一索引。
6、消息丢失的处理:
消息可能在以下三个环节丢失:
生产端:
RabbitMQ有两种方式可以防止:
自带的事务机制
2.confirm机制
Kafka的生产端可以认为不会丢失
MQ端:
RabbitMQ开启持久化
Kafka
设置 topic replication.factor > 1 (每个partition至少有两个replica)
设置 min.insync.replicas > 1 (每个leader至少有一个follower存活)
设置 producer acks = all (每条数据写入所有的replica才算成功)
设置 producer retries = max (无限重试次数)
消费端:
RabbitMQ:关闭自动ack,处理完毕时手动发出ack
Kafka:关闭自动提交offset,处理完毕时手动提交offset,同时做好幂等性检查
7、消息顺序消费:
RabbitMQ:在 MQ 里面创建多个 queue,同一规则的数据(对唯一标识进行 hash),有顺序的放入 MQ 的 queue 里面,消费者只取一个 queue 里面获取数据消费,这样执行的顺序是有序的。或者还是只有一个 queue 但是对应一个消费者,然后这个消费者内部用内存队列做排队,然后分发给底层不同的 worker 来处理。
Kafka:在消费端使用内存队列,队列里的数据使用 hash 进行分发,每个线程对应一个队列,这样可以保证数据的顺序。
RocketMQ:生产者中把 唯一ID 进行取模,把相同模的数据放到 messagequeue 里面,消费者消费同一个 messagequeue,只要消费者这边有序消费,那么可以保证数据被顺序消费。
ActiveMQ:指定 JMSXGroupID,消费者会消费指定的 JMSXGroupID。
上一篇:IDEA 激活