为什么要使用消息队列

1、什么是消息队列

通过先进先出或者双端进出的方式对数据进行管理，通过阻塞以达到自动平衡负载的功能。

2、系统中为什么要使用消息队列？

1. 系统间解耦（广告流水更新）

   当系统间没有实时的数据交换要求，但还需要其他业务信息是，可以通过消息队列来达到系统间解耦的作用，只要发布方定义好消息队列的格式，消费方的任何操作均可与发布方无关，减少了不必要的联调和发布冲突等影响。

2. 服务异步化（支付场景下的通知）

   在支付操作完成后，将支付结果发到短信通知中心指定的消息topic下

   让非核心的操作异步化，从而提高整个业务链路的高效和稳定。

   

3. 削峰填谷

   特殊场景下，比如秒杀、春晚红包等万亿流量的脉冲式压力下，消息队列可以保护系统免于崩溃。

   通过高性能的存储和处理能力，将超过系统处理能力的多余流量暂时存储起来，并在系统处理能力内平缓的释放出来，从而达到削峰的效果。

4. 其他

   比如广播、事务型、最终一致性等特性，也是消息队列中常用到的功能。

3、消息队列存在的问题

1. 业务上增加响应延迟

   消息队列使得业务费核心线程异步化，可以提高整个业务操作系统的时效性和流畅度，提升用户操作体验，但是，因为数据进入队列的原因，不可避免的会耽搁消费进度，导致业务生效不及时。

2. 架构上引入不稳定因素

   消息队列的引入，相当于在原有的分布式架构中新添了一个系统，使系统的复杂度变大。消息队列的因引入会诞生一些问题，比如 ： 怎样部署高可用的集群，消息发送不成功怎么办，broker数据同步，broker异常，消费不成功怎么重试

4、消息队列的使用

1. RocketMQ

   消费模式：

   • Push消费

     只适合消费速度远大于生产速度的场景

   • Pull消费

     针对大流量并发场景，在pull消费前，broker和client之间会进行负载均衡建立连接，一旦client宕机，就会导致broker‘中与client关联的队列消息无法被及时消费，导致积压。

   • POP消费

     可以解决积压问题，POP消费不去分配消费队列，取而代之的是请求所有的broker获取消息进行消费。broker内部会把自身的三个队列的消息根据一定的算法分配给等待的POPClient，即使其中一个client出现宕机现象，其他client也会消费内部的队列消息，从而避免消费堆积。

2. Kafka集群的平滑扩容

   要实现平滑，则需要让producer无感的实现partition迁移。

   大致原理是将待迁移partition的数据和新的partition数据进行同步并持续一段时间，直到消费者全部赶上同步的开始节点，然后再变更路由，删除原partition，完成迁移。

3. 针对Kafka缓存污染的优化

   kafka的高性能，来源于顺序文件读写和操作系统缓存pagecache的支持，在单partition，单consumer的场景下，kafka表现的非常优秀。但是，如果同一机器上，存在不同的partition,甚至，消费模式有实时和延迟消费的混合场景，将会出现PageCache资源竞争，导致缓存污染，影响broker的服务的处理效率

   • 将数据按照时间维度分布在不同的设备中，近实时部分的数据缓存在SSD中，当出现PageCache竞争时，实时消费作业从SSD中读取数据，保证实时作业不会受到延迟消费作业的影响

     当消费请求到达broker时，broker直接根据其维护的消息偏移量和设备关系从对应的设备中获取数据并返回，为防止出现的缓存污染，在读请求时不会讲HDD中的数据刷到SSD。同时访问路径明确，不会由于Cache Miss而出现额外的访问开销。

   • broker 中引入了两个对象：一个是 block cache；另一个是 flush queue。

     Producer 的写入请求在 broker 端首先会被以原 message 的形式写入 flush queue 中，之后再将数据写入到 block cache 的一个 block 中，之后整个请求就结束了。在 flush queue 中的数据会由其他线程异步地写入到磁盘中（会经历 page cache 过程）。保证queue不受follower的影响

     consumer 首先会从 block cache 中检索数据，如果命中，则直接返回。否则，则从磁盘读取数据。这样的读取模式保障了 consumer 的 cache miss 读并不会填充 block cache，从而避免了产生污染

   解决缓存污染的基本出发点，还是要拆解不同消费速度的任务，或者不同的数据生产来源，采用分而治之的思想避免相互间缓存的影响。

4. CMQ在红包支付场景下的使用

   由于账务系统能承载的压力有限(和账务相关的系统一般都会由于锁、事务等原因影响处理效率)，可能导致入账失败，如果按实时业务逻辑，则需要对拆红包进行实时回滚(回滚需要对A的账户再进行一次加法)，而引入CMQ后，业务链路变成将失败的请求写入CMQ，由CMQ的高可用来保证数据一致，直到账务系统最终入账成功。简化了账务系统由于系统压力而导致的入账失败而导致红包账务回滚带来的额外系统操作。