发布订阅消息系统
在软件架构中，发布订阅是一种消息范式，消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者）。而是将发布的消息分为不同的类别，无需了解哪些订阅者（如果有的话）可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收感兴趣的消息，无需了解哪些发布者（如果有的话）存在。
消息队列的好处
消息队列特别适用于高并发环境:
1.解耦: 消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
例子：A系统提供了一个用户服务，BCD三个系统依赖于A系统的服务
采用了消息队列以后：
2.异步：同步会带来时间的等待,而互联网企业要求对于用户的直接操作，一般每个请求都必须要在200ms以内完成，这样对于用户来说是无感知的。
采用消息队列后：
3.削峰：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
使用消息队列后：
消息队列的缺点
1.系统的可用性降低了：
系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。
2.系统的复杂性提高
硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
3.一致性问题
A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻用还是得用的。
ActiveMQ,RabbitMQ,Kafka的对比
ActiveMQ:
1.1) Java写的消息队列
1.2) 提供了丰富的客户端
1.3) 配置上使用的是对Java和Spring比较友好的XML
1.4) 可以作为一个jar包放到项目里,使用代码进行启动和配置
1.5) 支持复制集群
1.6) 工作模型:
<< 1.6.1) queue: 生产者往queue发消息,消费者从queue里取消息
<< 1.6.2) topics: 生产者往broker发消息,每个消息包含一个topic。消费者订阅
自己感兴趣的topic
1.7) 支持mqtt,ssl
1.8) 单击吞吐量: 万级
1.9) 时效: ms级
1.10)消息可靠性: 丢失消息的概率比较低
RabbitMQ:
2.1) erlang完成的,安装完不到10M
2.2) 配套设施强大: 实例,用户规划权限,监控系统
2.3) 也有topic和queue的概念,又引入了exchange的概念。
<< 2.3.1）要指定消息的key,作为路由键用
<< 2.3.2) 指定发送到哪个exchange(交换器)
2.4) exchange有四种: direct,fanout,topic,header.
<< 2.4.1) 默认的交换器是direct
<< 2.4.2) fanout
<< 2.4.3) topic
<<<<-- 2.4.3.1) * 表示部分字符
<<<<-- 2.4.3.2) # 表示剩余字符
<< 2.4.4) header
2.5) 支持主从复制和集群
<< 2.5.1) 普通集群
<< 2.5.2) 镜像队列,性能比普通集群低
2.6) 以插件的形式支持mqtt，以及和spring整合
2.7) 单击吞吐量: 万级
2.8) 时效性: 微秒级(延迟最低)
2.9) 可用性: 高
2.10)消息可靠性: 基本不丢
2.11)功能支持: 配套设施比较完备
direct:
fanout:
topic:
Kafka
3.1) Scala实现,是一门可以运行在JVM上的语言
3.2) Kafka中只有topic
3.3) Kafka的topic中有分区partition,并且分区是冗余存储的
3.4) Kafka中的消息在partition中的存储是采用的偏移量的机制,所以在同一个partition
中,消息消费的顺序是可以得到保证的
3.5) Kafka中消息的删除策略有两种,所以Kafka支持重复消费
<< 3.5.1) 时间策略,相当于过期时间,过了这个时间就会自动删除
<< 3.5.2) 容量: 超过了一定的量,会把最早的消息进行删除
3.6) Kafka支持多个应用程序消费同一个主题中的消息
3.7) 消费者要指出自己属于哪一个ConsumerGroup,每个消费者都可以读取多个分区
,但是一个分区再同一个ConsumerGroup中只会被同一个消费者消费
3.8) Kafka支持MQTT
3.9) 创建一个topic是一个很重的操作,Kafka仅仅可以作为MQTT的输入
3.10) Kafka提供了流式计算,可以做一些数据的初步清理
PS:
整理资料过程中参考了文献，感觉大佬写的比我这好，有很多自己的理解：https://www.cnblogs.com/laojiao/p/9573016.html
