Apache RocketMQ

消息中间件—RocketMQ消息消费（一） 消息中间件—RocketMQ消息消费（二）（push模式实现） 消息中间件—RocketMQ消息消费（三）（消息消费重试） MQ中Pull和Push的两种消费方式 Push方式 由消息中间件（MQ消息服务器代理）主动地将消息推送给消费者；采用Push方式，可以尽可能实时地将消息发送给消费者进行消费。但是，在消费者的处理消息的能力较弱的时候(比如，消费者端的业务系统处理一条消息的流程比较复杂，其中的调用链路比较多导致消费时间比较久。概括起来地说就是 “慢消费问题” )，而MQ不断地向消费者Push消息，消费者端的缓冲区可能会溢出，导致异常； Pull方式 由消费者客户端主动向消息中间件（MQ消息服务器代理）拉取消息；采用Pull方式，如何设置Pull消息的频率需要重点去考虑，举个例子来说，可能1分钟内连续来了1000条消息，然后2小时内没有新消息产生（概括起来说就是 “消息延迟与忙等待” ）。如果每次Pull的时间间隔比较久，会增加消息的延迟，即消息到达消费者的时间加长，MQ中消息的堆积量变大；若每次Pull的时间间隔较短，但是在一段时间内MQ中并没有任何消息可以消费，那么会产生很多无效的Pull请求的RPC开销，影响MQ整体的网络性能； RocketMQ消息消费的长轮询机制 RocketMQ的消费方式都是基于拉模式拉取消息的

前不久，朋友的公司，出现了比较大的故障。故障引起的原因也比较好解释，因为使用了ActiveMQ的高可用级别(M-S架构，双写完成ACK），结果在高峰期间，造成了生产端消息拥堵，诸多请求无法落地，数据错乱。 背景 据他说，他们的应用，级别比电信应用还要高（牛皮一定要吹），所以消息系统要求一条消息都不能丢。他做到了，但是服务不能用了。 这个Case有何而来呢？据说是来自一次高管会议上，某位领导对其中的一个小问题情绪激动：他测试环境测试的某条数据，直接不见了，生产环境并未复现。矛头最终指向了消息系统，直接上升到断电后怎么办云云。 领导发威，事情要特事特办。架构组扯蛋似的熬夜讨论了改进的方案，从Kafka到RocketMQ，从落盘DB到升级到StoreHA方案，不亦乐乎。最终的讨论结果，就是采用极高可用的方式。领导的条件满足了，消息系统也是高可用的，但整个业务不是。最终的MQ吞吐量，连个DB都不如。 典型的枪杆子需求引起的优化故障。一定不少见。 思考 高可用是个伪命题，虽然有CAP等耳熟能详的理论支持，还是有很多人陷入了这个误区，包括技术决策人。架构作为全局把控人，能出现这样的错误，纯属低级。下面，是我自己对高可用的一点思考。 高可用不是组件高可用，是业务高可用 拿消息队列来说，并不是说保证消息队列的存活和消息的可靠，就完成了工作。还需要考虑生产端和消费端的拓扑和高可用。比如

友情提示：全文1000多文字，预计阅读时间5分钟 来自中国移动云能力中心云计算产品部PaaS平台产品组的工程师刘唯一被Apache SkyWalking的PMC投票成为新的committer！ Apache SkyWalking是什么 SkyWalking是一个APM（应用程序性能监视器）系统，专门为微服务、云原生和基于容器（Docker/Kubernetes/Mesos）的体系结构而设计。 SkyWalking可以用来做什么 在大型网站系统设计中，随着分布式架构，特别是微服务架构的流行，我们将系统解耦成更小的单元，通过不断的添加新的、小的模块或者重用已经有的模块来构建复杂的系统。随着模块的不断增多，一次请求可能会涉及到十几个甚至几十个服务的协同处理，那么如何准确快速的定位到线上故障和性能瓶颈，便成为我们不得不面对的棘手问题。Google在论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中提出了分布式跟踪系统的设计和构建思路。在这样的背景下，Apache SkyWalking创建于2015年，2019年毕业成为Apache顶级项目。它参考Dapper论文实现分布式追踪功能，并逐渐进化为一个完整功能的Application Performance Management系统，用于追踪

友情提示：全文1000多文字，预计阅读时间5分钟 前言 在当下万物互联的浪潮下，无论企业还是个人，数据上云已经进行的如火如荼。 5G+移动云产品新功能也在不停地迭代发布上线，其中有些产品能力依赖底层虚拟化组件的新功能新特性，比如保证在不中断用户业务的情况下达到虚拟化组件在线升级的目的，为云上产品新功能成功上线提供助力。 面临的问题 目前主流的解决方案是使用虚拟化热迁移技术，但是云环境中虚拟机的热迁移存在迁移周期长，成功率低，运维工作量巨大的问题，因为目前 虚拟机的热迁移技术（libvirt层）仅仅局限于异地迁移，即将虚拟机从一台物理服务器迁移到另一台远端的物理服务器，这样带来的问题就是： 虚拟机的所有数据要通过网络进行传输，给线上网络带宽带来很大压力 当网络带宽成为迁移的瓶颈时，高负载虚机无法完成传输导致迁移失败 针对以上问题，社区主要从减少数据的生成和压缩传输数据两个方向进行了优化，但是对于带宽受限，负载极高的虚机来说，效果基本看不见。就现有环境测试来看，脏页达到250M/s左右时，即便各种优化特性全开，也难逃迁移失败的命运。 因此，面对云上版本升级的迫切诉求： 突破带宽限制，无视虚机负载，尽量保证100%成功迁移 保证迁移成功的同时，大大缩短迁移时间，以减轻运维负担 考虑到版本升级的特殊性（不同于负载均衡必须跨节点），如果有一种方法可以在本地就能完成虚机的版本升级

1)其实我一直想让自己框架做到最简化的，最好是一个进程部署到一台物理机器上就完事。 2)而且涉及到的环境要足够的少，比如：能用mysql解决问题，那么redis之类的我就不用考虑了。少点环境少点bug！ 3)但是如果考虑到分布式的内容，那么RocketMQ还是要上场的，用于发布和订阅，网关收到消息后，将结果转发给其它的业务服务器， 之前如果用网关直连业务服务器的话，会成：网状结构，不是特别方便管理. 因此我倾向于用MQ去解耦，分发消息。 Redis也是可以做发布订阅，而且更加轻量级，但是：消息只能消费一次，这点不太好，比如：玩家掉线了，需要通知所有的服务，那就不太好处理了。 因此Redis是有应用场景的：缓存、分布式锁、分布式唯一ID生成等。 来源： oschina 链接： https://my.oschina.net/u/4391429/blog/4941064

事务消息介绍 事务消息貌似是阿里提出的分布式事务解决方案，依赖于RocketMQ的事务消息实现（ RocketMQ事务消息 ）。 其核心是通过MQ类似于DB的事务提交或回滚功能+MQ主动回查机制(MQ请求应用)来确保最终的消息确认动作。 它的实现原理也比较简单，我们可以基于上一篇“ 分布式事务（四）：本地消息表 ”对照理解。 在本地消息表实现方案中，由于MQ不支持(或者不使用)事务，我们无法确保最终消息投递结果和数据库事务是否保持一致，所以加入了定时任务+本地消息表来进行消息重发机制保障最终一致性。 但是这样使每个服务都存在定时任务和消息表，导致代码逻辑以及数据库表设计和业务耦合严重；所以在事务消息中，将这一部分功能交给MQ进行实现。 MQ事务消息 RocketMQ是支持事务的，其实现原理也是二阶段提交。 也就是说我先发起一个发送消息的动作，但是这个动作类似于db中的声明了一个事务并执行了sql，此时并没有确认提交或者回滚。 然后进行业务处理，处理成功这提交，失败则回滚。 事务消息的回查机制 事务消息回查机制是指，假设客户端发起了一个发送消息的动作，但是后续没响儿了；那MQ怎么办呢，也不能傻等着。 所以MQ就主动的请求服务发起方，来进行询问；这个就是回查机制。 回查机制需要服务发起方进行接口的提供。 事务消息模型 这里画了一个事务消息大致流程： 我们跟着图来解读一下：

微服务架构已成为了互联网的热门话题之一，而这也是互联网技术发展的必然阶段。然而，微服务概念的提出者 Martin Fowler 却强调：分布式调用的第一原则就是不要分布式。 纵观微服务实施过程中的弊端，可以推断出作者的意图，就是希望系统架构者能够谨慎地对待分布式调用，这是分布式系统自身存在的缺陷所致。但无论是 RPC 框架，还是 REST 框架，都因为驻留在不同进程空间的分布式组件，而引入了额外的复杂度。因而可能对系统的效率、可靠性、可预测性等诸多方面带来负面影响。 信用算力自2016年开始实施微服务改造，通过消息队列（Message Queue），后文简称MQ，来规避微服务存在的缺陷，实现金融级数据服务。以下是一些使用场景和心得。 为什么需要 MQ 一、案例介绍 先来看一个当前的真实业务场景。 对于通过信息流获客的企业而言，当用户注册时，因业务需求会调用用户服务，然后执行一系列操作，注册 -> 初始化账户信息 -> 邀友奖励发放 -> 发放优惠券 -> ... -> 信息流数据上报。 用户服务的开发人员压力非常大，因为需要调用非常多的服务，业务耦合严重。如果当时账户服务正在执行发版操作，那么初始化账户动作会失败。然而平台经过不断的迭代更新，后续又新增了一个签到业务，新注册用户默认签到一次。这就需要修改用户服务，增加调用签到服务的接口。每当遇到此种情况

前言 2020 年微众银行在 GitHub 上正式开源了 EventMesh。 EventMesh 和 DeFiBus一起作为微众银行已经开源的项目，目前支撑了微众银行每天亿级的金融交易。 作为一个动态插件式云原生基础服务，EventMesh 提供了灵活，可靠和快速的事件分发与处理，并且可进行管理。本篇文章将围绕 EventMesh 起源及原理等方面进行介绍，并结合微众银行的实践经验带领大家一起探索事件驱动架构。 01 什么是事件驱动架构 近年来，随着微服务、云原生和 Serverless 概念的普及以及容器化技术的发展，事件驱动也再次成为热点，引起IT界广泛的关注。事件驱动架构是一种用于设计应用的软件架构和模型。对于事件驱动系统而言，事件的捕获、通信、处理和持久保留是解决方案的核心结构。事件驱动架构可以最大程度减少耦合度，很好地扩展与适配不同类型的服务组件，因此是现代化分布式应用架构的理想之选。 解耦 基于这种松耦合，微服务可以用不同的语言实现。解耦后的微服务能够轻松地在网络上相互独立地扩展，通过动态添加或删除事件生产者和消费者来修改他们的系统，而不需要更改任何微服务中的任何逻辑。 基于推送通知的消息传输机制 事件驱动的体系结构中，客户端无需轮询就可以接收更新，事件在到达事件存储后就会通知给客户端，客户端可以随时接收更新，这对于动态数据转换、分析和数据科学处理非常有用。

前言 上一篇文章《spring中这些能升华代码的技巧，可能会让你爱不释手》发表之后，受到了不少读者的好评，很多读者都在期待续集。今天非常高兴的通知大家，你们要的续集来了。本文继续总结我认为spring中还不错的知识点，希望对您有所帮助。 一. @Conditional的强大之处 不知道你们有没有遇到过这些问题： 某个功能需要根据项目中有没有某个jar判断是否开启该功能。 某个bean的实例化需要先判断另一个bean有没有实例化，再判断是否实例化自己。 某个功能是否开启，在配置文件中有个参数可以对它进行控制。 如果你有遇到过上述这些问题，那么恭喜你，本节内容非常适合你。 @ConditionalOnClass 问题1可以用@ConditionalOnClass注解解决，代码如下： public class A { } public class B { } @ConditionalOnClass(B.class) @Configuration public class TestConfiguration { @Bean public A a() { return new A(); } } 如果项目中存在B类，则会实例化A类。如果不存在B类，则不会实例化A类。 有人可能会问：不是判断有没有某个jar吗？怎么现在判断某个类了？ ❝ 直接判断有没有该jar下的某个关键类更简单。 ❞

三、控制台的使用 1. 切换语言为简体中文 上图首页即为“驾驶舱”标签下的图标，中共有4个图： - Broker TOP 10 ：是指前10个Brokder处理消息的数量。比如从上图可以看出来，我只有一个Brokder，并且此Brokder处理了1000条消息. - Broker 5min trend: 此图标可以筛选出某个Topic下5分钟的消息数量，可以切换时间，所以就相当于可以查看某个Topic下的消息数量趋势。 - 剩余2个图没搞懂含义。 2. 切换namesrvAdd 3. 集群 4. 主题 1.状态 2. 发送消息 5.消息 可以参考 “消息查询” 这篇文章。 5.消费者 消费详情 ———————————————— 版权声明：本文为CSDN博主「GNG」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/so_geili/article/details/90142461 来源： oschina 链接： https://my.oschina.net/u/4347039/blog/3346462