<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[后端进阶]]></title><description><![CDATA[微信公众号「后端进阶」，专注后端技术分享！]]></description><link>https://blog.csdn.net/zchdjb</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; zchdjb]]></copyright><item><title><![CDATA[四年磨一剑：我是如何拿到蚂蚁offer的？]]></title><link>https://blog.csdn.net/zchdjb/article/details/116103072</link><guid>https://blog.csdn.net/zchdjb/article/details/116103072</guid><author>zchdjb</author><pubDate>Sat, 24 Apr 2021 20:08:03 +0800</pubDate><description><![CDATA[萌芽
我大学学的并非计算机，学的是机械工程，课程仅接触过汇编语言以及一点 C 语言，当时也算有一点点计算机编程基础吧，我一点都不喜欢这个专业，除了上单片机汇编课程时比较感兴趣。
机械这个专业我不但不喜欢，还完全看不到未来，像一滩死水，自己就像一个温水里的青蛙，逐渐地死去。还好在死去前的一刻我终于想清楚了，转行！无论如何，我也要丢掉「专业」这个沉重的包袱，跟这个天坑的专业说再也不见。
我也渐渐地不会去趋于平庸委屈求全地度过年轻的岁月，人生本就应该去追寻源于内心真实的自己，而不该满足于现状，趋于平庸委曲求全。
]]></description><category></category></item><item><title><![CDATA[中通消息平台 Kafka 顺序消费线程模型的实践与优化]]></title><link>https://blog.csdn.net/zchdjb/article/details/110427195</link><guid>https://blog.csdn.net/zchdjb/article/details/110427195</guid><author>zchdjb</author><pubDate>Tue, 01 Dec 2020 11:55:30 +0800</pubDate><description><![CDATA[各类消息中间件对顺序消息实现的做法是将具有顺序性的一类消息发往相同的主题分区中，只需要将这类消息设置相同的 Key 即可，而 Kafka 会在任意时刻保证一个消费组同时只能有一个消费者监听消费，因此可在消费时按分区进行顺序消费，保证每个分区的消息具备局部顺序性。由于需要确保分区消息的顺序性，并不能并发地消费消费，对消费的吞吐量会造成一定的影响。那么，如何在保证消息顺序性的前提下，最大限度的提高消费者的消费能力？
本文将会对 Kafka 消费者拉取消息流程进行深度分析之后，对 Kafka 消费者顺序消费线程模]]></description><category></category></item><item><title><![CDATA[Kafka Producer 异步发送消息居然也会阻塞？]]></title><link>https://blog.csdn.net/zchdjb/article/details/108565667</link><guid>https://blog.csdn.net/zchdjb/article/details/108565667</guid><author>zchdjb</author><pubDate>Sun, 13 Sep 2020 18:13:46 +0800</pubDate><description><![CDATA[Kafka 一直以来都以高吞吐量的特性而家喻户晓，就在上周，在一个性能监控项目中，需要使用到 Kafka 传输海量消息，在这过程中遇到了一个 Kafka Producer 异步发送消息会被阻塞的问题，导致生产端发送耗时很大。
是的，你没听错，Kafka Producer 异步发送消息也会发生阻塞现象，那究竟是怎么回事呢？
在新版的 Kafka Producer 中，设计了一个消息缓冲池，客户端发送的消息都会被存储到缓冲池中，同时 Producer 启动后还会开启一个 Sender 线程，不断地从缓冲池获取消]]></description><category></category></item><item><title><![CDATA[图解 DataX 核心设计原理]]></title><link>https://blog.csdn.net/zchdjb/article/details/108458042</link><guid>https://blog.csdn.net/zchdjb/article/details/108458042</guid><author>zchdjb</author><pubDate>Mon, 07 Sep 2020 22:43:03 +0800</pubDate><description><![CDATA[DataX 是阿里巴巴开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库（MySQL、Oracle 等）、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。
前段时间我在 K8s 相关文章中有提到过数据同步的项目，该项目就是基于 DataX 内核构建的，由于公司数据同步的需求，还需要在 DataX 原有的基础上支持增量同步功能，同时支持分布式调度，在「使用 K8s 进行作业调度实战分享」这篇文章中已经详细描述其中的实现。
基于我在项目中对 DataX 的]]></description><category></category></item><item><title><![CDATA[探讨缓存行与伪共享]]></title><link>https://blog.csdn.net/zchdjb/article/details/108300940</link><guid>https://blog.csdn.net/zchdjb/article/details/108300940</guid><author>zchdjb</author><pubDate>Sat, 29 Aug 2020 23:09:58 +0800</pubDate><description><![CDATA[最近项目中有个需求，需要用到有界队列对访问请求量进行流量削峰请求，同时作为一个缓冲层对请求处理进行后续处理，Java 内置有界队列 ArrayBlockingQueue 可以满足这方面的需求，但是性能上并不满足，于是使用了 Disruptor，它是英国外汇交易公司 LMAX 开发的一个高性能队列，了解到它内部解决伪共享问题，今天就和大家一起学习缓存行与伪共享相关的知识。
缓存行（Cache line）
对计算机组成原理相对熟悉的小伙伴都知道，CPU 的速度比内存的速度高了几个数量级，为了 CPU 更快从内存]]></description><category></category></item><item><title><![CDATA[使用 K8s 进行作业调度实战分享]]></title><link>https://blog.csdn.net/zchdjb/article/details/108270592</link><guid>https://blog.csdn.net/zchdjb/article/details/108270592</guid><author>zchdjb</author><pubDate>Thu, 27 Aug 2020 23:18:55 +0800</pubDate><description><![CDATA[最近在公司的数据同步项目（以下简称 ZDTP）中，需要使用到分布式调度数据同步执行单元，目前使用的方案是将数据同步执行单元打包成镜像，使用 K8s 进行调度。
在 ZDTP 中，数据同步的动作可抽象成一个执行单元（以下称为 worker），类似于线程执行单元 Runnable ，Runnable 放入一个队列中等待线程的调度执行，执行完 Runnable 即完成了它的使命。当用户在 ZDTP 控制台中创建同步任务并启动任务时，会根据同步任务的配置，产生若干个用于该任务的 worker，假设这些 worker]]></description><category></category></item><item><title><![CDATA[图解 K8s 核心概念和术语]]></title><link>https://blog.csdn.net/zchdjb/article/details/108192915</link><guid>https://blog.csdn.net/zchdjb/article/details/108192915</guid><author>zchdjb</author><pubDate>Mon, 24 Aug 2020 09:16:43 +0800</pubDate><description><![CDATA[我第一次接触容器编排调度工具是 Docker 自家的 Docker Swarm，主要解决当时公司内部业务项目部署繁琐的问题，我记得当时项目实现容器化之后，花在项目部署运维的时间大大减少了，当时觉得这玩意还挺新鲜的，原来自动化运维可以这么玩。后面由于工作原因，很久没碰过容器方面的知识了。最近在公司的数据同步项目中，需要使用到分布式调度数据同步执行单元，目前使用的方案是将数据同步执行单元打包成镜像，使用 K8s 进行调度，正好趁这个机会了解一下 K8s，下面我就用图解的形式将我所理解的 K8s 分享给大家。
K]]></description><category></category></item><item><title><![CDATA[Seata RPC 模块的重构之路]]></title><link>https://blog.csdn.net/zchdjb/article/details/107689849</link><guid>https://blog.csdn.net/zchdjb/article/details/107689849</guid><author>zchdjb</author><pubDate>Thu, 30 Jul 2020 14:41:31 +0800</pubDate><description><![CDATA[RPC 模块是我最初研究 Seata 源码开始的地方，因此我对 Seata 的 RPC 模块有过一些深刻研究，在我研究了一番后，发现 RPC 模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着 “让天下没有难懂的 RPC 通信代码” 的初衷，我开始了 RPC 模块的重构之路。
这里建议想要深入了解 Seata 交互细节的，不妨从 RPC 模块的源码入手，RPC 模块相当于 Seata 的中枢，Seata 所有的交互逻辑在 RPC 模块中表现得淋漓尽致。
这次 RPC 模块的重构将会使得 ]]></description><category></category></item><item><title><![CDATA[Spring 异步实现原理与实战分享]]></title><link>https://blog.csdn.net/zchdjb/article/details/106824391</link><guid>https://blog.csdn.net/zchdjb/article/details/106824391</guid><author>zchdjb</author><pubDate>Thu, 18 Jun 2020 10:07:50 +0800</pubDate><description><![CDATA[最近因为全链路压测项目需要对用户自定义线程池 Bean 进行适配工作，我们知道全链路压测的核心思想是对流量压测进行标记，因此我们需要给压测的流量请求进行打标，并在链路中进行传递，那么问题来了，如果项目中使用了多线程处理业务，就会造成父子线程间无法传递压测打标数据，不过可以利用阿里开源的 ttl 解决这个问题。
全链路压测项目的宗旨就是不让用户感知这个项目的存在，因此我们不可能让用户去对其线程池进行改造的，我们需要主动去适配用户自定义的线程池。
在适配过程的过程中无非就是将线程池替换成 ttl 去解决，可通过]]></description><category></category></item><item><title><![CDATA[彻底搞懂 Kafka 消息大小相关参数设置的规则]]></title><link>https://blog.csdn.net/zchdjb/article/details/106255180</link><guid>https://blog.csdn.net/zchdjb/article/details/106255180</guid><author>zchdjb</author><pubDate>Thu, 21 May 2020 13:33:13 +0800</pubDate><description><![CDATA[前段时间接到用户要求，调整某个主题在 Kafka 集群消息大小为 4M。
根据 Kafka 消息大小规则设定，生产端自行将 max.request.size 调整为 4M 大小，Kafka 集群为该主题设置主题级别参数 max.message.bytes 的大小为 4M。
以上是针对 Kafka 2.2.x 版本的设置，需要注意的是，在某些旧版本当中，还需要调整相关关联参数，比如 replica.fetch.max.bytes 等。
从上面例子可看出，Kafka 消息大小的设置还是挺复杂的一件事，而且还分版]]></description><category></category></item><item><title><![CDATA[我参与 Seata 开源项目的一些感悟]]></title><link>https://blog.csdn.net/zchdjb/article/details/106199897</link><guid>https://blog.csdn.net/zchdjb/article/details/106199897</guid><author>zchdjb</author><pubDate>Mon, 18 May 2020 19:46:29 +0800</pubDate><description><![CDATA[丁老师在他的知识星球邀请我回答以下一个问题：

我觉得这个问题非常有意思，姑且把它贴到公众号这里，与大家分享一下我对这个问题的一些感悟。
感谢丁老师的邀请问答：
在这里我就简单说下，我这段时间参与 Seata 开源项目的一些感悟：
1、如何参与到开源项目中并贡献自己的一份力量？
我一直都有上 GitHub 搜索一些主流开源项目的习惯，我是从去年 5 月份从 GitHub 开始关注 Seata 项目的，经过入门上手之后，我就觉得它的设计理念非常棒，尽管当时还有很多地方没有完善，但并不阻碍我对它的赞美，我对它产]]></description><category></category></item><item><title><![CDATA[深度剖析 Kafka/RocketMQ 顺序消息的一些坑]]></title><link>https://blog.csdn.net/zchdjb/article/details/106101244</link><guid>https://blog.csdn.net/zchdjb/article/details/106101244</guid><author>zchdjb</author><pubDate>Wed, 13 May 2020 16:35:12 +0800</pubDate><description><![CDATA[我不记得有多少人问过以下这个问题了：

我觉得这个问题问得很频繁，而且非常经典，在这里我就以 Kafka 为例子，说说我对 Kafka 顺序消息的一些理解吧，如有理解不对的地方麻烦留言指点一下。
通常我们在说顺序消费指的是生产者按照顺序发送，消费者按照顺序进行消费，听起来简单，但做起来却非常困难。
我们都知道无论是 Kafka 还是 RocketMQ，每个主题下面都有若干分区（RocketMQ 叫队列），如果消息被分配到不同的分区中，那么 Kafka 是不能保证消息的消费顺序的，因为每个分区都分配到一个消费]]></description><category></category></item><item><title><![CDATA[当 Kafka 分区不可用且 leader 副本被损坏时，如何尽量减少数据的丢失？]]></title><link>https://blog.csdn.net/zchdjb/article/details/105185358</link><guid>https://blog.csdn.net/zchdjb/article/details/105185358</guid><author>zchdjb</author><pubDate>Sun, 29 Mar 2020 20:26:55 +0800</pubDate><description><![CDATA[经过上次 Kafka 日志集群某节点重启失败导致某个主题分区不可用的事故之后，这篇文章专门对分区不可用进行故障重现，并给出我的一些骚操作来尽量减少数据的丢失。
故障重现
下面我用一个例子重现现分区不可用且 leader 副本被损坏的例子：

使用 unclean.leader.election.enable = false 参数启动 broker0；
使用 unclean.leader.elect...]]></description><category></category></item><item><title><![CDATA[从源码和日志文件结构中分析 Kafka 重启失败事件]]></title><link>https://blog.csdn.net/zchdjb/article/details/105028991</link><guid>https://blog.csdn.net/zchdjb/article/details/105028991</guid><author>zchdjb</author><pubDate>Sun, 22 Mar 2020 15:39:23 +0800</pubDate><description><![CDATA[上次的 Kafka 重启失败事件，对为什么重启失败的原因似乎并没有解释清楚，那么我就在这里按照我对 Kafka 的认识，从源码和日志文件结构去尝试寻找原因。
从源码中定位到问题的根源
首先把导致 Kafka 进程退出的异常栈贴出来：

注：以下源码基于 kafka 0.11.0.2 版本。
我们直接从 index 文件损坏警告日志的位置开始：
kafka.log.Log#loadSegmentFi...]]></description><category></category></item><item><title><![CDATA[记一次 Kafka 重启失败问题排查]]></title><link>https://blog.csdn.net/zchdjb/article/details/104898521</link><guid>https://blog.csdn.net/zchdjb/article/details/104898521</guid><author>zchdjb</author><pubDate>Mon, 16 Mar 2020 14:22:20 +0800</pubDate><description><![CDATA[背景
在 2 月10 号下午大概 1 点半左右，收到用户方反馈，发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader，导致某些消息发送到该分区时，会报如下 no leader 的错误信息：
In the middle of a leadership election, there is currently no leader for this partition and he...]]></description><category></category></item><item><title><![CDATA[一次 kafka 消息堆积问题排查]]></title><link>https://blog.csdn.net/zchdjb/article/details/103868612</link><guid>https://blog.csdn.net/zchdjb/article/details/103868612</guid><author>zchdjb</author><pubDate>Tue, 07 Jan 2020 09:40:05 +0800</pubDate><description><![CDATA[收到某业务组的小伙伴发来的反馈，具体问题如下：
项目中某 kafka 消息组消费特别慢，有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。
从服务端日志看到如下信息：

该消费组在短时间内重平衡了 600 多次。
从 cat 查看得知，每条消息处理都会有 4 次数据库的交互，经过一番沟通之后，发现每条消息的处理耗时大概率保持在 200ms 以上。
Kafka 发生重平衡的有...]]></description><category></category></item><item><title><![CDATA[图解 Kafka 水印备份机制]]></title><link>https://blog.csdn.net/zchdjb/article/details/103728879</link><guid>https://blog.csdn.net/zchdjb/article/details/103728879</guid><author>zchdjb</author><pubDate>Fri, 27 Dec 2019 11:11:56 +0800</pubDate><description><![CDATA[高可用是很多分布式系统中必备的特征之一，Kafka 日志的高可用是通过基于 leader-follower 的多副本同步实现的，每个分区下有多个副本，其中只有一个是 leader 副本，提供发送和消费消息，其余都是 follower 副本，不断地发送 fetch 请求给 leader 副本以同步消息，如果 leader 在整个集群运行过程中不发生故障，follower 副本不会起到任何作用，问题就...]]></description><category></category></item><item><title><![CDATA[Seata 动态配置订阅与降级实现原理]]></title><link>https://blog.csdn.net/zchdjb/article/details/103657544</link><guid>https://blog.csdn.net/zchdjb/article/details/103657544</guid><author>zchdjb</author><pubDate>Sun, 22 Dec 2019 21:50:29 +0800</pubDate><description><![CDATA[Seata 的动态降级需要结合配置中心的动态配置订阅功能。动态配置订阅，即通过配置中心监听订阅，根据需要读取已更新的缓存值，ZK、Apollo、Nacos 等第三方配置中心都有现成的监听器可实现动态刷新配置；动态降级，即通过动态更新指定配置参数值，使得 Seata 能够在运行过程中动态控制全局事务失效（目前只有 AT 模式有这个功能）。
那么 Seata 支持的多个配置中心是如何适配不同的动态配置...]]></description><category></category></item><item><title><![CDATA[记一次 Kafka 集群线上扩容]]></title><link>https://blog.csdn.net/zchdjb/article/details/103622459</link><guid>https://blog.csdn.net/zchdjb/article/details/103622459</guid><author>zchdjb</author><pubDate>Thu, 19 Dec 2019 20:41:44 +0800</pubDate><description><![CDATA[前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高，于是花了一段时间去排查这个问题，最后该集群进行扩容，由于某些主题的当前数据量实在太大，在对这些主题迁移过程中话费了很长一段时间，不过这个过程还算顺利，因为在迁移过程中也做足了各方面的调研，包括分区重平衡过程中对客户端的影响，以及对整个集群的性能影响等，特此将这个过程总结一下，也为双十一打了一剂强心剂。




排查问题与分析
接到...]]></description><category></category></item><item><title><![CDATA[关于 Kafka 的一些面试题目]]></title><link>https://blog.csdn.net/zchdjb/article/details/103587195</link><guid>https://blog.csdn.net/zchdjb/article/details/103587195</guid><author>zchdjb</author><pubDate>Tue, 17 Dec 2019 20:33:33 +0800</pubDate><description><![CDATA[上周客串了一下面试官，在这里就简单记录一下期间我问到的一些关于 Kafka 的面试题目，这些都是我平时在学习 Kafka 的一些总结要点。





谈谈你对 kafka 的整体认识？



问这个问题主要是想知道面试者对 Kafka 的整体认识如何，能够大致了解清楚面试者对 Kafka 的相关概念的熟悉程度，比如消息、topic、partition、replica、offset、重平衡、lead...]]></description><category></category></item></channel></rss>