本人重度依赖 GitHub，面向 GitHub 编程，GitHub 可以让我每天早上打开电脑，假装了解最新开源项目。
最近你们有没有发现，GitHub 明显变慢了，如果没有 fanqiang，拉取代码的速度简直惨不忍睹，如果拉取的量少还可以勉强拉下来，但是遇到数据量大的时候，2 KiB/s 的速度你能忍？拉到中途超时就让你痛不欲生。
最近我就遇到这个问题，seata 社区的 seata.github.io 仓库有阵子突然增加了好多数据，我发现我已经拉不下来了，这时可以利用 Gitee 作为中间代理，下面详细说说具体操作过程。
收到某业务组的小伙伴发来的反馈，具体问题如下：
项目中某 kafka 消息组消费特别慢，有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。
Seata 的动态降级需要结合配置中心的动态配置订阅功能。动态配置订阅，即通过配置中心监听订阅，根据需要读取已更新的缓存值，ZK、Apollo、Nacos 等第三方配置中心都有现成的监听器可实现动态刷新配置；动态降级，即通过动态更新指定配置参数值，使得 Seata 能够在运行过程中动态控制全局事务失效（目前只有 AT 模式有这个功能）。
那么 Seata 支持的多个配置中心是如何适配不同的动态配置订阅以及如何实现降级的呢？下面从源码的层面详细给大家讲解一番。
Seata 可以支持多个第三方配置中心，那么 Seata 是如何同时兼容那么多个配置中心的呢？下面我给大家详细介绍下 Seata 配置中心的实现原理。
在分析启动部分源码时，我发现 GlobalTransactionScanner 会同时启动 RM 和 TM client，但根据 Seata 的设计来看，TM 负责全局事务的操作，如果一个服务中不需要开启全局事务，此时是不需要启动 TM client的，也就是说项目中如果没有全局事务注解，此时是不是就不需要初始化 TM client 了，因为不是每个微服务，都需要 GlobalTransactional，它此时仅仅作为一个 RM client 而已。
从上一篇文章「分布式事务中间件Seata的设计原理」讲了下 Seata AT 模式的一些设计原理，从中也知道了 AT 模式的三个角色（RM、TM、TC），接下来我会更新 Seata 源码分析系列文章。今天就来分析 Seata AT 模式在启动的时候都做了哪些操作。
上周客串了一下面试官，在这里就简单记录一下期间我问到的一些关于 Kafka 的面试题目，这些都是我平时在学习 Kafka 的一些总结要点。
有没有小伙伴要找工作的？
现在中通科技-技术平台部-消息组还有少量坑位，招聘高级 Java 开发工程师，坐标上海，薪资范围：25k - 45k，13 薪，提供单身宿舍，这在互联网寒冬时期机会实在难得啊，感兴趣的朋友可以在公众号后台加我好友发简历给我，或者直接把简历发到我邮箱：zhangchenghui.dev@gmail.com，我帮忙内推，成功入职后跟我同组（消息组），可以和我一起玩转亿级消息集群。
之前有个 Kafka 集群的每个节点的挂载磁盘多达 20+ 个，平均每个磁盘约1T，每个节点的分区日志被平均分配到这些磁盘中，但由于每个分区的数据不一致，而集群节点 log.retention.bytes 这个参数的默认值是 -1，也就是没有任何限制，因此 Kafka 的日志删除日志依赖 log.retention.hours 参数来删除，因此会出现日志未过期，磁盘写满的情况。
针对该集群双十一会遇到某些挂载磁盘被写满的情况，需要手动对主题进行删除以清空磁盘的操作，现在分析删除主题对集群以及客户端会有什么影响，以及 Kafka 都做了哪些动作。
ISR（in-sync replica） 就是 Kafka 为某个分区维护的一组同步集合，即每个分区都有自己的一个 ISR 集合，处于 ISR 集合中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 集合中的副本才有资格被选举为 leader。一条 Kafka 消息，只有被 ISR 中的副本都接收到，才被视为“已同步”状态。这跟 zk 的同步机制不一样，zk 只需要超过半数节点写入，就可被视为已写入成功。