kafka权威指南第二章第7节生产环境关注的内容

本帖最后由 levycui 于 2017-6-6 15:06 编辑
问题导读：
1、kafka如何优化垃圾回收选项？
2、生产环境中如何考虑kafka集群容灾？
3、如何搭配使用kafka和zookeeper？

一旦你准备好将kafka的环境从测试中移到生产环境中操作，就需要考虑的一些事情以便帮助我们建立可靠的消息列队服务。

垃圾回收的选项
对于应用程序调优Java垃圾回收选项一直都是一种艺术，需要详细了解应用程序如何使用内存以及大量的实践观察、试验以及报错查看。

值得庆幸的是，可以使用Java 7和Garbage First (称为G1)垃圾回收器进行调整。 G1被设计为自动适应不同的工作负载，在应用程序的生命周期内进行垃圾回收提供一致性的工作。它还可以轻松地处理堆大小，将堆划分为较小的区域，而不是在每次暂停时回收整个堆，在默认的操作中，G1的配置是最小的， G1有两种配置选项，通常用于调整其性能。分别为:

MaxGCPauseMillis: 这个选项为每一个垃圾收集周期指定每个选项首选的暂停时间。它不是一个固定的最大值，如果需要的话G1可以超过这个时间，此值默认为200毫秒。意味着G1 将尝试调整GC周期的频率及每个周期中收集的区域，每一个周期大约 200 ms。
InitiatingHeapOccupancyPercent::这个选项指定了在G1使用的总堆百分比前将启动一个回收周期。默认的值为45。这意味着G1不会启动一个回收周期，直到45% 堆在使用。这包括新的(eden)和旧的区域使用。

kafka的broker使用堆内存和创建垃圾对象是相当高效的方式，因此可以将这些选项设置的更低。所使用的特定调优这里已经被证明适用于拥有64Gb内存的服务器。kafka在一个5Gb的堆里。对于MaxGCPauseMillis，可以配置此值为20毫秒，值初始化百分比设置为35%，这样垃圾回收比默认值稍早运行。

kafka的开始脚本没有使用G1回收器，而是默认使用并行的、并发的清除垃圾回收。调整它很容易，可以通过环境变量来实现。在start命令靠前的位置，对它进行修改:

[mw_shl_code=java,true]# export JAVA_HOME=/usr/java/jdk1.8.0_51
# export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC
-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
-XX:+DisableExplicitGC -Djava.awt.headless=true"
# /usr/local/kafka/bin/kafka-server-start.sh -daemon
/usr/local/kafka/config/server.properties[/mw_shl_code]

数据中心布局
对于开发系统，一个数据中心中的kafka broker的物理位置并不会令人担心，因为如果集群在短时间内部分或完全不可用时，也不会产生严重的影响。然而，当在生产环境中，停机就意味数据损失，无论是对用户服务不可用还是对用户所做的监测数据的损失。这时在kafka集群中配置复制变得非常关键(见第六章)，这时在数据中心机架中考虑broker的物理位置是很重要的，如果在部署kafka之前不解决，那么以后将产生昂贵的费用来移动服务器。

当broker分配新的分区时，kafka broker并没有rack-awareness（机架感知）。这意味着它不能考虑到两个broker可能位于同一物理架,或在同一区域(运行在AWS)如这样一个云服务中,因此可以很容易地将一个分区的所有副本分配给共享相同的电源和网络连接在同一个机架上的broker,如果这机架故障,这些分区将离线和无法访问。此外, 在恢复不稳定的leader选举时它也会导致额外的数据丢失 (更多关于这个内容在第6章)。

最佳实践方法是让每个Kafka broker在一个集群中安装在不同的机架中,或者至少没有分享单点故障和网络等基础设施服务。这通常意味着部署运行brokers的服务器将使用双电源连接(两种不同的电路)和双网络交换机(在服务器上要有一个绑定接口，称为双网卡绑定)。即使有双重连接,也要满足完全独立的broker机架。有时，在机柜中可能需要离线进行必要物理维护(如移动服务器,或重新部署电力连接)。

在Zookeeper上托管应用
kafka利用zookeeper用于存储元数据的信息如broker、主题和分区。这对于zookeeper来说并没有足够的多个节点专门用于kafka的集群，随着写的仅仅是对消费组群体的改变或者kafka的集群的本身。事实上,许多部署将多个kafka集群共用一个zookeeper集群(为每个集群修改zookeeper中的路径)。

kafka消费者和zookeeper
Apache kafka 0.9.0.0之前, 消费者,除了broker，还可以利用zookeeper, 直接存储关于消费者组的信息及offsets主题，并定期为每个分区提交被offsets的信息 (要使组中的消费者能够进行故障转移)。0.9.0.0版本,推出一个新的消费者接口,允许直接与Kafka broker管理。（这是第4章讨论的消费者）。

在某些特定的配置下，消费者和zookeeper让人担忧。然而，消费者有一个可配置的选择使用zookeeper或kafka提交offsets,以及提交间隔。如果消费者使用zookeeper进行消费,每个消费者将执行一个zookeeper为每个分区写间隔消耗。offset提交的合理间隔是1 分钟,因为这一段时间在客户失败的情况下消费者组将读取副本消息。这些提交是很重要的对于zookeeper的传输，特别是在一个有很多消费者的集群中需要考虑。如果zookeeper无法处理传输问题，使用较长的提交间隔是非常有必要的。但是,还是建议消费者使用最新的kafka库并使用kafka提交offsets,不要去依赖zookeeper。

除了为多个kafka集群使用单一的集群外,如果可以避免，不建议与其他应用程序共享这个集群。kafka对zookeeper延迟和超时非常敏感, 与此同时，通信中断会导致broker的行为不可预测。这很容易导致多个broker同时离线,他们如果失去zookeeper连接,这将导致分区也会离线。它会给集群的控制器带来压力, 在中断发生后很长一段时间都可能出现一些异常的错误，例如试图关闭执行一个broker。其他应用程序可以把压力放在zookeeper上, 要么大量使用，要么有不适当操作 , 所以应该放在他们自己的集体中。