上次跟大家分享的文章「Kafka Producer 异步发送消息居然也会阻塞？」中提到了缓冲池，后面再经过一番阅读源码后，发现了这个缓冲池设计的很棒，被它的设计思想优雅到了，所以忍不住跟大家继续分享一波。

Kafka 一直以来都以高吞吐量的特性而家喻户晓，就在上周，在一个性能监控项目中，需要使用到 Kafka 传输海量消息，在这过程中遇到了一个 Kafka Producer 异步发送消息会被阻塞的问题，导致生产端发送耗时很大。

DataX 是阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库（MySQL、Oracle 等）、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。

最近在公司的数据同步项目（以下简称 ZDTP）中，需要使用到分布式调度数据同步执行单元，目前使用的方案是将数据同步执行单元打包成镜像，使用 K8s 进行调度。

我第一次接触容器编排调度工具是 Docker 自家的 Docker Swarm，主要解决当时公司内部业务项目部署繁琐的问题，我记得当时项目实现容器化之后，花在项目部署运维的时间大大减少了，当时觉得这玩意还挺新鲜的，原来自动化运维可以这么玩。后面由于工作原因，很久没碰过容器方面的知识了。最近在公司的数据同步项目中，需要...

RPC 模块是我最初研究 Seata 源码开始的地方，因此我对 Seata 的 RPC 模块有过一些深刻研究，在我研究了一番后，发现 RPC 模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着 “让天下没有难懂的 RPC 通信代码” 的初衷，我开始了 RPC 模块的重构之路。

最近因为全链路压测项目需要对用户自定义线程池 Bean 进行适配工作，我们知道全链路压测的核心思想是对流量压测进行标记，因此我们需要给压测的流量请求进行打标，并在链路中进行传递，那么问题来了，如果项目中使用了多线程处理业务，就会造成父子线程间无法传递压测打标数据，不过可以利用阿里开源的 ttl 解决这个问题。

丁老师在他的知识星球邀请我回答以下一个问题： 我觉得这个问题非常有意思，姑且把它贴到公众号这里，与大家分享一下我对这个问题的一些感悟。 感谢丁老师的邀请问答： 在这里我就简单说下，我这段时间参与 Seata 开源项目的一些感悟： 1、如何参与到开源项目中并贡献自己的一份力量？ 我一直都有上 GitHub 搜索一些主流...

在 2 月10 号下午大概 1 点半左右，收到用户方反馈，发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader，导致某些消息发送到该分区时，会报如下 no leader 的错误信息：

Seata 的动态降级需要结合配置中心的动态配置订阅功能。动态配置订阅，即通过配置中心监听订阅，根据需要读取已更新的缓存值，ZK、Apollo、Nacos 等第三方配置中心都有现成的监听器可实现动态刷新配置；动态降级，即通过动态更新指定配置参数值，使得 Seata 能够在运行过程中动态控制全局事务失效（目前只有 AT 模式有这...

之前发表了一篇关于重平衡的文章：「Kafka 重平衡机制」，里面有说到 RocketMQ 重平衡机制是每隔 20s 从任意一个 Broker 节点获取消费组的消费 ID 以及订阅信息，再根据这些订阅信息进行分配，然后将分配到的信息封装成 pullRequest 对象 pull 到 pullRequestQueue 队列中，拉取线程唤醒后执行拉取任务，流程图如下：

当集群中有新成员加入，或者某些主题增加了分区之后，消费者是怎么进行重新分配消费的？这里就涉及到重平衡（Rebalance）的概念，下面我就给大家讲解一下什么是 Kafka 重平衡机制，我尽量做到图文并茂通俗易懂。

还记得前几天有个小伙伴跟我反馈发送消息时提示请求数据过大的异常吗？经过调整 max.request.size 的大小之后，又报了了如下异常：

其中，如果是广播模式消费，消息的消费进度是保存到本地，如果是集群消费模式，消息的消费进度则是保存到 Broker，但无论是保存到本地，还是保存到 Broker，消费者都会在本地留一份缓存，我们暂且看看集群消费模式下，消息消费进度的缓存是如何保存的：

一般来说，选择主从备份实现高可用的架构中，都会具备读写分离机制，比如 MySql 读写分离，客户端可以向主从服务器读取数据，但客户写数据只能通过主服务器。

之前写了一篇关于 RocketMQ 队列与 Kafka 分区副本的区别文章，里面提到了 RocketMQ 的消息冗余主要是通过主备同步机制实现的，这跟 Kafka 分区副本的 Leader-Follower 模型不同，HA（High Available) 指的是高可用性，而 RocketMQ 的HA机制是通过主备同步实现消息的高可用。

过去几天，这个公众号粉丝数量突破 2000 人了，这个数量可能对于一些公众号来说，连零头都不到，但对于我来说，有这么一群小伙伴看我写的技术分享，我就觉得很满足了，你们就是我坚持继续分享下去的源动力，在这里感谢这 2000 个小伙伴，感谢你们对这个公众号的厚爱。

最近在学习 Kafka，发现其核心概念与 RocketMQ 还是存在一定的差别，下面我来说下 Kafka 分区 与 RocketMQ 队列之间的区别。

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 前段时间有个朋友向我提了一个问题，他说在搭建 RocketMQ 集群过程中遇到了关于消费订阅的问题，具体问题如下： 然后他发了报错的日志给我看： {代码...} 我第一时间在源码里找到了报错的位置： org.apache.rocketmq.br...

在微服务架构体系下，我们可以按照业务模块分层设计，单独部署，减轻了服务部署压力，也解耦了业务的耦合，避免了应用逐渐变成一个庞然怪物，从而可以轻松扩展，在某些服务出现故障时也不会影响其它服务的正常运行。总之，微服务在业务的高速发展中带给我们越来越多的优势，但是微服务并不是十全十美，因此不能盲目过度...

在 Java 的项目中，有 Maven 和 Gradle 这些很好用的依赖版本管理工具，简直不要太方便了，但是在 Golang 的项目中，之前的 Golang 官方并没有提供版本管理工具，我们以前用 go get 获取依赖其实是有潜在危险的，因为我们不确定最新版依赖是否会破坏掉我们项目对依赖包的使用方式，即当前项目可能会出现不兼容最新依赖包...

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！

微信公众号「后端进阶」，专注后端技术分享：Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授，带你一路进阶，来不及解释了快上车！