mq

一、mq的特性：

1. 异步。上游无法直到下游的执行结果。这是mq无法取代直接调用最根本的原因。
   所以，很多人说mq削峰，但是不是什么都削，必须是，调用方对调用结果的及时性不是很在意才行，比如，登录，你不可能用mq削峰吧。。

2. 解耦。A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据，或者C系统现在不要这个数据，或者A系统再发第二种数据，再或者，BCDE这些服务，一旦挂了，这个数据就丢失了。
   总之，耦合性太重，

3. 削峰。对于一些上游对下游的直接结果不是很关注的业务，对CAP的C容错比较大的业务。上游并发大，下游处理能力小，如果上游直接调用，下游会直接被打死。那么可以把任务先放到mq中去，然后异步慢慢处理。

二、mq的使用场景：
mq只是一个消息队列，或者是一个生产者消费者模式，是进程间通信的。

进程内的消费者生产者适合的场景跨服务就是mq适合的场景。
比如：
2.1. 时间上有依赖的任务执行。
比如，我曾经有一个定时服务，同步，小区，人员，房屋等等信息，之后还要对这些信息进行统计，计算处理。各个步骤有时间上的依赖。

1.1 一种很常见的方式：每个定时任务开启定时器，然后同步的时间点预定在上一个任务之后，然后在预留相当长的时间防止任务执行超时了。
优点：简单，赶工期先这样应付着。。。
缺点就是：
1、一旦上一个任务超时了，下一个任务的数据就错了。
2、需要预留时间，时间紧的话没有那么多时间浪费，比如就晚上有时间给你同步数据，可晚上就那么几个钟头。
3、一旦以后数据量多了，同步时间延长了，则需要修改同步时间。

1.2 另一种方式：一个任务执行完了之后，直接调下一个任务的方法，执行下一个任务。
这种方式，能够解决第一种方式的3个缺点。
缺点：1、耦合性很高，一个任务之后，要回调很多个下个任务的方法，不是很优雅。而且，如果以后再新增一个回调任务，则又要修改上个任务的回调方法。
2、假设这个任务是在多个服务的，如果远程调用的话，很可能会因为网络原因等调用失败，除非引入了rpc有重试机制。

1.3 再一种方式：写一个进程内的消费者生产者模式。然后上游任务执行完，直接往进程内队列里put，然后，下游任务直接订阅这个队列，然后就会直接得到处理了。
优点：耦合性不高。
缺点：需要花时间去写一个进程内消费者生产者模式。比如这样的东西：写一个消费者生产者模式

2.2. 可以异步，耦合性高，执行时间长的场景
比如，添加一个商品，就要生产一个商品索引，还要生成一个商品的详情页，等等。

1、如果直接rpc调用，那么，直接调用，则执行时间太长。

2、如果异步线程调用，耦合性太大，一旦增加一个获取通知的回调，又要修改生成商品服务。
3、而且直接调用，万一下游服务挂了，消息就丢失了。

2.3. 流量削峰

上游qps大，直接调用，会把下游打死。
比如上游只有简单的下单逻辑，下游有计算检查，扣库存等等。自然上游会比下游qps大。

如果可以异步，对执行失败可以容忍：可以把任务往mq中放，mq如果用主动推的方式，可以设置消费者线程数，慢慢处理。如果用拉的方式，可以自己慢慢拉取。

否则，必须要同步调用的场景：只能服务限流的方式，抛弃一部分请求。

对于削峰

总结：异步，解耦，削峰。

三、线程池和mq的区别
1、线程池是进程内队列，也是队列。
2、如果消息积压多了，用线程池的方式，会积压大量任务，消耗大量内存。
3、消息丢失，重试机制，持久化等，应答机制，如果消费者系统没有运行，则线程池调用的方式，直接导致，消息丢失了。
4、mq的解耦机制是线程池没有的。

四、mq的缺点
1、异步，这是最大的缺点。
2、引入组件，增加复杂度。

五、mq的高可用
activemq可以做主从。
rabbitmq可以做镜像集群。
rocketmq和kafka更不用说，比如rocketmq的name server集群、broker集群。
rabbitmq的普通的集群：每个节点只有元数据，获取数据的时候，去真正节点上去拉，所以做不到高可用，只是负载均衡了一下。镜像集群：则是每个节点有都有这个数据。

六、mq 如何保证幂等性
不管是发送、消费，如果网络原因，还没来得及ack应答，导致重复推送，就会导致重复消息的问题。
要根据业务来。
有写数据不需要保证幂等性，比如set或update操作。
比如数据库的唯一键约束，比如订单id，做一个唯一索引。
如果实在不好保证，只能存一个唯一id，然后处理前，查一下没有没处理过这个id。

七、如何保证消息的可靠性传输

比如activemq，消费者设置应答模式为同步模式，这样，在服务端没有给生产者应答之前，生产者一直堵塞。生产者设置消息持久化到硬盘，消费者设置手动应答模式，当真正消费了消息之后，才应答。

如果是rabbitmq的话：为了保证消息发布到rabbitmq成功以否，rabbitmq提供了回调确认机制，保证数据不丢失，当然事务也可以做到，但是性能不好，不常用，也有持久化和应答。

rocketmq也有同步写主从以及持久化和应答机制。

kafka不是很熟：kafka，kafka也可以通过配置，参数，必须写入多少台机器，才算写入成功。

八、如何保证消息的顺序性

一个queue对应一个消费者，就绝对是有序的，如果对应多个消费者自然就无序。

九、消息延迟、消息积压怎么处理？
1、修好consumer，然后可以临时增加consumer增加分担消费能力，比如rabbitmq，rocketmq，则直接新增消费者就可以。
2、如果不好这么做，可以新建一个临时queue，然后把消息转发过来，然后新的queue，用多个消费者消费。
3、如果对于rabbitmq，这种设置过期时间的，造成消息积压导致的消息丢失，则只能想办法找出丢失的数据，然后，再推送到mq中去。·