kafka高性能原理

    Topic：            用于划分Message的逻辑概念，一个Topic可以分布在多个Broker上
    Partition：        是Kafka中横向扩展和一切并行化的基础，每个Topic都至少被切分为1个Partition
    Offset：        消息在Partition中的编号，编号顺序不跨Partition
    Consumer：        用于从Broker中取出/消费Message
    Producer：        用于往Broker中发送/生产Message
    Replication：    Kafka支持以Partition为单位对Message进行冗余备份，每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身)
    Leader：        每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理，其他Replicas从Leader处把数据更新同步到本地，过程类似大家熟悉的MySQL中的Binlog同步
    Broker：        Kafka中使用Broker来接受Producer和Consumer的请求，并把Message持久化到本地磁盘，每个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工作
    ISR(In-Sync Replica)：    是Replicas的一个子集，表示目前Alive且与Leader能够“Catch-up”的Replicas集合。由于读写都是首先落到Leader上，所以一般来说通过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度)，任意一个超过阈值都会把该Replica踢出ISR。每个Partition都有它自己独立的ISR
    性能分析：
        不同于Redis和MemcacheQ等内存消息队列，Kafka的设计是把所有的Message都写入速度低容量大的硬盘，以此来换取更强的存储能力，但Kafka使用硬盘并没有带来过多的性能损失
        Kafka在磁盘上只做Sequence I/O的限制，规避了磁盘访问速度低下对性能可能造成的影响
        Kafka重度依赖底层操作系统提供的PageCache功能，当上层有写操作时，操作系统只是将数据写入PageCache，同时标记Page属性为Dirty，当读操作发生时，先从PageCache中查找，如果发生缺页才进行磁盘调度，最终返回需要的数据，实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用，同时如果有其他进程申请内存，回收PageCache的代价又很小
        Kafka为了进一步的优化性能还采用了Sendfile技术，让数据直接在内核区完成数据拷贝，减少同一份数据在内核Buffer与用户Buffer之间重复拷贝

备注（摘自：https://blog.csdn.net/qq_27232757/article/details/78951993）：

Sendfile技术：在解释Sendfile之前，首先介绍一下传统的网络I/O操作流程，大体上分为以下4步。
1. OS从硬盘把数据读到内核区的PageCache。
2. 用户进程把数据从内核区Copy到用户区。
3. 然后用户进程再把数据写入到Socket，数据流入内核区的Socket Buffer上。
4. OS再把数据从Buffer中Copy到网卡的Buffer上，这样完成一次发送。

整个过程共经历两次Context Switch，四次System Call。同一份数据在内核Buffer与用户Buffer之间重复拷贝，效率低下。其中2、3两步没有必要，完全可以直接在内核区完成数据拷贝。这也正是Sendfile所解决的问题，经过Sendfile优化后，整个I/O过程就变成了下面这个样子。

通过以上的介绍不难看出，Kafka的设计初衷是尽一切努力在内存中完成数据交换，无论是对外作为一整个消息系统，或是内部同底层操作系统的交互。如果Producer和Consumer之间生产和消费进度上配合得当，完全可以实现数据交换零I/O。这也就是我为什么说Kafka使用“硬盘”并没有带来过多性能损失的原因。