消息队列 Kafka 系统架构
一个典型的消息队列 Kafka 集群包含：
Producer：通过 push 模式向消息队列 Kafka Broker 发送消息，可以是网站的页面访问、服务器日志等，也可以是 CPU 和内存相关的系统资源信息；
Kafka Broker：消息队列 Kafka 的服务器，用于存储消息；支持水平扩展，一般 Broker 节点数量越多，集群吞吐率越高；
Consumer Group：通过 pull 模式从消息队列 Kafka Broker 订阅并消费消息;
Zookeeper：管理集群的配置、选举 leader，以及在 Consumer Group 发生变化时进行负载均衡。
产品优势：
1、吞吐量
高吞吐是kafka需要实现的核心目标之一，为此kafka做了以下一些设计：
数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能
zero-copy：减少IO操作步骤
数据批量发送
数据压缩
Topic划分为多个partition，提高parallelism
2、负载均衡
producer根据用户指定的算法，将消息发送到指定的partition
存在多个partiiton，每个partition有自己的replica，每个replica分布在不同的Broker节点上
多个partition需要选取出lead partition，lead partition负责读写，并由zookeeper负责fail over
通过zookeeper管理broker与consumer的动态加入与离开
3.可扩展性
当需要增加broker结点时，新增的broker会向zookeeper注册，而producer及consumer会根据注册在zookeeper上的watcher感知这些变化，并及时作出调整。
kafka:设计注意点：
1、直接使用linux 文件系统的cache，来高效缓存数据。
2、采用linux Zero-Copy提高发送性能。传统的数据发送需要发送4次上下文切换，采用sendfile系统调用之后，数据直接在内核态交换，系统上下文切换减少为2次。根据测试结果，可以提高60%的数据发送性能。Zero-Copy详细的技术细节可以参考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/
3、数据在磁盘上存取代价为O(1)。kafka以topic来进行消息管理，每个topic包含多个partition，每个partitiont对应一个逻辑log，有多个segment组成。每个segment中存储多条消息，消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。发布者发到某个topic的消息会被均匀的分布到多个part上（随机或根据用户指定的回调函数进行分布），broker收到发布消息往对应part的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。
应用场景：
网站活动跟踪
成功的网站运营都会非常关注站点的用户行为并进行分析。通过消息队列 Kafka，您可以实时收集网站活动数据（包括用户浏览页面、搜索及其他行为等），并通过“发布/订阅”模型实现：
根据不同的业务数据类型，将消息发布到不同的 Topic；
通过订阅消息的实时投递，将消息流用于实时监控与业务分析或者加载到 Hadoop、ODPS 等离线数据仓库系统进行离线处理与业务报告。
能够实现：
高吞吐：网站所有用户产生的行为信息极为庞大，需要非常高的吞吐量来支持；
弹性扩容：网站活动导致行为数据激增，云平台可以快速按需扩容；
大数据分析：可对接 Storm/Spark 实时流计算引擎，亦可对接 Hadoop/ODPS 等离线数据仓库系统。
日志聚合
许多公司，比如淘宝、天猫平台每天都会产生大量的日志（一般为流式数据，如搜索引擎 pv、查询等），相较于日志为中心的系统，比如 Scribe 或者 Flume 来说，Kafka 在提供同样高效的性能时，可以实现更强的数据持久化以及更低的端到端响应时间。Kafka 的这种特性决定它非常适合作为日志收集中心：
Kafka 忽略掉文件的细节，可以将多台主机或应用的日志数据抽象成一个个日志或事件的消息流，异步发送到 Kafka 集群，从而做到非常低的 RT 时间；
Kafka 客户端可批量提交消息和压缩消息，对生产者而言几乎感觉不到性能的开支；
消费者可以使用 Hadoop、ODPS 等离线仓库存储和 Strom、Spark 等实时在线分析系统对日志进行统计分析。
能够实现：
应用与分析解耦：构建应用系统和分析系统的桥梁，并将它们之间的关联解耦；
高可扩展性：具有非常高的可扩展性，即当数据量增加时可通过增加节点快速水平扩展；
在线/离线分析系统：支持实时在线分析系统和类似于 Hadoop 的离线分析系统。
流计算处理
在很多领域，如股市走向分析、气象数据测控、网站用户行为分析，由于数据产生快、实时性强且量大，您很难统一采集这些数据并将其入库存储后再做处理，这便导致传统的数据处理架构不能满足需求。
与传统架构不同，Kafka 以及 Storm/Samza/Spark 等流计算引擎的出现，就是为了更好地解决这类数据在处理过程中遇到的问题，流计算模型能实现在数据流动的过程中对数据进行实时地捕捉和处理，并根据业务需求进行计算分析，最终把结果保存或者分发给需要的组件。
能够实现：
流动的数据：构建应用系统和分析系统的桥梁，并将它们之间的关联解耦；
高可扩展性：由于数据产生非常快且数据量大，需要非常高的可扩展性；
流计算引擎：可对接开源 Storm/Samza/Spark 以及 EMR、Blink、StreamCompute 等阿里云产品。
数据中转枢纽
近 10 多年来，诸如 KV 存储（HBase）、搜索（ElasticSearch）、流式处理（Storm/Spark Streaming/Samza）、时序数据库（OpenTSDB）等专用系统应运而生。这些系统是因为单一的目标而产生，也因其简单性使得在商业硬件上构建分布式系统变得更加容易且性价比更高。
通常，同一份数据集需要被注入到多个专用系统内。例如，当应用日志用于离线日志分析，搜索单个日志记录同样不可或缺，而构建各自独立的工作流来采集每种类型的数据再导入到各自的专用系统显然不切实际，利用 Kafka 作为数据中转枢纽，同份数据可以被导入到不同专用系统中。
能够实现：
高容量存储：能在商业硬件上存储高容量的数据，实现可横向扩展的分布式系统；
一对多消费模型：“发布/订阅”模型，支持同份数据集能同时被消费多次；
同时支持实时和批处理：支持本地数据持久化和 Page Cache，在无性能损耗的情况下能同时传送消息到实时和批处理的消费者。