————————————————————————————————————————————————服务器
【关键原理】数据结构
1.消息文件存储（消息堆积能力）异步
2.消息topic分区分布式
3.消息顺序的保证oop
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得到。
————————————————————————————————————————————————