消息队列使用场景
队列，在数据结构中是一种先进先出的结构，消息队列可以看成是一个盛放消息的容器，这些消息等待着各种业务来处理。
消息队列是「分布式系统」中重要的组件，kafka就可以看做是一种消息队列，其大致使用场景：
- 解耦
- 异步通信
- 削峰填谷
来看一个用户注册业务，在传统的单体项目中，假如注册流程是：
如果用户注册相关处理耗费30ms，发送短信又耗时30ms，那么一个完整的注册业务就耗时60ms，这60ms期间，服务器资源是被这一个注册业务独占的。
如果发送短信的业务出现了故障，那么整个注册业务就不成功：
再来看分布式系统中的注册业务，注册和发短信拆分为两个业务，用户填写完注册信息，将“用户注册”的消息发送到消息队列，然后直接响应给客户端：
这样即使发送短信业务出现了故障，用户的注册业务是完成了的，只不过客户端收到成功通知的时间晚了一会而已。
这就是消息队列用到的解耦和异步通信的场景。
还有一种比较典型的场景就是分布式系统中各个业务产生的各种日志：
这里消息队列起到了一个缓冲的作用，辅助数据库，减少流计算给数据库造成的压力。
Kafka作为消息队列的一种，它也有这么多的使用场景。
关联阅读：RocketMQ入坑系列
kafka架构模型
核心构成部分
先来看一下Kafka核心的东西：
- Broker
- Topic
- Partition
- Record
- offset
- Replication
Broker
一个kafka节点就是一个「broker」。
Kafka集群中的每一个节点都称之为「broker」，每个「broker」都有一个不同的brokerId，由配置参数broker.id指定，是一个不小于0的整数。
每个「broker」的broker.id必须不同，需要扩展kafka集群的时候只需引入新节点，分配一个不同的broker.id即可。
「broker」参与kafka集群选举leader。
「启动kafka集群时，每一个broker都会实例化并启动一个kafkaController，并将该broker的brokerId注册到zooKeeper的相应节点中。」
集群各broker会根据选举机制选出其中一个broker作为leader，即leader kafkaController。
leader kafkaController负责「topic的创建与删除、partition分区和副本的管理等」。当leader kafkaController宕机后，其他broker会再次选举出新的leader kafkaController。
Topic & Partition
一个topic可以认为是一类消息，每个topic将被分成多个partition，每个partition在存储层面是append log文件。
Record
Kafka的Record就是一条消息，其消息格式可以理解为有key、value和timestamp时间戳组成。
当客户端写入一条record时，kafka根据消息的key进行hash运算，然后在将它和分区个数进行取模运算，用以决定这条消息写到哪个分区（partition）中。
这样的话，既保证了相同的key的消息发送到相同的分区，而且消息写入到哪个分区也是足够随机的。
offset
每个partition都由一系列「有序的」、「不可变的」消息组成，这些消息被连续的追加到partition中。
「partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息。」
Kafka集群架构
在kafka中，每个主题可以有多个分区，每个分区又可以有多个副本。
这多个副本中，只有一个是leader，而其他的都是follower副本。仅有leader副本可以对外提供服务。
多个follower副本通常存放在和leader副本不同的broker中。
通过这样的机制实现了高可用，当某台机器挂掉后，其他follower副本也能迅速”转正“，开始对外提供服务。
kafka高性能之道
顺序写mmap
因为硬盘是机械结构，每次读写都会「寻址」，「写入」，其中寻址是一个“机械动作”，它是最耗时的。
所以随机I/O会让硬盘重复机械动作比较耗时，顺序I/O的寻址速度就比较快了。
为了提高读写硬盘的速度，Kafka就是使用「顺序I/O」。每条消息都被append到该Partition中，属于「顺序写磁盘」，因此效率非常高。
即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以「Kafka的数据并不是实时的写入硬盘，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。」
零拷贝
Kafka服务器在响应客户端读取数据的时候，底层使用的是「ZeroCopy」技术，也就是数据只在内核空间传输，数据不会到达用户空间。
常规的I/O操作一般是这样的：
- 文件在磁盘中的数据被拷贝到内核缓冲区
- 从内核缓冲区拷贝到用户缓冲区
- 用户缓冲区拷贝到内核与Socket相关的缓冲区
- 数据从Socket缓冲区拷贝到相关协议引擎发送出去
这样的操作与用户空间有关，效率不高，Kafka底层使用的零拷贝是这样的：
- 文件在磁盘中的数据被拷贝到内核缓冲区
- 从内核缓冲区拷贝到与Socket相关的缓冲区
- 数据从Socket缓冲区拷贝到相关协议引擎发送出去
整个处理过程没有用到用户空间，效率提升了，这种就是零拷贝。
