LinkedIn是如何优化Kafka的
原文： http://www.infoq.com/cn/articles/linkedIn-improving-kafka
在LinkedIn的数据基础设施中，Kafka是核心支柱之一。来自LinkedIn的工程师曾经就Kafka写过一系列的专题文章，包括它的 现状和未来 、 如何规模化运行 、 如何适应LinkedIn的开源策略 以及 如何适应整体的技术栈 等。近日，来自LinkedIn的高级工程主管 Kartik Paramasivam 撰文分享了他们 使用和优化Kafka的经验 。
LinkedIn在2011年7月开始大规模使用Kafka，当时Kafka每天大约处理10亿条消息，这一数据在2012年达到了每天200亿 条，而到了2013年7月，每天处理的消息达到了2000亿条。在几个月前，他们的最新记录是每天利用Kafka处理的消息超过1万亿条，在峰值时每秒钟 会发布超过450万条消息，每周处理的信息是1.34 PB。每条消息平均会被4个应用处理。在过去的四年中，实现了1200倍的增长。
随着规模的不断扩大，LinkedIn更加关注于Kafka的可靠性、成本、安全性、可用性以及其他的基础指标。在这个过程中，LinkedIn的技术团队在多个特性和领域都进行了有意义的探索。
LinkedIn在Kafka上的主要关注领域包括：
配额（Quotas）
在LinkedIn，不同的应用使用同一个Kafka集群，所以如果某个应用滥用Kafka的话，将会对共享集群的其他应用带来性能和SLA上的 负面影响。有些合理的使用场景有可能也会带来很坏的影响，比如如果要重新处理整个数据库的所有数据的话，那数据库中的所有记录会迅速推送到Kafka上， 即便Kafka性能很高，也会很容易地造成网络饱和和磁盘冲击。
Kartik Paramasivam绘图展现了不同的应用是如何共享Kafka Broker的：
为了解决这个问题，LinkedIn的团队研发了一项特性，如果每秒钟的字节数超过了一个阈值，就会降低这些Producer和Customer 的速度。对于大多数的应用来讲，这个默认的阈值都是可行的。但是有些用户会要求更高的带宽，于是他们引入了白名单机制，白名单中的用户能够使用更高数量的 带宽。这种配置的变化不会对Kafka Broker的稳定性产生影响。这项特性运行良好，在下一版本的Kafka发布版中，所有的人就都能使用该特性了。
开发新的Customer
目前的Kafka Customer客户端依赖于 ZooKeeper ，这种依赖会产生一些大家所熟知的问题，包括ZooKeeper的使用缺乏安全性以及Customer实例之间可能会出现的 脑裂现象（split brain） 。因此，LinkedIn与 Confluent 以及其他的开源社区合作开发了一个新的Customer。这个新的Customer只依赖于Kafka Broker，不再依赖于ZooKeeper。这是一项很复杂的特性，因此需要很长的时间才能完全应用于生产环境中。
在Kafka中，目前有两个不同类型的Customer。如果Customer希望完全控制使用哪个分区上的Topic的话，就要使用低级别的 Customer。在高级别的Customer中，Kafka客户端会自动计算如何在Customer实例之间分配Topic分区。这里的问题在于，如果 使用低级别Customer的话，会有许多的基本任务要去完成，比如错误处理、重试等等，并且无法使用高级别Customer中的一些特性。在 LinkedIn这个新的Customer中，对低级别和高级别的Customer进行了调和。
可靠性和可用性的提升
按照LinkedIn这样的规模，如果Kafka的新版本中有什么重要缺陷的话，就会对可靠性产生很大的影响。因此，LinkedIn技术团队一项很重要的任务就是发现和修正缺陷。他们在可靠性方面所做的增强包括：
Mirror Maker 无损的数据传输 ：Mirror Maker是Kafka的一个组件，用来实现Kafka集群和Kafka Topic之间的数据转移。LinkedIn广泛使用了这项技术，但是它在设计的时候存在一个缺陷，在传输时可能会丢失数据，尤其是在集群升级或机器重启 的时候。为了保证所有的消息都能正常传输，他们修改了设计，能够确保只有消息成功到达目标Topic时，才会认为已经完全消费掉了。
副本的延迟监控 ：所有发布到Kafka上的消息都会复制副本，以提高持久性。当副本无法“跟上”主版本（master）的话，就认为这个副本处于非健康的状态。在这里， “跟上”的标准指的是配置好的字节数延迟。这里的问题在于，如果发送内容很大的消息或消息数量不断增长的话，那么延迟可能会增加，那么系统就会认为副本是 非健康的。为了解决这个问题，LinkedIn将副本延迟的规则修改为基于时间进行判断。
实现新的Producer ：LinkedIn为Kafka实现了新的Producer，这个新的Producer允许将消息实现为管道（pipeline），以提升性能。目前该功能尚有部分缺陷，正在处于修复之中。
删除Topic ：作为如此成熟的产品，Kafka在删除Topic的时候，会出现难以预料的后果或集群不稳定性，这一点颇令人惊讶。在几个月前，LinkedIn对其进行了广泛地测试并修改了很多缺陷。到Kafka的下一个主版本时，就能安全地删除Topic了。
安全性
在Kafka中，这是参与者最多的特性之一，众多的公司互相协作来解决这一问题。其成果就是加密、认证和权限等功能将会添加到Kafka中，在LinkedIn，预期在2015年能使用加密功能，在2016年能使用其他的安全特性。
Kafka监控框架
LinkedIn最近正在致力于以一种标准的方式监控Kafka集群，他们的想法是运行一组测试应用，这些应用会发布和消费Kafka Topic数据，从而验证基本的功能（顺序、保证送达和数据完整性等）以及端到端发布和消费消息的延时。除此之外，这个框架还可以验证Kafka新版本是 否可以用于生产环境，能够确保新版本的Kafka Broker不会破坏已有的客户端。
故障测试
当拿到新的Kafka开源版本后，LinkedIn会运行一些故障测试，从而验证发生失败时Kafka新版本的质量。针对这项任务，LinkedIn研发了名为 Simoorg 的故障引导框架，它会产生一些低级别的机器故障，如磁盘写失败、关机、杀进程等等。
应用延迟监控
LinkedIn开发了名为 Burrow 的工具，能够监控Customer消费消息的延迟，从而监控应用的健康状况。
保持Kafka集群平衡
LinkedIn在如下几个维度保证了集群的平衡：
感知机柜： 在进行平衡时，很重要的一点是Kafka分区的主版本与副本不要放到同一个数据中心机柜上。如果不这样做的话，一旦出现机柜故障，将会导致所有的分区不可用。
确保Topic 的分区公平地分发到Broker 上： 在为Kafka发布和消费消息确定了配额后，这项功能变得尤为重要。相对于将Topic的分区发布到同一个Broker节点上，如果Topic的分区能够均衡地分发到多个Broker上，那么相当的它有了更多的带宽。
确保集群节点的磁盘和网络容量不会被耗尽： 如果几个Topic的大量分区集中到了集群上的少数几个节点上，那么很容易出现磁盘或网络容量耗尽的情况。
在LinkedIn，目前维护站点可靠性的工程师（Site Reliability Enginee，SRE）通过定期转移分区确保集群的平衡。在分区放置和重平衡方面，他们已经做了一些原始设计和原型实现，希望能够让系统更加智能。
在其他的数据系统中，将Kafka作为核心的组成部分
在LinkedIn，使用 Espresso 作为NoSQL数据库，目前他们正在将Kafka作为Espresso的备份机制。这将Kafka放到了站点延迟敏感数据路径的关键部分，同时还需要保证更高的消息传送可靠性。目前，他们做了很多的性能优化，保证消息传输的低延迟，并且不会影响消息传递的可靠性。
Kafka还会用于异步上传数据到 Venice 之中。除此之外，Kafka是 Apache Samza 实时 流处理 的一个重要事件源，同时Samza还使用Kafka作为持久化存储，保存应用的状态。在这个过程中，LinkedIn修改了一些重要的缺陷，并增强了Kafka的日志压缩特性。
LinkedIn的Kafka生态系统
除了Apache Kafka Broker、客户端以及Mirror Maker组件之外，LinkedIn还有一些内部服务，实现通用的消息功能：
支持非Java 客户端： 在LinkedIn，会有一些非Java应用会用到Kafka的REST接口，去年他们重新设计了Kafka的REST服务，因为原始的设计中并不能保证消息的送达。
消息的模式： 在LinkedIn，有一个成熟的“模式（schema）注册服务”，当应用发送消息到Kafka中的时候，LinkedIn Kafka客户端会根据消息注册一个模式（如果还没有注册过的话）。这个模式将会自动在Customer端用于消息的反序列化。
成本计算： 为了统计各个应用对Kafka的使用成本，LinkedIn使用了一个Kafka审计Topic。LinkedIn客户端会自动将使用情况发送到这个Topic上，供Kafka审计服务读取并记录使用情况，便于后续的分析。
审计系统： LinkedIn的离线报告job会反映每小时和每天的事件情况，而事件从源Kafka Topic/集群/数据中心，到最后的HDFS存储是需要时间的。因此，Hadoop job需要有一种机制，保证某个时间窗口能够获得所有的事件。LinkedIn Kafka客户端会生成它们所发布和消费的消息数量。审计服务会记录这个信息，Hadoop以及其他的服务可以通过REST接口获取这一信息。
支持内容较大的消息： 在LinkedIn，将消息的大小限定为1MB，但是有些场景下，无法满足这一限制。如果消息的发布方和使用方是同一个应用的话，一般会将消息拆分为片段 来处理。对于其他的应用，建议消息不要超过1MB。如果实在无法满足该规则的话，消息的发送和消费方就需要使用一些通用的API来分割和组装消息片段，而 在LinkedIn的客户端SDK中，他们实现了一种特性，能够自动将一条大的信息进行分割和重组。
目前， 越来越多的国内外公司在使用Kafka ，如Yahoo!、推ter、Netflix和Uber等，所涉及的功能从数据分析到流处理不一而足，希望LinkedIn的经验也能够给其他公司一些借鉴。