标签：多后 进阶 分区 写入 kafka 寻址 数过 IO 磁盘
大家好，这是一个为了梦想而保持学习的博客。这个专题会记录我对于 KAFKA 的学习和实战经验，希望对大家有所帮助，目录形式依旧为问答的方式，相当于是模拟面试。
一、概述
在对 kafka 有了基础的认知之后，回过头来看看，当前 kafka 的 存储架构 还存在哪些问题呢？
很多地方有提到 kafka 无法承载大量的分区这个问题，但是都只给了个结论，没有说明其中缘由，这里我们就来梳理一下。
二、磁盘顺序写特性被破坏，导致写入吞吐量下降
我们从前面的【十一】小节知道，kafka 有如此高的写入吞吐量，主要是得益于追加写的性能极高，但是如果这个特性被破坏，那么写入吞吐量就会有明显的下降，那么什么时候会破坏这个特性呢？我们先从基本的磁盘 IO 说起。
机械硬盘的 IO 过程可以简单的理解为两个阶段：寻址 + 数据写入 其中寻址是个物理动作，就是需要通过旋转加上磁臂去找到对应的扇区，这个过程的耗时是毫秒级的，相对于其他计算机类的操作，高出了好几个数量级。 而数据写入呢，就是将我们的数据写入物理载体中，相对来说也是很快的。
从这个大概的过程中，我们知道，机械硬盘的 IO 过程慢就慢在寻址这个操作上，那我们有没有什么办法能优化掉这个过程呢？其中一个优化点就是追加写。
试想你一直只对一个文件进行写入，那么磁臂就根本就不需要再寻址了呀，接着往下写就好啦，所以就省去了寻址的这个开销，让写磁盘的性能能接近写内存。
也正是由于追加写的这个特性，在 Linux 的 IO 调度层面，有 4 种不同的调度策略，都尝试将随机的 IO 请求尽可能的合并成顺序写或者临近读，从而优化 IO 性能，在这里我简单的提一下，大家有兴趣可以进行查阅相关资料：
- NOOP：大致上就是所有进程共用一个先进先出队列，做了简单的相邻请求合并。
- CFQ（默认）：特点是按照 I/O 请求的地址进行排序，而不是按照先进先出的顺序响应的，并且会为每个进程都创建一个这样特点的队列。但是存在 “饿死” 的场景，也就是我一个很小的读请求要读取很后面的地址，但是因为排序之后，被前面的很大的 I/O 请求给卡住了，导致无法被执行。
- DEADLINE：针对 CFQ 算法进行了优化，为每个请求设置了超时时间，如果达到了这么个时间一定要被调度执行，读等待时间为 500ms，写等待时间为 5s。
- ANTICIPATORY：为每个 I/O 都设置 6ms 的等待时间窗口，如果 6ms 内收到了相邻的 I/O 请求，那么就进行合并，通过增加时间的方式来获取更高的性能，尽可能的将随机读写转换为顺序读写。
进入正题，为什么 kafka 的分区数多了知道会破坏追加写的特性呢？
分区底层对应的是底层一个个 segment 文件，如果一个 broker 上，有上万个分区，那么对应的就需要去写上万个 segment，那么从磁盘的角度来说就是我刚写完 A 文件，又要重新寻址去写 B 文件，以此类推，当文件一多，就相当于是随机 IO 了，追加写的特性就由此被破坏，写入吞吐量就受到了非常大的影响。另外提一句，RocketMQ 就是基于这个原因将所有分区数据都写到一个 commitLog 中来规避这个问题。
最后再提一句，我们在说随机 I/O 和追加写的时候，是站在磁盘的角度去说的，跟上层持不持有 file 的引用或者用什么流去写入没有什么关系，这也是我之前认知的一个误区。
另外就是，这个问题只会存在于机械硬盘，云盘和 SSD 都不会存在，因为云盘走的是带宽，而 SSD 是元器件也不需要物理旋转寻址。
三、集群故障转移受影响，导致故障转移耗时增加
另外一个影响点就是我们日常运维会遇到的问题，故障转移和集群状态恢复时间受到影响。
其中的影响点主要是由于 kafka 故障转移时主要依靠 controller+zk 去实现的，而整个过程的是单线程顺序去执行的，整个过程大概分为：计算新的 leader + 更新 zk 数据 + 通知其他节点将 follower 变为 leader + 更新元数据。而在这个过着执行完之前，对应受影响的分区都是没有 leader 可以去提供读写服务的，所以对业务的影响是很大的。
试想我们集群有几十万的分区数，那么这个过程将非常耗时，达到分钟级别甚至小时级别。但是 kafka 在 1.1.0 版本优化了这个问题，主要优化点三个：zk 批量异步写 / 批量计算通知 / 日志优化。
具体参见胡夕大佬的翻译文章：【译】Apache Kafka 支持单集群 20 万分区
四、元数据太过庞大，导致更新元数据操作变重
这个问题就是显而易见的了，当分区数很多的时候，整个集群的元数据将会变得庞大，一旦集群状态变化，整个集群都会更新元数据，但是由于元数据太过庞大会让这个更新操作变得非常沉重。
五、日志清理受影响
kafka 的日志文件操作，是 broker 有个后台清理线程去定时检查执行的，一旦一台 broker 上的文件过多，会导致线程处理不过来，无法及时清理掉对应的磁盘文件，从而导致磁盘被打满等异常情况。
标签：多后,进阶,分区,写入,kafka,寻址,数过,IO,磁盘 来源： https://www.cnblogs.com/keepal/p/16341760.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。