Kafka的一些问题
前言
读自vivo 互联网技术的文章–《Kafka 原理和实战》 整理
问题点
单分区有序
只保证单个主题单个分区内的消息有序，但是不能保证单个主题所有分区消息有序。如果应用严格要求消息有序，那么kafka可能不大合适
消费偏移量维护
消费偏移量由消费者跟踪和提交，但是消费者并不会经常把这个偏移量写会kafka，因为broker维护这些更新的代价很大，这会导致异常情况下消息可能会被多次消费或者没有消费。
具体分析如下：消息可能已经被消费了，但是消费者还没有像broker提交偏移量(commit offset)确认该消息已经被消费就挂掉了，接着另一个消费者又开始处理同一个分区，那么它会从上一个已提交偏移量开始，导致有些消息被重复消费。但是反过来，如果消费者在批处理消息之前就先提交偏移量，但是在处理消息的时候挂掉了，那么这部分消息就相当于『丢失』了。通常来说，处理消息和提交偏移量很难构成一个原子性操作，因此无法总是保证所有消息都刚好只被处理一次。
主题和分区的数目有限
Kafka集群能够处理的主题数目是有限的，达到1000个主题左右时，性能就开始下降。这些问题基本上都跟Kafka的基本实现决策有关。特别是，随着主题数目增加，broker上的随机IO量急剧增加，因为每个主题分区的写操作实际上都是一个单独的文件追加(append)操作。随着分区数目增加，问题越来越严重。如果Kafka不接管IO调度，问题就很难解决。
磁盘大小
单个节点必须有足够的磁盘空间来处理副本，因此非常大的副本可能会迫使你是用非常大的磁盘，磁盘的冗余需要评估和衡量
手动均衡分区负载
在集群扩展时必须做Rebalance。这个过程是比较痛苦的，需要良好的计划和执行来保证没有任何故障的情况下分散节点的存储压力
follow副本(replica)只充当冷备（解决HA问题），无法提供读服务
kafka因为读服务是有状态的（要维护commited offset），所以follow副本并没有参与到读写服务中。只是作为一个冷备，解决单点问题。
顺序消费
只能顺序消费消息，不能随机定位消息，出问题的时候不方便快速定位问题
这其实是所有以消息系统作为异步RPC的通用问题。假设发送方发了一条消息，但是消费者说我没有收到，那么怎么排查呢？消息队列缺少随机访问消息的机制，如根据消息的key获取消息。
这导致排查这种问题不大容易。
参考链接