MQ消息中间件了解

MQ 消息中间件

Rabbit MQ

AMQP协议
1、交换器 Exchange
Direct（直连）数据的分发，交给不同的队列来处理
通过绑定路由键，生产者发送消息到MQ的时候提供routing key（即路由键），指定发送给某个队列，或者说是给指定的服务去消费

Fanout（广播）群发，进行消息的复制（给多个消费者分发，让多个消费者获得同样的消息）
只要绑定了多个队列，就可以使多个队列收到消息，这时候绑定键和routing key是没有意义的，因为它只会去看你绑定了多少队列，然后进行群发

Topic（主题）可进行数据分析，通过“.”，经过主题交换器进行分类
路由键中的“*”和“#” （这里的#号是通配符，指1个或多个）
"."分隔符
举例:

routing key	routing key	routing key	routing key
ping.kafka	ping.jvm	hy.kafka	hy.jvm

通过Exchange交换器
交换器中的路由键有

绑定路由键	绑定路由键	绑定路由键	绑定路由键
ping.#	#.kafka	#.jvm	hy.#
队列	队列	队列	队列
ping.kafka	ping.kafka	ping.jvm	hy.kafka
ping.kafka	hy.kafka	hy.jvm	hy.jvm

解决消息丢失
1、确保消息到MQ（发送方的确认模式）
这边有一点，就是怎么确保消息发送到MQ，并不是发送过去了，MQ就要返回，这就改变了MQ的解耦功能，应该是MQ收到消息后返回（起一个setConfirmCallback,来通知生产者有没有发送消息到MQ），这一步可以判断网络是否成功
2、确保消息路由到正确的队列（路由失败通知你）（这个属于路由内部 ）
路由键不匹配，就会路由失败，路由失败就需要提示
3、确保消息的队列正确的存储
默认情况，消息在rabbit MQ 是放在内存的，运行一段时间，消费者消费的比较慢，还有消息在内存在队列里面，这时候如果电源被拔了，消息就永久的丢失了，因为消息在mq上的存储是在队列中的，这时候如果把消息同步存储在磁盘，并发量要下降一个数量级也就是10倍，原来可以1.2万并发，会变成1200.（消息的持久化性能下降）
4、确保消息从路队列中正确的投递至消费者
在消费消息的时候，会把队列中的消息删除，因为不删除就会出现消息的重复
有可能在消费端没有被消费掉（手动确认，也就是交给消费者来确认，消费者来判断是否消息，还是异常然后进行返回）

RocketMQ

版本发展

Metaq（Metamorphosis）1.x（2011） 由开源社区killme2008维护（完全抄袭kafka）
Metaq2.x (2012) 淘宝内部使用
RocketMq3.x/4.x (2012/2017) Apache开源

三大MQ

	RabbitMQ	RocketMQ	Kafka
性能（单台）	万级（12000+）	十万级	百万级
消息持久化	支持	支持	支持
多语言支持	支持	很少	支持
支持协议	多（AMQT,STOMP,MQTT…）	自定义协议	自定义协议
综合评价	优点：性能较好，管理界面较丰富，在互联网公司也有较大规模的应用，有多个语言的成熟客户端。缺点：内部机制很难了解，也意味很难定制和掌控。集群不支持动态扩展。	优点：模型简单，接口易用。在阿里有打规模应用。分布式系统，性能很好，版本更新很快。缺点:支持的语言较少。	优点：天生分布式，性能最好，所以常见用于大数据领域。缺点：运维难度大，偶尔有数据混乱的情况，对ZooKeeper强依赖。多副本机制下对带宽有一定的要求。

kafka在海量主题时会产生多个文件（每个主题都是文件），那么在并发处理时就会降低性能，所以不能直接使用kafka，在使用前还是要进行处理或进行优化

kafka的存储模型-都是独立的一个文件
rocketMQ的存储模型-共享一个文件（这边就是在海量主题下，都只是一个文件，解决kafka在海量主题导致的性能下降问题 ）