构成：
1.producer:
producer直接发消息到broker，broker会返回一些topic的元数据信息，比如：这些元信息包括哪些机器是存活的，topic的leader partition都在哪，现阶段哪些leader partition是可以直接被访问的
2.consumers
1).high-level-api:维持了已消费消息的状态，每次消费的都是下一个消息；还支持以组的形式来消费topic；
2).simple-api:底层api，维持了一个和单一broker的连接，并且这个API是完全无状态的，每次请求需要指定offset值，可以通过设置offset值来重复读取
消费过的数据
3.broker:
1).partitions:
topic是以partition的形式存放的，可配置
2).replications:
备份机制，实现多个备份，防止单个broker挂了后，数据不会丢失
3).leaders:
partition的副本中只有一个会被选举为leader，用来进行读写
核心特性：
1.压缩：
kafka支持以集合为单位发送消息，在此基础上，kafka还支持对消息集合进行压缩，producer端可以通过GZIP或SNAPPY格式进行压缩，然后在
consumer端进行解压，在大数据处理上，性能瓶颈往往体现在网络上而不是CPU.
如何区别消息是否被压缩，kafka在消息头部添加了一个描述压缩属性的字节，这个字节的后两位表示消息压缩采用的编码，如果后两位是0，说明
没有被压缩
2.消息可靠性：
为了防止消息丢失、多次发送等情况，kafka采用如下处理：
1).producer端：producer会等待borker成功接收消息的反馈（可通过参数设置来控制等待时间），如果消息丢失或者broker挂了，producer会重新
发送（通过参数控制是否等待所有备份节点都收到消息）
2).consumer端：consumer收到消息，但是在处理过程中挂了，此时consumer会通过offset值重新找到上一个消息在进行处理.当然，consumer还
有权限控制这个offset值.
3.备份机制:
0.8版本新特性，一个备份数量为n的集群允许n-1个节点失败.在所有备份节点中，有一个节点作为lead节点，这个节点保存了其它备份节点列表，并维持各个备份间的状体同步
4.高效性相关设计：
4.1).消息的持久化
磁盘性能事实：磁盘驱动器的吞吐量跟寻到延迟是相背离的，也就是所，线性写的速度远远大于随机写，举例：在一个6 7200rpm SATA
RAID-5 的磁盘阵列上线性写的速度大概是600M/秒，但是随机写的速度只有100K/秒，两者相差将近6000倍
顺序I/O是为了提高读写硬盘的速度
4.2).常数时间性能保证
一个持久化的队列可以构建在对一个文件的读和追加上，kafka数据持久化就是两个文件，一个保存数据（.log文件），一个保存offset相关信
息（.index文件）
4.3).更多的效率考虑
1).为了减少大量小IO操作，kafka都是以消息块的形式来追加消息到log中的
2).为了减小过多的字节拷贝，kafka设计了标准字节消息，producer、consumer、broker共享这一中消息格式
Memory Mapped Files：内存映射文件->直接利用操作系统的Page来实现文件到物理内存的映射，省去了用户空间到内核空间的赋值开销
（调用文件的read会把数据先放到内核空间的内存中，然后再复制到用户空间的内存中）
注：Java NIO提供了MappedByteBuffer来实现内存映射
性能瓶颈：
1.网络传输
2.磁盘吞吐量
