1.消息中间件是什么
能够实现与平台无关的消息调用
拥有失败重试机制
2.2限流削峰
3.模型
消息具有topoic,并且也是按照topic进行存储
负责消息管理-->中间件的消息接收,消费者的消息订阅
生产者组:发送同一种Topic消息,多个productor
消费者组:1.消费同样消息2.具有同样消费逻辑的Consumer
因此可以有不同的消费者组,都接收同一个topic,但是执行逻辑不同
对于消费者组,消息的分配问题,引出_>消费模式
a.集群模式:一条消息只会被消费者中的某一个消费者消费一次
b.广播模式,一条消息被消费者中的每个消费者消费一次
默认模式:集群模式
在同一个消费者组的多个消费者,必须订阅相同topic,否则,有可能会出现消费错乱
(存在着:同一个消息给不同消费者组(订阅同样topic)的情况 诞生的的消息分享机制)
offset指针,指向Topic队列中的消息; (数量与消费者组持平,一人一个),为此可以保证在不同组的消费速率的情况下依然可以进行正常消费
broker(消息中转)
broker可以有多个
Nameservice(注册中心)
- Nameserver 注册中心
- 作用:
- 每个Broker启动的时候会向namesrv注册
- Producer发送消息的时候根据Topic获取路由到Broker里面Broker的信息
- Consumer根据Topic到Namesrv 获取topic的路由到Broker的信息
- (先启动nameservice再启动broker)
提供者发送消息选择对应topic的broker(存在于不同主机不同端口),这个过程由注册中心提供
消费者接收对应的broker的消息,这个过程由注册中心提供1. 注册中心Nameserver启动
- 2. 消息中转服务Broker启动(读取日志中之前的消息队列)
- 启动的时候会去创建Topic并创建对应的MessageQueue
- 启动的时候会去注册中心注册,把自己的地址以及负责的Topic告诉注册中心
- Broker和Nameserver之间通过心跳机制来检测对方是否存活
在长连接中,可以避免连接失效而 *** 作系统一直开启资源的问题,(从而更新nameservice里的注册信息)生成者获得消息路由信息
MQ将储存信息存储与读取日志文件的存储策略
broker主从架构的复制策略
a.同步复制(复制结束之后)高可用
b.异步复制(当接受到消息的时候)高效率
单点问题
主从架构_>哨兵模式_>集群模式(主备切换,故障转移)
读写分离
官网地址:http://rocketmq.apache.org
下载地址:http://rocketmq.apache.org/release_notes/release-notes-4.4.0/
修改以上两个配置文件
start mqbroker -n 127.0.0.1:9876 -c ..confbroker.conf autoCreateTopicEnable
0.导入依赖
1.
消费者
Cunsumer从队列中拿到消息,放入监听器,从监听器中取出消息
监听器的返回值consumer会获得,可以将返回值信息传递给MQ
重试机制 (16次,时间递增 4小时结束)
延迟消息
订单超时自动取消
只需修改提供者
延迟消息->延迟消息的消费的(指定30分钟之后才能被消费)30分钟之后 根据订单号查询订单是否被支付,如果没有支付就取消掉
message.setuserProperty("starTime")
消费者获取时间
因为这里没有导入boot的包,所以没有自动配置,spring无法注入
,spring都是用空仓构造器来创建对象的,因此可以利用init方法来执行注入
mq:订单初始化类 调用提供者方法
消费者
先注入
创建topic
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)