MQ知识点汇总
1. MQ是什么
2. MQ能做什么
3. 消息模式
4. 使用MQ的时候需要注意什么
5. 常用MQ
6. MQ的不足
7. 什么时候不适用MQ
8. MQ的组成
9. MQ的关注点
1. MQ是什么
MQ 是message queue ,消息队列，也叫消息中间件、消息总线，是一种跨进程的通信机制，用于上下游传递消息。遵守JMS（java message service）规范的一种软件。数据库因为历史原因，横向扩展是一件非常复杂的工程，所有我们一般会尽量把流量都挡在数据库之前。不管是无限的横向扩展服务器，还是纵向阻隔到达数据库的流量，都是这个思路。阻隔直达数据库的流量，缓存组件和消息组件是两大杀器。
2. MQ能做什么
1）数据驱动的任务依赖：
例如：task2在task1执行完成后才能执行，存在依赖关系
2）解耦：上游不关心执行结果
例如：注册成功后发邮件
3）上游关注执行结果，但执行时间很长
例如：微信支付成功的回调
4）限流（削峰）
5）通知
6）数据分发
a. 注册后我们可能需要做很多初始化的操作，如：调用邮件服务器发送邮件、调用促销服务赠送优惠劵、下发用户数据到客户关系系统等。
那么这时候我们将这些操作去监听MQ，当用户注册成功过后，通过MQ通知其他业务进行操作。确保注册用户的性能。
b. 后台发布商品的时候，商品数据需要从数据库中转换成搜索引擎数据（基于elasticsearch），那么我们应该将商品写入数据库后，
再写入到MQ，然后通过监听MQ来生成elasticsearch对应的数据。
c. 用户下单后，24小时未支付，需要取消订单。以前我们可能是定时任务循环查询，然后取消订单。实际上，我更推荐类似延迟MQ的方式，
避免了很多无效的数据库查询，将一个MQ设置为24小时后才让消费者消费掉，这样很大程度上能减轻服务器压力。
d. 支付完成后，需要及时的通知子系统（进销存系统发货，用户服务积分，发送短信）进行下一步操作，但是，支付回调我们都是需要保证
高性能的，所以，我应该直接修改数据库状态，存入MQ，让MQ通知子系统做其他非实时的业务操作。这样能保证核心业务的高效及时。
7）分布式事务
8）日志处理：
kafka日志处理
3. 消息模式
1）点对点模式和发布订阅模式：是否可以重复消费
a. P2P模式：
P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者
从队列中获取消息。队列保留着消息，直到他们被消费或超时。
b. Pub/sub模式：
包含三个角色：主题（Topic），发布者（Publisher），订阅者（Subscriber） 。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
2）推模式和拉模式：消息的更新者
a. 推(push)模式是一种基于C/S机制、由服务器主动将信息送到客户器的技术。
b. 拉（pull）模式与推模式相反，是由客户器主动发起的事务。
4. 使用MQ的时候需要注意什么
1）消息必达：
a. 消息收到先落地
b. 消息超时、重传、确认保证消息必达
2）幂等性：
a. 上半场：MQ-client生成inner-msg-id，保证上半场幂等。这个ID全局唯一，业务无关，由MQ保证。
b. 下半场：业务发送方带入biz-id，业务接收方去重保证幂等。这个ID对单业务唯一，业务相关，对MQ透明。
结论：幂等性，不仅对MQ有要求，对业务上下游也有要求。
3）高效延时消息，包含两个重要的数据结构：
a. 环形队列，例如可以创建一个包含3600个slot的环形队列（本质是个数组）
b. 任务集合，环上每一个slot是一个Set<Task>
环形队列是一个实现“延时消息”的好方法，开源的MQ好像都不支持延迟消息，不妨自己实现一个简易的“延时消息队列”，
能解决很多业务问题，并减少很多低效扫库的cron任务。
4）削峰填谷
a. MQ-client提供拉模式，定时或者批量拉取，可以起到削平流量，下游自我保护的作用（MQ需要做的）
b. 要想提升整体吞吐量，需要下游优化，例如批量处理等方式（消息接收方需要做的）
5. 常用MQ
6. MQ的不足：
1）系统更复杂，多了一个MQ组件
2）消息传递路径更长，延时会增加
3）消息可靠性和重复性互为矛盾，消息不丢不重难以同时保证
4）上游无法知道下游的执行结果，这一点是很致命的
7. 什么时候不适用MQ
1）上游实时关注执行结果
8. MQ的组成：
1）生产者
2）消费者
3）队列
4）路由
9. MQ的关注点：
1）发布订阅
2）消息优先级
3）消息有序
4）持久化
5）消息过滤
6）消息可靠性：主从，同步双写，异步双写
7）消息低延迟（RocketMQ 使用长轮询 Pull 方式，可保证消息非常实时，消息实时性丌低亍 Push）
8）At least Once（是指每个消息必须投递一次）
9）Exactly Only Once：发送消息阶段，不允许収送重复的消息；消费消息阶段，不允许消费重复的消息。
10）Broker的Buffer满了怎么办?
11）回溯消费
12）消息堆积
13）分布式事务
14）定时消息
15）消息重试
消息通道对并发的支持以及在性能上的表现；消息通道是否充分地考虑了错误处理；对消息安全的支持；以及关于消息持久化、灾备（fail over）与集群等方面的支持。
参见：https://www.cnblogs.com/xuyatao/p/6864109.html
https://www.cnblogs.com/joylee/p/8916460.html
