队列模型

就是一个先入先出的队列。生产者放入，消费者取出。

 

 

单个队列无法满足“广播”的需求

主题模型

或者称之为，发布订阅模型。

在主题模型中，生产者称之为发布者，消费者称之为订阅者，存放消息的容器称之为主题。

发布者将消息发送到指定主题中，订阅者需要提前订阅带能接受到特定主题的消息。

 

 

RocketMQ

其实他的消息模型就是主题模型实现。

 

 

1. Produce  Group   生产者组。代表一类生产者，比如我们有多个秒杀下同作为生产者。多个合在一起就是生产者组。
2. ConSumer Group  消费者组。
3. Topic  主题。代表了一类消息。比如订单消息，物流消息等等。

如图中可以看到，主题中有多个队列，生产者每次生产消息之后是指定主题中的某个队列发送消息的。

集群消费模式下，一个消费者集群多台机器共同消费一个topic的多个队列。。一个队列只会被一个消费者消费，分组内的其他消费者会接替挂掉的消费者继续消费。

每个消费者都会维护一个消费者位置为什么呢？

因为发布订阅模式下的消费者组是多个的。而每一个消费者组的消费位置是不一样的。一个消费者处理完自己的信息时，是不会删除的，因为其他消费者组还需要这个消息。只要加一个位置每次消费完直接向后移动就不会重复消费。

为什么topic中有多个队列

提高并发能力。消费者组中的消费者可以有好多个的。如果只有一个队列。那么只会有一个消费者派上用场。

总结来说：RocketMQ同过在一个topic中配置多个队列并且每个队列维护每个消费者组的消费位置实现发布订阅模式。

RocketMQ架构图。

  Broker

主要负责消息的存储，邮递和查询以及服务的高可用保证。简单上来说就是消息队列服务器。生产者生产消息到Broker，消费者从broker拉取消息并消费。

Broker和topic的关系

 

所以我们需要配置多个Broker

NameServer

他是一个类似与zookeeper的配置中心。主要提供两个功能，Broker管理和路由信息管理、NameServer中存放了很多的broker的信息路由表。消费者和生产者就哦那个nameserver中获取路由表然后按着信息和对应的Broker进行通信。

用来解耦合的。

producer

消息的发布者。支持汲取分布式方式部署。

consumer

消费角色。支持push推，pull拉对消费进行消费。

如何解决顺序消费，重复消费

顺序消费

RocketMQ在主题上是无序的他在队列层面才能保证有序。

他有着普通顺序和严格顺序之分。

普通顺序：消费者通过同一个消息对列收到的消息是有顺序的，不同消息队列收到的消息可能是无序的。普通顺序消息在broker重启情况下不会保证消息顺序性。短时间内。

严格顺序：消费者收到的消息都是有顺序的。即使异常情况下也会保证消息顺序性。

使用普通顺序模式，生产消息轮询（取决于负载均衡策略）来向一个主题的不同消息队列发送消息。如果此时有几个消息分分别是同一个订单的创建，支付，发货。在轮询的策略下这个三个消息会发送到不同队列。应为在不同的队列此时就无法使用TocketMq带来的队列有序特性保证消息有序了。

解决：  将同一于语义下的消息放下同一个队列，使用hash取模法保证同一个订单在同一个队列中就行了

重复消费

需要一个幂等操作，就是无论执行多少次，始终和第一次结果一样。

具体如何实现：   可以使用redis来保证。因为key和value式天然幂等的。也可以通过数据库插入，基于数据库的唯一键来保证重复数据不会被插入多条。

消息队列事务

 

 

消息堆积问题

消息队列有一个很重要的功能就是----削峰。那如果这个峰值太大了呢。

根源就是两个问题：生产太快，消费太慢。

生产太快可以使用一些---限级降流的方法。   也可以选择添加消费者实例。

如果消费者消费过慢，我们可以先检查是否出现大量的消费错误问题。打一个一下日志看看拿一个线程卡死，出现了锁资源不释放的问题。