用Apache Kafka构建流数据平台的建议

1. 限制集群数量
2. 简化数据流：将各个系统间的互联改为以流数据平台为中心
3. 指定一种数据格式：遵循同一种数据规范可以避免数据生产者和消费者不必要的数据适配工作
4. 共享事件模式：为常见事件流指定通用模式
5. 具体数据类型建模：纯数据流，应用程序日志，系统指标，hadoop数据加载等待。。。
6. 流处理：数据系统之间以流的方式传递数据，将各部分系统解耦，同时起到缓冲区作用。

Kafka设计目标

1. 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能
2. 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
3. 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输
4. 同时支持离线数据处理和实时数据处理。
5. Scale out：支持在线水平扩展。

为什么使用消息系统

1. 解耦
   在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2. 冗余
   有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3. 扩展性
   因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
4. 灵活性 & 峰值处理能力
   在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5. 可恢复性
   系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6. 顺序保证
   在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
7. 缓冲
   在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
8. 异步通信
   很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

Kafka组件

1. Broker：kafka一个节点
2. Topic：每个消息都属于一个topic，可以看作一个queue
3. Partition：每个topic包含一个或多个partition
4. producer：push消息到Broker
5. consumer ：从Broker pull消息
6. consumer group：每个consumer属于一个consumer group，不同consumer group可对消息重复消费

Kafka关键设计

broker上的持久化存储

每个具体broker上以topic-partition为单独目录存储；新增消息以append模式追加写；在每个partition存储目录中，包含多个segment files，每个segment file存储实际消息内容，为一个log entrie序列，log entrie {message length:4 bytes (value:1+4+n), magic value, crc, payload:n bytes}，同时还包含一个segment索引文件，记录每个segment file的offset起止范围

数据过期删除策略

kafka并不以消息没消费后便删除，而是通过配删除策略来保证。一个是设置保存时间，一个是设置partition大小。

消费者订阅进度控制

kafka为每一个consumer group保存一些metadata，如订阅进度offset，这个offset由consumer控制（增减），因此每个broker是无状态的，不需要保证同一个consumer group中只有一个consumer能消费一条消息，不需要增加锁机制。

producer消息路由

Producer发送消息到broker时，会根据Paritition机制（比如取模：key % nPartitions）选择将其存储到哪一个Partition。

kafka delivery guarantee

At most once & At least once & Exactly once
Kafka默认保证At least once，并且允许通过设置Producer异步提交来实现At most once。

Replica leader

引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replication之间选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据。

replica分布策略

1）将所有Broker（假设共n个Broker）和待分配的Partition排序
2）将第i个Partition分配到第（i mod n）个Broker上
3）将第i个Partition的第j个Replica分配到第（(i + j) mode n）个Broker上

Propagate消息

Producer在发布消息到某个Partition时，先通过ZooKeeper找到该Partition的Leader，Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leader pull数据。这种方式上，Follower存储的数据顺序与Leader保持一致。Follower在收到该消息后（并不等到持久化到硬盘完成），向Leader发送ACK。一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW并且向Producer发送ACK。

复制机制

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，完全同步复制要求所有能工作的Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率（高吞吐率是Kafka非常重要的一个特性）。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下如果Follower都复制完都落后于Leader，而如果Leader突然宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，这样极大的提高复制性能（批量写磁盘），极大减少了Follower与Leader的差距。

leader election

Kafka在ZooKeeper中动态维护了一个ISR（in-sync replicas），这个ISR里的所有Replica都跟上了leader，只有ISR里的成员才有被选为Leader的可能。在这种模式下，对于f+1个Replica，一个Partition能在保证不丢失已经commit的消息的前提下容忍f个Replica的失败。在大多数使用场景中，这种模式是非常有利的。事实上，为了容忍f个Replica的失败，Majority Vote和ISR在commit前需要等待的Replica数量是一样的，但是ISR需要的总的Replica的个数几乎是Majority Vote的一半。

相关项目

camus: 将kafka数据上传到hadoop
kafka-manager

参考链接

Kafka剖析（一）：Kafka背景及架构介绍
Kafka设计解析（二）：Kafka High Availability
Kafka深度解析
Kafka在LinkedIn公司的应用场景、现状与未来
Yahoo开源Kafka集群管理器Kafka Manager
Apache Kafka 下一代分布式消息系统
用Apache Kafka构建流数据平台的建议