共计 4058 个字符，预计需要花费 11 分钟才能阅读完成。
Kafka 是以后十分风行的一个音讯零碎，最后用作 LinkedIn 的流动流式数据和经营数据处理管道的根底。流动流式数据次要包含 页面访问量 PV、拜访内容 以及 检索内容 等。经营数据指的是服务器的性能数据（CPU、IO 使用率、申请工夫、服务日志等等数据）。这些数据通常的解决形式是先把各种流动以日志的模式写入某种文件，而后周期性地对这些文件进行统计分析。
近年来，随着互联网的疾速倒退，流动和经营数据处理曾经成为网站软件产品个性中一个至关重要的组成部分，须要一套宏大的基础设施对其提供反对。
什么是 Kafka？
Kafka 是一个分布式、反对分区的、多正本的，基于 Zookeeper 协调的分布式音讯零碎，现已募捐给 Apache 基金会。它最大的个性就是能够实时处理大量数据并且反对动静程度扩大，这样的个性能够满足各种需要场景：比方基于 Hadoop 的批处理零碎、低提早的实时零碎、Storm/Spark 流式解决引擎，日志解决零碎，音讯服务等等。
Kafka 零碎架构
Kafka 架构如上图所示，实质就是生产 - 存储 - 生产，次要蕴含以下四个局部：
- Producer Cluster：生产者集群，负责公布音讯到 Kafka broker，个别由多个利用组成。
- Kafka Cluster：Kafka 服务器集群。这里就是 Kafka 最重要的一部分，这里负责接管生产者写入的数据，并将其长久化到文件存储里，最终将音讯提供给 Consumer Cluster。
- Zookeeper Cluster：Zookeeper 集群。Zookeeper 负责保护整个 Kafka 集群的 Topic 信息、Kafka Controller 等信息。
- _Consumer Cluster_：消费者集群，负责从 Kafka broker 读取音讯，个别也由多个利用组成，获取本人想要的信息。
Kafka 相干概念解释
- Broker Kafka 集群蕴含一个或多个服务器，这种服务器被称为 broker；
- Topic 每条公布到 Kafka 集群的音讯都有一个类别，这个类别被称为 Topic。（物理上不同 Topic 的音讯离开存储，逻辑上一个 Topic 的音讯尽管保留于一个或多个 broker 上但用户只需指定音讯的 Topic 即可生产或生产数据而不用关怀数据存于何处）；
- Partition 是物理上的概念，每个 Topic 蕴含一个或多个 Partition；
- Producer 负责公布音讯到 Kafka broker；
- Consumer 音讯消费者，向 Kafka broker 读取音讯的客户端；
- Consumer Group 每个 Consumer 属于一个特定的 Consumer Group（可为每个 Consumer 指定 group name，若不指定 group name 则属于默认的 group）。
在 Kafka 架构设计里，无论是生产者、还是消费者、还是音讯存储，都能够动静程度扩大，从而进步整个集群的吞吐量、可扩展性、持久性和容错性，Kafka 生来就是一个分布式系统，这赋予了它以下个性：
- 高吞吐量、低提早：Kafka 能够以较低的资源耗费解决每秒上百 MB 的音讯吞吐量，而它的提早最低只有几毫秒。
- 可扩展性：Kafka 集群反对动静程度扩大。
- 持久性、可靠性 ： 音讯被长久化到本地磁盘，并且反对数据备份避免数据失落。
- 容错性 ： 容许集群中节点失败（若正本数量为 n, 则容许 n - 1 个节点失败）。
- 高并发 ： 反对数千个客户端同时读写。
Kafka 次要应用场景
目前越来越多的开源分布式解决零碎如 Cloudera、Apache Storm、Spark、Flink 等都反对与 Kafka 集成，Kafka 可被广泛应用于以下场景中：
音讯零碎：异步解耦生产者和消费者，削峰填谷稳定的流量峰值。
_日志聚合：_能够用 Kafka 收集各种服务的操作日志，通过 Kafka 以对立接口服务的形式凋谢给各种消费者，能够应用 Hadoop 等其余系统化的存储和剖析系统对聚合的日志进行统计分析。
用户流动跟踪： Kafka 常常被用来记录 web 用户或者 app 用户的各种流动，如浏览网页、搜寻、点击等流动，这些流动信息被各个服务器公布到 Kafka 中，而后订阅者通过订阅这些 topic 来做实时的监控剖析，做离线剖析和开掘。
经营指标：Kafka 也常常用来记录经营监控数据。包含收集各种分布式应用的数据，生产各种操作的集中反馈，比方报警和监控。
流式解决：Kafka 能够很好地反对离线数据、流式数据的解决，并可能不便地进行数据聚合、剖析等操作。比方 Spark streaming 和 Storm。
京东智联云 K afka服务技术架构
京东智联云音讯队列 Kafka 版不仅托管了开源的 Apache Kafka，做到了用户原有业务代码无需革新，即可无缝迁徙上云，并且还加强了对于 Kafka 集群的创立、治理、运维和监控，用户通过京东智联云音讯队列 Kafka 版部署，能够取得以下劣势：
多版本创立
反对 Kafka V0.10、V1.0、V2.4 多版本创立，并且反对预付费和后付费两种模式。三个大版本的反对方便使用 kafka 的用户无缝迁徙上云，后付费的模式反对用户进行测试试用，不用产生机器老本的费用，免去屡次部署的麻烦。
弹性扩容
轻松扩大，方便快捷。用户可依据资源应用状况按需扩容，不影响现有业务的同时以满足业务增长需要。防止了用户自行搭建 Kafka 进行扩容的简单操作和业务危险。
治理组件
用户创立的每个 Kafka 集群都配置了 Kafka Manager，不便用户进行界面化、可视化的集群治理，免去了 API 调用或者命令行工具的简单操作。
运维监控
集群级别免运维，装备健康检查，不衰弱的状态主动 failover，无需用户运维，即可保障服务可用性。并且对集群状态进行监控，反对多维度的监控预警。免去了服务不可用然而应用方无感知的担心。
Kafka 部署指南
上面咱们看一下通过京东智联云音讯队列 Kafka，是如何构建高牢靠高吞吐 Kafak 服务的？
1
进步京东智联云 Kafka 的吞吐量
Kafka 中主题 topic 作为次要承受音讯的载体，个别会分成一个或多个分区 partition，每个 partiton 相当于是一个子 queue，多个 partition 就相当于多个子 queue 在同时工作进行写盘和交互解决，因而减少 partition 能够减少单个主题 topic 的吞吐量。
在物理构造上，每个 partition 对应一个物理的文件，Kafka 中会把音讯长久化到本地文件系统中，并且放弃 o(1) 极高的效率。磁盘的 IO 读写是十分耗资源的性能，所以进步磁盘的 iops 和吞吐量，能够进步音讯写入磁盘的速度，相应的进步吞吐。
Kafka 中的主题都是由 生产组 consumer group 来生产的。如果这个 consumer group 外面 consumer 的数量小于 topic 外面 partition 的数量，就会有 consumer thread 同时解决多个 partition。如果这个 consumer group 外面 consumer 的数量大于 topic 外面 partition 的数量，多出的 consumer thread 就会闲置，剩下的是一个 consumer thread 解决一个 partition，这就造成了资源的节约，因为一个 partition 不可能被两个 consumer thread 去解决。
倡议：
1）减少分区数 partition 能够无效进步音讯的吞吐量，并且分区数最好是集群解决节点 broker 的整数倍，这样每个正本调配到的分区数比拟平均；
2）采纳高 iops 和高吞吐的磁盘规格和 SSD 类型的磁盘；
3）减少生产者 producer 和消费者 consumer 的数量，并且消费者的数量最好能够和分区数相等。
2
进步京东智联云 Kafka 的可靠性
Kafka 主题 topic 的正本数即备份 replica 的个数。如果正本数为 1 , 即便 Kafka 节点机器有多个，当该正本所在的机器宕机后，对应的数据也会拜访失败。但正本数不是越多越好，正本数不能多于 Kafka 中解决节点 broker 的数量，更多的正本数在进行数据同步的时候会影响服务的性能。
当主题有了多正本之后，发送音讯时候正本数据同步策略也影响着数据的高可靠性，次要由 ack 这个参数来管制。
- 当 ack=1，示意 producer 写 leader 胜利后，broker 就返回胜利，无论其余的 follower 是否写胜利；
- 当 ack=2，示意 producer 写 leader 和其余一个 follower 胜利的时候，broker 就返回胜利，无论其余的 partition follower 是否写胜利；
- 当 ack=-1，示意只有 producer 全副写胜利的时候，才算胜利，kafka broker 才返回胜利信息。
可见当 ack=-1 时候，数据的可靠性必定是最好的，然而这会影响到服务的可用，因为必须所有的 follower 都写入胜利才算胜利，一个 follow 呈现问题就会导致服务不可用。
倡议：
1）当创立 Kafka 主题时，如果对数据可靠性有要求倡议设置主题 topic 的正本数不少于三正本；
2）设置发送音讯 ack 参数的时候，倡议设置半数以上的正本胜利就算发送胜利即可，这样能够兼顾音讯的可靠性也不会升高服务的可用性；
3）发送音讯的时候抉择同步或者异步的形式，关怀音讯的发送后果并且对于发送失败的音讯进行解决。
京东智联云音讯队列 Kafka 在部署的时候还能够做到节点反亲和，使得真正 topic 的多副本能做到跨可用区，做到集群和 topic 都能放弃跨可用区的可用性。
通过以上内容，你应该曾经晓得如何通过应用京东智联云音讯队列 Kafka，构建一个高牢靠高吞吐的 Kafka 音讯服务了，如果想更近一步体验该产品，请点击 【浏览原文】 链接体验试用。
参考资料：
*《Confluent 官网》
https://www.confluent.io/blog…
*《Kafka 设计解析（一）：Kafka 背景及架构介绍》
https://www.infoq.cn/article/…
*《Kafka（三）Kafka 的高可用与生产生产过程解析》
https://www.cnblogs.com/frank…
