Mq
今天小菜鸡跟着Java进阶扫盲好好了解了一下Mq，感觉人家分享的东西写的真的是好呀，我自己写的都是些啥呀，本来不想自己写了，但是害怕自己读了一遍会忘记，并且觉得自己写一遍理解得更好，所以还是想要重新来学习写一篇有关Mq的文章。
事实上我已经遇到了Activemq与Kafka，没有好好地思考其原理与优缺点，那么废话不多说开始吧。
为什么要用消息队列
之前了解Activemq的时候粗略地了解了一下，当时只是觉得可能是因为处理速度比较快，另外还有一个词——解耦，ok，解耦是如何体现的呢？
倘若现在有一个消息生产者producer，有多个要获取这些消息的消费者，若使用调用接口的方式，producer发消息的同时万一遇到消费者挂了的情况呢？挂了要不要重发？这时候producer和其他需要消费的系统之间有高的耦合，这显然非常地麻烦。
于是 发布订阅的模式就解决了这一问题，producer只需要丢给Mq消息，消费者自行从Mq里订阅所需要的消息，同时这也解释了为什么用Mq肯定速度比较快，除了producer不需要考虑其他系统外，Mq可以异步地被多个消费者订阅。
削峰
生产中的消息不可能总是平缓地产生，有个什么活动或周末客户量较大很可能导致系统请求暴增，若依靠普通的基于MySQL不知道要多久，而先刷进Mq，一边等待数据库处理，等系统空闲比如深夜了没什么用户的时候，再慢慢处理Mq中的消息。
缺点
并不是把一个大盒子的东西拆开来放进小盒子就完全没有弊端，万一Mq挂了消息丢了，或是消费者拿到消息后写数据库失败了呢，而且平白多了一个小盒子出来无疑是把整个过程复杂化了，对付这种一致性和可用性问题部分Mq有自己独到的优化方式。
Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ | 10 万级，支撑高吞吐 | 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic 数量对吞吐量的影响 | topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 | ||
| 时效性 | ms 级 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低 | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高，基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到 0 丢失 | 同 RocketMQ |
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
入门最早用Activemq，实际生产中RabbitMq和Kafka都是优选。