网站建设方式,输入法网站设计,官网是怎么做的,seo排名点来上海百首网络目录儿常见MQRocketMQ2、RocketMQ测试可用MQ常见问题1、幂等性问题2、如何保证消息不丢失3、消息积压问题4、事务消息设计分析常见MQ RocketMQ
RocketMQ又四部分组成
NameServer 同步Broker服务信息#xff0c;给消费者和生产者提供可用Broker的服务信息。Broker 消息存储业…
目录儿常见MQRocketMQ2、RocketMQ测试可用MQ常见问题1、幂等性问题2、如何保证消息不丢失3、消息积压问题4、事务消息设计分析常见MQ RocketMQ
RocketMQ又四部分组成
NameServer 同步Broker服务信息给消费者和生产者提供可用Broker的服务信息。Broker 消息存储业务核心Producer 消息生产者Consumer 消息消费者 先启动NameServer作为注册中心然后再启动Broker服务。 2、RocketMQ测试可用
在RocketMQ的安装包中提供了一个tools.sh工具可以用来在命令行快速验证RocketMQ服务。进入RocketMQ的安装目录 ① 首先需要配置一个环境变量NAMESRV_ADDR指向我们启动的NameServer服务。
export NAMESRV_ADDRlocalhost:9876② 然后执行工具脚本启动消息生产者发送消息默认会发1000条消息
bin/tools.sh org.apache.rocketmg.example.quickstart.Producer③ 然后执行工具脚本然后启动消息消费者接收消息
bin/tools.sh org.apache.rocketmg.example.quickstart.Consumer成功了表单机服务就搭建好了
MQ常见问题
1、幂等性问题
通常。客户端调用服务端接口是通过http协议来调取的不安全且整个调用过程是一个同步过程。服务端处理业务逻辑比较耗时没有及时响应的情况下于服务端而言产生了请求堆积可能会造成 服务雪崩。于客户端会造成阻塞等待、超时断开 自动重试这样服务器端接口就在一段时间内接收到了n个相同的请求产生了 幂等性问题
如何防止幂等性问题通用做法
如表单重复提交、add表数据可以用全局id做唯一约束如重复update表数据可以用版本号防止重复修改每次修改都基于版本号 幂等性 所谓的幂等性是分布式环境下的一个常见问题一般是指我们在进行多次操作时所得到的结果是一样的即多次运算结果是一致的(同一个业务逻辑重复执行多次最终只算一次)。 也就是说用户对于同一操作无论是发起一次请求还是多次请求最终的执行结果是一致的不会因为多次点击而产生副作用。常见幂等性操作 select查询天然幂等delete删除也是幂等删除同一个数据多次其效果一样;update直接更新某个值时幂等update更新累加操作的的结果非幂等insert操作会每次都新增一条非幂等 什么情况下会产生重复提交(非幂等性) 连续点击提交两次按钮点击刷新按钮使用浏览器后退按钮重复之前的操作导致重复提交表单使用浏览器历史记录重复提交表单浏览器重复地HTTP请求等。 2、如何保证消息不丢失 引入MQ消息中间件最直接的目的是做系统解耦合流量控制追其根源还是为了解决互联网系统的高可用和高性能问题 引入MQ虽然实现了系统解耦合流量控制也会带来其他问题 其中保证数据传输的一致性就是保证消息不丢失的关键
消息从生产到消费不同环节发生消息丢失对应的原因不同解决方案也不同所以要分开来说 上面三个环节的解决方案看似完美但在分布式系统中常常出现各种故障且不可避免所以还是需要一种机制来检查消息是否丢失
总体方案思路 在消息生产端给每个发出的消息都指定一个全局唯一D或者附加一个连续递增的版本号然后在消费端做对应的版本校验
具体实现思路1 可以利用拦截器机制在生产端发送消息之前通过拦截器将消息版本号注入消息中然后在消费端收到消息后再通过拦截器检测版本号的连续性或消费状态这样实现的好处是消息检测的代码不会侵入到业务代码中可以通过单独的任务来定位丢失的消息做进一步的排查 不同的唯一ID生成方案也会有不同的问题存在没有完美的方案。
3、消息积压问题
如果出现积压那一定是性能问题想要解决消息从生产到消费上的性能问题就首先要知道哪些环节可能出现消息积压然后在考虑如何解决。
因为消息在生产并发送到Broker之后才会出现积压问题所以问题不在生产端而又因为在绝大部分消息队列单节点性能都能达到几万/s的处理能力所以问题大概率也不在存储端上。所以性能问题绝大多数出现在消费端。
应急处理方案 如果是线上突发问题就要临时扩容增加消费端的数量(水平扩容)与此同时还可以降级一些非核心的业务通过扩容和降级抗住流量。 扩容的同时要增加分区防止扩容失效。 逻辑优化方案 排查解决异常问题比如通过查看监控日志等手段分析是否消费端的业务逻辑代码出现了问题进而优化消费端的业务处理逻辑提升消费能力。
4、事务消息设计分析
如下场景用户操作下单我们首先需要生成一条订单信息然后库存系统需要针对订单中的商品进行库存扣减的操作。这两步操作必须保证数据的一致性否则会出现库存超扣等情况。
第一种情况如图所示在本地事务提交前发送事务消息。若在创建订单信息时发生了异常而此时事务消息已经成功发送库存系统消费事务消息就会导致订单并没有创建成功而库存却被扣减。 进而有了第二种情况如图所示在本地事务提交完成后再发送事务消息。若在发送事务消息的过程发生了异常如网络波动等等将会出现订单已创建完成而库存系统永远也监听不到消息导致库存无法正常扣减。 综合第一和第二种情况汇总成第三种方案如图所示。在本地事务执行前先向MQ发送前置的Prepared消息在本地事务执行完毕后再发送确认的消息告知MQ当前事务消息需提交/回滚。如果事务正常则提交消息那么这条消息将会被消息消费方监听到如果事务回滚MQ会丢弃这条消息消息消费方无法监听到这条消息。以上情况对应 事务消息生产者的设计思路 图中的 1、2、3、4步骤。 继续分析如果上图的第二步中发送确认消息的过程中出现异常没有发送成功怎么办RocketMQ会定期默认60s扫描Prepared消息如果迟迟没有收到确认消息将会执行事务回查的逻辑主动去消息生产方确认事务状态。对应 事务消息生产者的设计思路 图中的 5、6、7步骤。综上是事务消息中生产者的设计思路保证本地事务和事务消息一致性。 如上图中在事务消息者中如果步骤4返回了消费失败或者超时未响应的情况怎么办RocketMQ对待事务消息的处理和普通消息一样。如果消费失败或超时将会把这条消息加入到重试队列中不断是重复执行步骤3、4如果重复的次数达到阈值那么可能需要人工介入处理。
如果消费方本地事务执行成功仅仅是在确认消息时失败呢 那么这里又会出现另一个问题 重复消费 这里就需要具体的业务模块去处理消息的幂等性。如接住Redis来处理。如在本地事务执行前先去查询redis中当前消息是否已经消费执行成功后再向redis写入一条成功消费的记录这样就能保证消费不会被重复消费了。 参考资料 哔哩哔哩 余胜军 BAT大厂消息中间件MQ常见面试题及答案你能搞懂有哪些 https://www.bilibili.com/video/BV1zK4y1e7kS?share_sourcecopy_web如何解决幂等性问题 - Java马剑威的回答 - 知乎 https://www.zhihu.com/question/534651475/answer/2542377973哔哩哔哩 so贝塔 MQ如何回答消息队列的丢失、重复与积压问题 https://www.bilibili.com/video/BV1F8411g7LF?share_sourcecopy_web哔哩哔哩 图灵教育-诸葛 这可能是B站讲的最好的RocketMQ实战教程全套完整版2023年最新版 https://www.bilibili.com/video/BV1DY41127Be?p2share_sourcecopy_web 5.CSDN Rooibos gron RocketMQ事务消息 https://blog.csdn.net/qq_42877546/article/details/125404307
