RocketMQ——事务消息原理分析
事务消息交互流程 图片摘自官网 事务消息发送步骤如下（摘抄自官网）： 1、生产者将半事务消息发送至 RocketMQ Broker 2、RocketMQ Broker 将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息暂不能投递，为半事务消息。 3、生产者开始执行本地事务逻辑。 4、生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务
RocketMQ——MessageQueue选择和故障延时机制
！！！RocketMQ在发消息之前会先从当前订阅信息中选择出一个比较合适的MessageQueue，本文主要针对MessageQueue以及在选取MessageQueue时相关的故障延时策略展开说明 MessageQueue选择MessageQueue选取相关逻辑时在消息发送是调用sendDefaultImpl方法逻辑中，在进行MessageQueue选择之前，会先获取当前的消息对应Topic的订
RocketMQ——消息重试原理分析
背景RocketMQ中Producer在发送消息的时候，可能存在发送失败的情况（如网络通信、部分Broker异常等），RocketMQ默认支持了失败重试机制，本文基于上一篇文章 https://blog.5iwork.com/post/efbf9e99.html/ 展开对消息重试进行分析和说明 RocketMQ中对重试机制几个配置，可支持用户自定义配置： retryTimesWhenSendFa
RocketMQ——同步消息、异步消息发送源码分析
RocketMQ中，消息发送模式有三种,如下：12345public enum CommunicationMode { SYNC, ASYNC, ONEWAY,} SYNC：同步消息同步消息会阻塞等待消息发送结果 ASYNC：异步消息异步消息发送消息时间，不会等待消息结果，对应的消息回调结果会到相应的Callback回调函数里面返回，不会阻塞用户线程，吞吐
RocketMQ——NameServer消息路由和Broker管理
Nameserver 作用  RocketMQ架构体系中，是承担注册中心这个角色的，主要有两个作用： 消息路由管理 Broker在启动后，会定时向Nameserver上报Broker相关的信息，Nameserver在收到Broker上报的信息后，会将这些信息保存在内存中（通过RouteInfoManager管理），供Producer和Consumer使用，达到消息路由的目的 Brok
记一次测试环境因代码覆盖率代理对象jacocoagent引起的NoSuchMethodException
背景不同环境运行会有不同的效果，生产和开发环境正常，测试环境异常 原因查看FAT环境JVM信息，有如下配置 123-javaagent:/xxx/xxx/jacocoagent.jar=includes=*,output=tcpserver,address=*,port=6300-javaagent:/xxx/xxx/data/vanda_agent.jar=classpath=/bankapp/
分布式锁实现----Zookeeper
设计思路主动轮询心跳… 弊端：延时，压力大，资源浪费 基于watch实现，有如下两种方式 watch 某一个节点可以解决延时问题，弊端：如果client很多很多的话，这把锁被释放之后，zk会回调所有的watch这个节点的client，所有client就会去抢锁、无疑会造成抢锁压力问题，这个时候就可以通过使用序列节点+watch这个机制实，不建议 sequence+watch 可以在节点的父目录上创
分布式锁实现----Redis+Lua脚本
说明：每个lua 脚本中的操作都是原子操作 实现步骤在resources目录下新建 lua 脚本 /resources/luascript/lock-del.lua 12345if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1])else return 0e
