MQ消息队列--学习笔记

什么是消息队列

把传输数据按照先后顺序进行排列的一种数据结构，而一般把数据放到消息队列叫生产者，把从消息队列里取数据叫消费者。

为什么需要消息队列

解决高并发带来的压力，没钱堆设备只能掉头发去优化与客户的交互还有各系统之间数据传输的方式
具体解决下面三个问题：
1.解耦：
将系统之间的直接关联改为间接关联，避免牵一发而动全身
传统模式:

中间件模式:

2.异步
将线性的业务逻辑的非重要部分改成并行运行
传统模式:

中间件模式:

3.削峰
通过消息队列把突发高流量接下，再按照数据库能承受的压力下一部分一部分的转发过去

主流MQ中间件的优缺点

1、ActiveMQ

吞吐量：万级（一秒1W~2W左右请求）
时效：ms级别
可用性：高，基于主从架构高可用
消息可靠性：有较低概率丢失数据
总结：
1、对 TPS 要求比较低的系统，可以使用 ActiveMQ 来实现，一方面比较简单，能够快速上手开发，另一方面可控性也比较好，还有比较好的监控机制和界面
　 2、ActiveMQ 不支持消息自动分片机制，如果消息量巨大，导致一台服务器不能处理全部消息，就需要自己开发消息分片功能。

2、RabbitMQ

吞吐量：万级
时效：微秒级，延时低
可用性：高，基于主从架构高可用
总结：
1、结合erlang语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护。不过，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug。

3、RocketMQ

吞吐量：十万级
时效：ms级
可用性：非常高，分布式架构
消息可靠性：经过参数优化配置，消息可以做到0丢失
总结：
1、MQ功能较为完善，还是分布式的，扩展性好
2、支持10亿级别的消息堆积，不会因为堆积导致性能下降
3、源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控
4、社区活跃度一般，没有在 mq 核心中去实现JMS等接口，有些系统要迁移需要修改大量代码

4、Kafka

吞吐量：十万级，最大的优点，就是吞吐量高。
时效：ms级
可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性：高可靠的分布式日志存储服务
总结：
1、Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
2、大型公司建议可以选用，如果有日志采集功能，肯定是首选kafka了。

消息队列带来的问题

重复数据

MQ 只能保证消息不丢，不能保证重复发送
解决方案：
幂等：用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
思路：
1、拿数据要写库，首先检查下主键，如果有数据，则不插入，进行一次update
2、如果是写 redis，就没问题，反正每次都是 set ，天然幂等性
3、生产者发送消息的时候带上一个全局唯一的id,消费者拿到消息后，先根据这个id去 redis里查一下，之前有没消费过，没有消费过就处理，并且写入这个 id 到 redis，如果消费过了，则不处理。
4、基于数据库的唯一键

消息丢失

MQ 传递非常核心的消息，比如：广告计费系统，用户点击一次广告，扣费一块钱，如果扣费的时候消息丢了，那就扣费失败，积少成多对公司会有巨大的损失
解决方案：
1、消息持久化到磁盘
2、关闭autoAck机制，等待消费者处理完自己发送ack

消息顺序性

概况：mysql binlog 同步的系统，在mysql里增删改一条数据，对应出来了增删改 3 条binlog，接着这 3 条binlog发送到 MQ 里面，到消费出来依次执行，起码是要保证顺序的吧，不然顺序变成了 删除、修改、增加。日同步数据达到上亿，mysql->mysql,比如大数据 team，需要同步一个mysql库，来对公司的业务系统的数据做各种复杂的操作。

参考链接：
[1]https://zhuanlan.zhihu.com/p/140885460
[2]https://blog.csdn.net/miachen520/article/details/91039661
[3]https://blog.csdn.net/u011663149/article/details/86232869
[4]https://www.cnblogs.com/rsapaper/p/10382423.html
[5]https://blog.csdn.net/qinweili751/article/details/80620104
[6]https://blog.csdn.net/belvine/article/details/80842240?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

-----------------------------------------------------------------我是分割线--------------------------------------------------------------

看完了觉得不错就点个赞或者评论下吧，感谢！！！

如果本文哪里有误随时可以提出了，收到会尽快更正的