各种MQ应用分式

RabbitMQ

RabbitMQ有一个交换机(Exchange)决定消息分发到那些队列中
交换机有四种类型：
Direct：direct 类型的行为是"先匹配, 再投送". 即在绑定时设定一个 routing_key, 消息的routing_key 匹配时, 才会被交换器投送到绑定的队列中去.
Topic：按规则转发消息（最灵活）
Headers：设置header attribute参数类型的交换机
Fanout：转发消息到所有绑定队列

多个消费者定阅同一个队列，只有一个消费者可以得到的消息，消费完消息会删除
多种应用消费者要消费同样的消息，可以建立不同的队列，以Topic转发规则匹配到多个队列中实现

消息消费后就不再存在
[url]https://www.cnblogs.com/ityouknow/p/6120544.html[/url]

为了确保消息不会丢失，RabbitMQ支持消息应答。
[url]https://blog.csdn.net/a491857321/article/details/50670238[/url]


RabbitMQ在服务端没有声明队列和消息持久化时，队列和消息是存在内存中的，服务端宕机了，队列和消息也不会保留。
服务端声明持久化，客户端想接受消息的话，必须也要声明queue时，也要声明持久化，不然的话，客户端执行会报错。


[url]https://www.jianshu.com/p/6376936845ff[/url](消息中间件—RabbitMQ（集群原理与搭建篇))

RocketMQ
支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型

单一队列百万消息的堆积能力
Tag标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
Name Server 为 producer 和 consumer 提供路由信息。
NameServer: 提供轻量级的服务发现和路由。
一个topic可以对应多个queue，多消都多生产时用于提高吞吐量
延时消息
延时消息，简单来说就是当 producer 将消息发送到 broker 后，会延时一定时间后才投递给 consumer 进行消费。

发布/订阅（Pub/Sub）
消息会一直持久化在broker中，通过一定的策略来删除消息

集群消费,一个消息只会被同一个组的消费者中的一个消费者消费

支持分组消费，就是不同应用可以订阅同一个topic，但属于不同的消费组，每个组的消费者都会消费同一topic里的所有消息，

消息支持应答，如果没有应答就会发送到同组的其他消费者消费(return ConsumeOrderlyStatus.SUCCESS;)

发布/订阅模式,消息消费后还存有，会保存一份，更改分组名后可以重新消费之前的所有消息

P2P模式,一个消息只有一个真正的消费者，因为消息取走了之后，消息就不会在broker存在了

每个组的消费信息会保存到broker中

当 consumer 使用集群消费时，每条消息只会被 consumer 集群内的任意一个 consumer 实例消费一次。

[url]https://www.jianshu.com/p/824066d70da8[/url]
[url]https://blog.csdn.net/iie_libi/article/details/54289580[/url]
[url]https://mp.weixin.qq.com/s/QdNQFG6ohhPpNppScEXdUQ[/url]


activemq

两种数据结构:Queue/Topic
1.Queue队列,生产者生产一个消息,只能由一个消费者进行消费.
2.Topic 话题.生产者生产一个消息,可以由多个消费者进行消费.,
支持消费应答

多个一样的消费者可以用Queue,但不同应用要相同的数据就不能用Queue,因为同一个消息只会有一个消费者消费
多个应用接收相同消息可用Topic,但一个应用不能有多个了，否则同一个消息会消费多次
如果多应用多节点就只能多开Queue的方式进行处理了

Topic模式只对在线的消费者发送消息，
Queue队列模式后面再上线也会接收到之前的消息

对于这种点对点的发送方式而言，一旦服务器中的消息被相应的消费者消费后，对应的消息就会立刻被移出消息队列。

对于发布订阅式的通信模式而言，消费者必须先于生产者而启动，否者的话，消费者是接收不到相应的消费消息的。


[url]https://www.cnblogs.com/xiohao/p/4835594.html[/url]
[url]https://www.cnblogs.com/xiohao/p/4835594.html[/url]


[url]https://blog.csdn.net/zhangll_2008/article/details/78657177[/url]（分布式消息中间件-Rocketmq）
[url]https://www.cnblogs.com/xiaodf/p/5075167.html[/url](阿里 RocketMQ 安装与简介)


kafka
支持应答
支持分组消费
支持重新消费之前的数据(offect)


消费事务
[url]https://www.cnblogs.com/xuwc/p/9034352.html[/url]


//1.发送端，先在同一个事务中把消息放入数据库，发送成功后再把数据库的消息删除或更换状态。（要求数据库事务一致性,路由到同一个库就可以实现了）,发送失败就由下一次的发送或后台定时任务进行处理。

2.发送失败，重试N次还是失败，保存到DB，由后台线程进行发送。（这种方式业务会简单一占）
存在问题，逻辑处理了，但消息没有发送就宕机了，所以单库就放到逻辑事务中就可以了，如果多库就要解多库的事务问题(如分到同一个库中),发送后删除。后台找到没发送的重发

[url]https://blog.csdn.net/qq_32020035/article/details/82113751[/url]

//接收端，处理与消息去重在同一事务中进行，操作完成再回ACK给MQ，这样就可以保证消息不会被重复消费。

接收端接收到消息时就先向去重表放一条数据，再在事务中做逻辑处理，消息回应放到事务里面，以备失败回滚,同样存在插入了，但逻辑失败

高并发下去重:加上缓存加快去重查询操作


//接收端,
1.查询ID是否在去重表，是不处理。否插入到去重表。
2.执行逻辑处理(执行多次(最好有一定延时))，成功返回MQ的ACK。失败，去重表删除ID（重试多次(最好有一定延时)），成功就退出（不回ACK），删除失败,写消息到日志中（手工进行恢复）.
3.2中如果写日志失败也会存在问题，所以如果是重复的就把消息写和另一个日志进行保存.

//接收端,
1.保证去重和逻辑处理在同一个库中进行处理，以消息ID和逻辑处理的ID拼接路由到同一个库实现。（保证去重表与逻辑处理的一致性）,这样就可以解决不一致的问题了.


kafka在一台普通的服务器上既可以达到10W/s的吞吐速率