UPKafka需要搭配zookeeper来部署，我们建议在资源充裕的情况下，UPKafka和zookeeper分开部署在不同机器上，请采用大于等于3台作为集群，zookeeper的数目为奇数最佳。

UPKafka是众多传统消息中间件的一个很好的替代品。消息中间件有一系列被选择使用的原因--1.与上游消息生产者解耦。2.缓冲未处理的消息等等。与其他绝对多数的消息中间件对比，UPKafka在吞吐量、partition（分区）概念的设计与构建、replica（备份）机制、容错机制等均有更优异的表现。而这些特性在应对有海量的、可扩展消息的处理的应用的需求时，是一个很好的解决方案。

在我们的经验中，相比较来说，使用消息中间件的应用程序一般是低吞吐量的，但一般也是要求点到点低延迟的，且要求数据持久化的高可靠性，而这几个功能UPKafka提供。

网站活动跟踪?

UPKafka的初始用例能够重构一个用户活动跟踪管道，作为实时发布-订阅的反馈系统。这意味着网站活动（页面浏览,搜索,或用户可能采取的其他行为)是发布到中央topics，每一种行为类型一种topic。这些反馈内容可供实时处理应用、实时监控应用订阅,并加载到Hadoop或离线数据仓库系统进行离线处理和报告。

活动跟踪数据通常是海量的，因为用户每一次的页面浏览，都会生产很多行为活动记录。

监控统计?

UPKafka通常用于操作的监控数据。这意味着，从分布式应用程序中聚集统计数据，并生产集中的操作数据记录。。

日志聚合?

UPKafka被广泛使用用作日志收集、聚合替代的解决方案。日志收集、聚合通常从servers上收集物理日志文件，并将日志文件汇总到一个中央结点(一个文件服务器或者HDFS)进行处理。UPKafka脱离了文件的细节进行了抽象,并给出了一个更简洁的抽象模型，将日志或事件消息的数据作为消息数据流。这一功能使得处理过程低延时，并使得支持多数据源和分布式数据消费更加简单。与日志中心化处理的系统如Scribe和Flume相比较,UPKafka提供同样优秀的性能,更可靠的持久化确认机制（replica机制的存在）,和更低的点到点的延迟。

流式处理?

UPKafka处理数据一般通过由多个阶段组成的数据处理管道,首先topics的数据作为原始数据被消费，然后数据被聚合、进一步丰富数据内容、或者转换传输到新的topics，等待进一步消费或后续处理。 例如,一个推荐新闻、文章的处理管道可能从RSS订阅反馈进行内容爬取，然后将数据发布到名为“articles”的topic下；进一步处理可能会清洗数据，使其变为标准化并去重，然后将清洗后的数据发布到一个新的topic；最后一步处理阶段会尝试向用户推荐数据内容。这样的数据处理管道根据各个topic创建实时数据流图。UPKafka从0.10.0.0版本开始,提供一个轻量级但功能强大的流处理库--UPKafka Streams.可以在Apache卡夫卡执行这样的数据处理如上所述。 除了UPKafka Streams,可以选择开源流处理工具包括Apache Storm和Apache Samza作为替代。

事件源?

事件源是一种应用的设计模式，状态的变化按照时间顺序存储到log的队列中。UPKafka支持存储海量的数据，这一特性使得应用可按照这一风格进行后台应用的构建。

提交日志?

UPKafka可以为分布式系统作为一种外部的提交日志进行服务。UPKafka的日志功能帮助完成结点之间的数据备份，并对于宕机的结点，通过“重新同步”的机制，帮助完成存储数据。UPKafka的日志压缩功能支持这一用例的需求功能。

通常我们评估UPKafka集群是否正常，主要是以下几点：

1. 查看zk上节点是否注册，登录zkCli.sh 或者使用UPKafka工具 bin/zookeeper-shell.sh [zkip]:[zkport]，然后ls /brokers/ids，查看列表中是否包含全部节点。不在列表中的节点即为与ZK连接异常或节点异常

2. 查看logs/server.log，稳定态时会打印清理超时偏移量提交、删除过期日志等

3. 查看bin/kafka-topics.sh --zookeeper [zkip]:[zkport] --describe查看ISR是否正常

4. 查看bin/kafka-consumer-groups.sh --bootstrap-server [listeners] --group [groupName] --describe查看订阅是否正常，积压情况（少许积压都是正常状态）。
   

UPKafka会发生Rebalance的原因一般有如下：

1. 分区变动（如扩分区、扩副本）

2. 消费线程挂了（KafkaConsumer维护，业务代码一般不可控，也很少发生）

3. 消费超时了，即poll()周期内未能处理完消息并提交偏移量（常见是这种情况）。

应对措施：

    情形一：等待分区变动完成，可以登录zk 查看ls /admin下是否有任务挂起

    情形二：有条件可以尝试重启应用观察

    情形三：调小max.poll.records（默认500）或增大max.poll.inteval.ms（默认30000）参数，后重启应用观察