————————————————————————————————————————————————
【关键原理】
1.消息文件存储（消息堆积能力）
2.消息topic分区
3.消息顺序的保证
4.拉模型（消费者水平扩展）
————————————————————————————————————————————————
【关键概念】
Producer ：消息生产者，就是向kafka broker发消息的客户端。
Consumer ：消息消费者，向kafka broker取消息的客户端
Topic ：咋们可以理解为一个队列。
Consumer Group （CG）：这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个CG只会把消息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka
————————————————————————————————————————————————
处理大量数据。Kafka主要的设计约束是吞吐量而不是功能。（活跃的流式数据实时处理）
分布式应用间的通信。
基于拉的消费模型让消费者以自己的速度处理消息
如果处理消息时出现了异常，消费者始终可以选择再消费该消息。
【kafka设计目标】
高吞吐量是其核心设计之一。
数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能。
zero-copy：减少IO操作步骤。
支持数据批量发送和拉取。
支持数据压缩。
Topic划分为多个partition，提高并行处理能力。
【特征】
严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力。
【kafka特性】
通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
高吞吐量：即使是非常普通的硬件kafka也可以支持每秒数十万的消息。
支持同步和异步复制两种HA
Consumer客户端pull，随机读,利用sendfile系统调用，zero-copy ,批量拉数据
消费状态保存在客户端
消息存储顺序写
数据迁移、扩容对用户透明
支持Hadoop并行数据加载。
支持online和offline的场景。
持久化：通过将数据持久化到硬盘以及replication防止数据丢失。
scale out：无需停机即可扩展机器。
定期删除机制，支持设定partitions的segment file保留时间。
【应用场景】
日志异步记录：高吞吐量+低一致性要求。
顺序同步：MySQL binlog复制。
消息广播。（消息推送）
分布式消息路由。
【消息分发的可靠性】
kafka(MQ)要实现从producer到consumer之间的可靠的消息传送和分发。
传统的MQ系统通常都是通过broker和consumer间的确认（ack）机制实现的，并在broker保存消息分发的状态。即使这样一致性也是很难保证的。
kafka的做法是由consumer自己保存状态，也不要任何确认。这样虽然consumer负担更重，但其实更灵活了。
因为不管consumer上任何原因导致需要重新处理消息，都可以再次从broker获得。
————————————————————————————————————————————————