技术选型：为什么要用MQ
任何技术没有绝对的好和坏，学会扬长避短。在合适的地方去运用合适的技术，对其原理，模式，运用，优缺点都要有比较熟悉的应用和理解。 MQ的缺点：系统的可用性降低（mq一旦发生故障，整个系统将会出现崩溃），复杂度提高，一致性问题
技术选型：可伸缩性 ，mq的持久化，mq的可用性，能不能支持数据0丢失
为什么使用RabbitMQ呢？
1、使得简单，功能强大。
2、基于AMQP协议。
3、社区活跃，文档完善。
4、高并发性能好，这主要得益于Erlang语言。
5、Spring Boot默认已集成RabbitMQ
RabbitMQ有以下几种工作模式 ：
1、Work queues
2、Publish/Subscribe
3、Routing
4、Topics
5、Header
6、RPC
MQ的三大作用：异步，解耦，削锋
| 特性 |
ActiveMQ |
RabbitMQ |
RocketMQ |
Kafka |
| 单机吞吐量 |
万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |
万级，吞吐量比RocketMQ和Kafka要低了一个数量级 |
10万级，RocketMQ也是可以支撑高吞吐的一种MQ |
10万级别，这是kafka最大的优点，就是吞吐量高。
一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic数量对吞吐量的影响 |
|
|
topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降
这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic |
topic从几十个到几百个的时候，吞吐量会大幅度下降
所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 |
| 时效性 |
ms级 |
微秒级，这是rabbitmq的一大特点，延迟是最低的 |
ms级 |
延迟在ms级以内 |
| 可用性 |
高，基于主从架构实现高可用性 |
高，基于主从架构实现高可用性 |
非常高，分布式架构 |
非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 |
有较低的概率丢失数据 |
|
经过参数优化配置，可以做到0丢失 |
经过参数优化配置，消息可以做到0丢失 |
| 功能支持 |
MQ领域的功能极其完备 |
基于erlang开发，所以并发能力很强，性能极其好，延时很低 |
MQ功能较为完善，还是分布式的，扩展性好 |
功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 |
| 优劣势总结 |
非常成熟，功能强大，在业内大量的公司以及项目中都有应用
偶尔会有较低概率丢失消息
而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本
而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用
|
erlang语言开发，性能极其好，延时很低；
吞吐量到万级，MQ功能比较完备
而且开源提供的管理界面非常棒，用起来很好用
社区相对比较活跃，几乎每个月都发布几个版本分
在国内一些互联网公司近几年用rabbitmq也比较多一些
但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。
而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。 |
接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障
日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景
而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控
社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码
还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的 |
kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量
而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略
这个特性天然适合大数据实时计算以及日志收集 |
如图所示
MQ的问题解决
第一问：如何保证消息队列的高可用（MQ挂了怎么办）
rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
第二问：如何保证消息不被重复消费啊（如何保证消息消费时的幂等性）？
假设你有个系统，消费一条往数据库里插入一条，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下已经消费过了，直接扔了，不就保留了一条数据？
比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下好吧
比如你是写redis，那没问题了，反正每次都是set，天然幂等性
比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
如何保证MQ的消费是幂等性的，需要结合具体的业务来看
第三问：如何保证消息的可靠性传输（如何处理消息丢失的问题）？
rabbitmq这种mq，一般来说都是承载公司的核心业务的，数据是绝对不能弄丢的
1，生产者弄丢了数据
解决一：rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能。 解决二：如果你要确保说写rabbitmq的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了
所以一般在生产者这块避免数据丢失，都是用confirm机制的。
2，rabbitmq弄丢了数据
必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。
3，消费端弄丢了数据
rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。
第四问：如何保证消息的顺序性？
rabbitmq：拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理
第五问：如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
只能操作临时紧急扩容了
解决方案一：
1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息
解决方案二：
假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次
关注郭大侠关注技术
转载：https://blog.csdn.net/guoqinghuajj/article/details/101225293