kafka 高吞吐、高并发架构

kafka的PageCache读写

不同于Redis和MemcacheQ等内存消息队列，Kafka的设计是把所有的Message都要写入速度低容量大的硬盘，以此来换取更强的存储能力。实际上，Kafka使用硬盘并没有带来过多的性能损失（这一点是有条件限制的，这个条件是，消费者的消费速度要高于或等于生产者的速度）。

kafka重度依赖底层操作系统提供的PageCache功能。（文件缓存，速度相当于操作内存）当上层有写操作时，操作系统只是将数据写入PageCache，同时标记Page属性为Dirty。当读操作发生时，先从PageCache中查找，如果发生缺页才进行磁盘调度，最终返回需要的数据。写入PageCache的数据被定期批量保存到文件系统，减少了磁盘的操作次数，减少系统开销。

实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。同时如果有其他进程申请内存，回收PageCache的代价又很小，所以现代的OS都支持PageCache。使用PageCache功能同时可以避免JVM设计带来的GC开销大的问题。

总结：

1、kafka一开始是把数据写到PageCache，也就是缓存，如果消费者一直在消费，而且速度大于等于kafka的生产者发送数据的速度，那么消费者会一直从PageCache读取数据，速度等同于内存的操作，不会因为kafka写入磁盘的操作影响吞吐量。

2、当kafka的消费者消费速度不及生产者生产速度时，PageCache存的数据已经是最新的数据了，kafka消费端需要的数据已经被存储磁盘中，这时，kafka的消费速度会受到磁盘的读取速度影响。

问题：

kafka的数据一开始就是存储在PageCache上的，定期flush到磁盘上的，也就是说，不是每个消息都被存储在磁盘了，如果出现断电或者机器故障等，PageCache上的数据就丢失了。

kafka数据完整性保障：

kafka是多副本的，当你配置了同步复制之后。多个副本的数据都在PageCache里面，出现多个副本同时挂掉的概率比1个副本挂掉的概率就很小了。（官方推荐是通过副本来保证数据的完整性的）

同时kafka也提供了相关的配置参数，来让你在性能与可靠性之间权衡（一般默认）：

# 当达到下面的消息数量时，会将数据 flush 到日志文件中。默认 10000

log.flush.interval.messages=10000

# 当达到下面的时间 (ms) 时，执行一次强制的 flush 操作。 interval.ms 和 interval.messages 无论哪个达到，都会 flush 。默认 3000ms

log.flush.interval.ms=1000

# 检查是否需要将日志 flush 的时间间隔

log.flush.scheduler.interval.ms = 3000