高级JAVA开发 MQ部分

2023-11-14

高级JAVA开发 MQ部分

MQ

参考和摘自：
中华石杉《Java工程师面试突击第1季》
ActiveMQ—知识点整理
 消息总线真的能保证幂等
 ActiveMQ消息传送机制以及ACK机制详解

MQ的作用、为什么要用MQ

解耦、异步、消峰

应用场景：

解耦：利用发布/订阅（Publish/Subscribe）模型，多服务订阅同一queue，省去生产者主动调用并维护多个消费者（service），消费者可随时unSubscribe，生产者并不感知。
异步：利用点对点（ Point-to-Point）模型，将多个任务分别放到不同队列中，之后直接返回。消费者各自从不同队列取得任务并消费。这么做的好处是不用阻塞等待多个任务全部返回再响应用户操作，加速响应。
消峰：利用点对点（ Point-to-Point）模型，在系统请求高峰期不采用阻塞式调用，将任务全部打入MQ中，让系统调用链中消费者慢慢消化任务。防止系统被访问高峰打死（很大原因是直接访问数据库，数据库成为瓶颈，后面也会在缓存章节继续分析）。

常见的MQ的优缺点

摘自中华石杉老师的笔记

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级吞吐量比RocketMQ和Kafka要低了一个数量级	万级吞吐量比RocketMQ和Kafka要低了一个数量级	10万级 RocketMQ也是可以支撑高吞吐的一种MQ	10万级这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
时效性	ms级	微秒级这是rabbitmq的一大特点，延迟是最低的	ms级	延迟在ms级以内
可用性	高基于主从架构实现高可用性	高基于主从架构实现高可用性	非常高分布式架构	非常高 kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据		经过参数优化配置，可以做到0丢失	经过参数优化配置，消息可以做到0丢失
功能支持	MQ领域的功能极其完备	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
优劣势总结	非常成熟，功能强大，在业内大量的公司以及项目中都有应用。偶尔会有较低概率丢失消息。而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本。而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用。	erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备而且开源提供的管理界面非常棒，用起来很好用社区相对比较活跃，几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。	接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的	kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集

使用MQ带来的问题以及处理办法

MQ带来的问题列举

系统可用性降低，需要保证MQ健康的运行，否则MQ挂掉会导致整个应用不可用，后果难以设想。
系统的复杂性变高，比如消息重复消费、消息丢失等等，需要用一些手段来处理，怎么处理接下来细说，这里将会成为重要考点。
一致性问题（分布式事务）。A、B、C、D四个任务必须同时成功，放入MQ后A、B、C都成功了，偏偏D任务失败了该如何处理。这也是重要考点。

消息重复消费（幂等）问题

消费者拿到消息但是还没来得及ACK（或者还没来得及提交offset）就挂掉了，重启后会重新拿到已经消费但是还没通知（ACK）给MQ的消息，就产生了重复消费问题。（PS：这里如果MQ采用AUTO_ACK模式，消费者拿到消息后会第一时间给MQ做出ACK反馈，之后再去消费消息。但还没来得及消费完就挂掉了，那么MQ会认为此条消息处理过了，消费者重启后会继续从MQ拿消息，会产生消息丢失的问题，参看：<消息丢失问题>章节）
解决办法：
数据携带唯一id，基于内存Map或Set、Redis、数据库唯一键，保存消费成功的数据，重复数据来第二次时候可以感知到并直接丢弃处理。

面试遇到过这么一个问题：
面试官：有100w用户电话号码数据在数据库中，并不保证其中是否有重复，要求为每一个用户发一条短信并且不可重复发送，现提供一个基于http的短信发送微服务，该如何设计架构，最简单最快的把短信发送出去？

我的思路：
1.数据量过大，不能在数据库上做去重，并且用多线程读取更快。
2.短信服务会成为瓶颈，需要缓冲。
3.怎么在消费的过程中直接过滤掉重复消息。

我：用多线程读取数据（计算好多少页，每个线程取多少次，一次取多少条）将用户数据灌入MQ，多个消费者从MQ取得数据先在Redis中读一下看看有没有消费过，并在Redis中存入消费过的电话号码，调用短信服务（多部署几个）发送。重复电话号码直接舍弃数据不消费。
接着面试官问：如果就有那么几个消费者同时取到电话号码，巧了，他们取到的电话号码相同，查了一下Redis，没人发送过，就有重复发送的问题，怎么解决。
我：呃…

回来想了一下这个问题，因为先读取Redis再写入Redis并不能保证原子性，出现了并发问题。采用和分布式锁相同的思想来解决这个问题。参考下面文章：
Redis分布式锁的正确实现方式
用Redis的set加入NX（SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；）参数保证set原子性并且取得返回值。完美解决~~~

PS：

Redis是主从集群，上述分布式锁会有漏洞。Redisson分布式锁实现框架可以弥补漏洞。（slave节点异步同步master数据，有延时。master节点设置锁还未同步到slave时挂掉了，锁就失效了）

由于本人技术水平有限，上述的架构方案并不是最优的，读文章小伙伴有更好的解决方案请发邮件给我，不胜感激~~~~

消息丢失问题

1.生产者发送消息丢失：

生产者发送消息到MQ过程中，网络原因丢了。

MQ接收到消息后内部出错，没保存下来。

解决办法：
1.用事务，发送时用try catch包裹发送消息代码块，如果发送失败可以拦截Exception再做进一步处理（重发或者…）
事务机制是同步阻塞的，影响发送消息吞吐量。
2.（RabbitMq）利用 confirm机制。把channel设置成confirm模式，发送结果通知给本地实现的接口，如果通知失败再做进一步的处理（重发或者…）异步不会阻塞，吞吐量高

2.MQ本身问题丢失：

MQ挂掉了导致内存中消息丢失

解决办法：配置持久化。但是也有一种可能，消息接收到了但是还没来得及持久化就挂掉了，还是会丢失一点点数据。

3.MQ到消费者消费过程中导致的丢失，消费端弄丢了数据

消费着拿到消息但是还没来得及消费就挂掉了，MQ以为消费者已经处理完了

解决办法：关闭AUTO_ACK，采用CLIENT_ACK模式，客户端收到消息处理成功后再手动发送ACK给MQ。如果消费者挂掉了，MQ针对这条消息会ACK超时，重新发给别人继续消费。

消息顺序性问题

这里假设要处理一个订单的三个任务，三个任务为一组：

RabbitMQ等非分布式MQ解决方案：
思路：将同订单任务按顺序放到一个Queue中，一个消费者只从一个Queue消费。

这里不能建立无穷多个Queue，将订单号的hash值对Queue个数取余分发到对应Queue中即可。
Kafka等分布式MQ解决方案：
参考：kafka topic消息分配partition规则（Java源码）
思路：由于Kafka是分布式的，每个Queue中的数据会分布到多个partition中。Kafka可以保证每个partition中的数据是有顺序的，那么指定key（比如订单ID），将需要保证顺序的任务放到同一partition中（kafka会把key值一样的任务放到一个partition中，和上述订单号对Queue个数取余原理相同），一个消费者只能从一个partition消费，这样就保证了按顺序执行。

如果消费者是多线程并发的从partition取得数据，多线程不能保证执行顺序，那么上述模型就不好用了。
解决办法：在消费者端建立多个线程安全的队列（比如LinkedBlockingQueue，这里我认为采用阻塞队列比较好，省得消耗jvm内存过多导致oom异常），从MQ取得任务，将相同订单号的任务发送到同一个队列（也可以用hash取余的办法），再对每一个队列启动一个线程消费任务，保证顺序执行。
在这里插入图片描述

消息过期丢失、大量积压等问题

过期问题：
一般不设置消息的过期时间。如果设置了过期时间，只能在事后从数据源头找出数据，写程序将数据重新发送到MQ中。
大量积压后如何快速消费：
ActiveMQ、RabbitMQ等非分布式MQ单个Queue数据量过大增加临时MQ节点也不能解决问题（每个节点存储全量数据），需要增加消费者临时节点来加速消费。
Kafka是分布式MQ，每个消费者只能指定一个partition消费，那么新建立一个更多节点的Kafka集群，增加临时服务将原Kafka集群中的数据直接分发到新Kafka集群，这样消息会平均分配到更多的机器中，减缓MQ压力，再针对新Kafka集群添加实际业务处理的消费者，增加消费速度即可。
MQ积压导致磁盘空间不足：
（Kafka）增加临时消费节点将消息写到临时MQ集群中。
或者增加临时消费者拿到数据直接将数据扔掉，事后做补偿。防止MQ直接压垮掉导致整个系统不可用。

如何保证MQ高可用性

RabbitMQ高可用以及部署模式

单机模式，普通集群模式，镜像集群模式

单机模式
普通集群模式：
集群中Master保存Queue元数据（Queue的属性之类的数据）和Queue数据，slave只保存Queue的元数据，在访问slave节点时，slave去和主节点通信取得Queue数据。
总结：
优点：提高消费吞吐量
缺点：1. 性能开销大，在集群内部产生大量数据传输 2.可用性几乎没有保障，主节点挂掉了，整个MQ不可用。
镜像集群模式：
所有节点都保存Queue的所有数据。在写入数据时，各个节点自动同步。消费数据时同样。
总结：
优点：高可用，单个节点挂掉不影响整个集群
缺点：1.性能开销大，需要所有机器同步所有数据。 2.不是分布式的，单Queue数据量超级大，超出单机最大容量时无法处理。 3.扩展性很差，和第2点一样，加机器也不能缓解数据量超级大的问题。

如何开启镜像集群模式

在管理控制台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点，也可以要求同步到指定数量的节点，然后再次创建Queue的时候应用这个策略，就会自动将数据同步到其他的节点上去了。

kafka的高可用性

多个broker组成，每个broker是一个节点；创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition放一部分数据。（可以理解为每个Queue的数据被划分到不同机器上，换言说每个机器都持有同一个Queue的一部分数据）。在0.8版本以前没有HA机制，其中一台机器宕机则数据直接丢失。0.8版本后可以针对每个partition设置多个broker，其中一台是leader节点，其余是follower节点，只有leader节点提供对外读写服务，数据读写自动同步到follower节点，如果leader挂掉，follower们通过选举算法选举一个follower作为新的leader继续提供服务。

$摘自中华石杉《Java工程师面试突击第1季（可能是史上最好的Java面试突击课程）\06_引入消息队列之后该如何保证其高可用性？\视频\04》$ 图片摘自中华石杉《Java工程师面试突击第1季（可能是史上最好的Java面试突击课程）\06_引入消息队列之后该如何保证其高可用性？\视频\04

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

技术栈