过去工作经历接触了比较多消息中间件，也产出了不少关于这方面的技术文章，今天我就来给大家梳理一下本公众号过去关于 RocketMQ 的文章，做一个汇总。
一直坚守，从未放弃。
支付宝亿级资金业务平台（转账、代发、红包）社招 Java，base 上海/杭州，P6～P8，大量 HC，直线内推，流程很快。
简历请投递至：zhangchenghui.zch@antgroup.com
ZCache 是中通下一代缓存服务平台，实现多种缓存类型自动部署，提供 Proxy 访问层，通过 Proxy 层提供指令限制、访问权限、限流、分片处理等功能，通过自研 K8s Operator 实现自动部署与故障转移，实现集群的高可用，提供完善统计、监控、运维功能、减少运维成本和误操作，提高机器的利用率，提供灵活的伸缩性，方便用户接入缓存服务。
随着业务上的增长与迭代，业务使用的消息集群会创建越来越多主题，在业务流量不断增长的情况下，还需要不断增加主题的分区数量，Kafka 由于本身的存储机制特点，随着主题和分区数的增加，性能会不断下降，无法满足业务上的发展。通常我们的做法是扩容集群，但随着集群的不断扩大，又会伴随着很多问题，随着集群的扩容节点，创建主题和分区数不断增多，存储在 zk 上的元数据就会越来越多，每当需要全量同步元数据到 Broker 节点时，会是一笔很大的网络开销，由于当 contrller 切换时往往需要全量同步元数据到每个 Broker 上，因此，元数据越多，controller 的切换时长会越长，而且由于 Kafka 会独立一个复制线程进行分区副本的复制，多个分区共享该线程，因此 Broker上的分区不断增多后会造成复制线程负载增大，严重时会会造成某些分区副本复制跟不上，导致 ISR 频繁变化。
某天晚上打球打得正嗨，突然间收到运维电话，说某个 Kafka 集群 RT 值非常高，使用该集群的用户也发现了消息堆积现象，此刻我意识到问题的严重性，于是急忙跑回办公室查看这个问题。
在过去的一年多，由于工作的原因我接触 Kafka 比较多，在工作的过程中，总结了很多关于 Kafka 的知识并将它们沉淀为一篇篇文章，包括 Kafka 核心知识点的讲解，工作中遇到的问题排查分析与性能调优相关，仔细看了下应该有 30 篇了，因此我将这一年多写的 Kafka 文章汇总起来，对 Kafka 进行一次知识梳理。
某天临时被当成壮丁拉去参加一个非常牛逼的应用监控平台（后续会开源），然后大佬就给我派了一个任务，要将项目中的查询性能优化 50 倍以上，大佬对我如此地寄予厚望，我怎么能让大佬失望呢（虽然我内心瑟瑟发抖）？于是我就开始了这段性能优化之旅。
消息引擎最重要的工作就是将生产者生产的消息传输到消费者，消息的格式应该要怎么设计是各大消息引擎框架最核心的问题，消息格式决定了消息引擎的性能与效率，Kafka 在过去的多个版本迭代中，衍生了 3 个版本的消息格式，每个版本的消息格式之间究竟有哪些差异，它们之间的升级解决了什么样的问题呢？下面我就对 Kafka 的消息格式进行深度剖析。
消息中间件的性能好坏，它的消息存储的机制是衡量该性能的最重要指标之一，而 Kafka 具有高性能、高吞吐、低延时的特点，动不动可以上到几十上百万 TPS，离不开它优秀的消息存储设计。下面我按照自己的理解为大家讲解 Kafka 消息存储设计的那些事。