Kafka

Kafka

开源版本kafka本地盘主写主读模式

存算分离
阿里云商业化版本需要支持

1. 平滑扩缩容
   a. 缩容场景，为了保证缩容后的partition副本数仍满足配置，开源版本会涉及到大量数据复制并导致节点抖动。
   b. 阿里云现有模式是支持了元数据层的重映射从而避免分区复制。缩容节点相当于对客户端不可见，新数据会写到新的leader节点上，访问partition的旧数据时，新leader判断没有数据会转到缩容节点上获取。等缩容节点上的数据都过期后才真正缩容
2. 解决数据倾斜
   a. 分区数据不均会导致部分broker磁盘占用高，客户希望只升配问题节点降低升配影响，这种场景属于非标扩容，会增加集群管理难度

阿里云存算分离版本kafka

1. 盘古存储系统提供数据可靠性，follower节点都为虚拟节点，不会真正去同步数据。
   kafka高吞吐相关的机制
   消息聚批
   producer配置，借鉴了TCP的Nagle算法思想，尽可能将消息攒一批执行批量发送
   ● batch.size 聚批大小（字节）
   ● linger.ms 聚批最大等待时间（毫秒）
   传输存储格式统一
   kafka 0.11版本之后引入了v2格式Record Batch，消息收发和日志文件保存都会用相同的数据，这样broker就可以只针对producer发送的原始数据做简单的校验就可以落盘，避免不必要的数据组织
   与之区别的是，Rocketmq的机制是broker会重新组织落盘的数据，成为影响吞吐的一个原因
   页缓存和零拷贝
   通常情况下，broker会配置收到的数据写入pagecache后即认为成功，不使用同步刷盘的原因：
2. kafka天生的多副本机制，本身对消息可靠性已经有了保障
3. 面向pagecache相当于对内存操作，性能非常高
4. 操作系统的I/O调度策略可以支持按照地址排序，借由pagecache异步刷盘能够更好的发挥顺序写的性能

kafka本身定位作为流式处理平台，消息大概率会立即被消费，基于kafka的主写主读架构，通常我们会考虑把最新的消息缓存起来方便消费时返回。但在java中自己管理缓存会因为堆内存过大影响GC时间，而kafka设计了传输存储格式统一之后，pagecache（文件）中的数据可以直接返回给consumer，故相当于kafka利用了操作系统的pagecache做自己的读缓存

实际上在kafka的消息都被及时消费的场景中，1中从磁盘读文件的操作也是不需要的，因为数据刚被写入pagecache，不会触发缺页中断需要从磁盘加载