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）与集群等方面的支持。

 

 

参见：http://www.javashuo.com/article/p-ubdrypih-en.html

         http://www.javashuo.com/article/p-aalwfjgd-dv.html

         https://blog.csdn.net/KingCat666/article/details/78660535

         消息必达