https://www.ibm.com/developerworks/cn/opensource/os-cn-kafka/index.html

周 明耀
2015 年 6 月 10 日发布

• 示例：网络游戏

假设我们正在开发一个在线网络游戏平台，这个平台需要支持大量的在线用户实时操作，玩家在一个虚拟的世界里通过互相协作的方式一起完成每一个任务。由于游戏当中允许玩家互相交易金币、道具，我们必须确保玩家之间的诚信关系，而为了确保玩家之间的诚信及账户安全，我们需要对玩家的 IP 地址进行追踪，当出现一个长期固定 IP 地址忽然之间出现异动情况，我们要能够预警，同时，如果出现玩家所持有的金币、道具出现重大变更的情况，也要能够及时预警。此外，为了让开发组的数据工程师能够测试新的算法，我们要允许这些玩家数据进入到 Hadoop 集群，即加载这些数据到 Hadoop 集群里面。

【内存 算法测试】

对于一个实时游戏，我们必须要做到对存储在服务器内存中的数据进行快速处理，这样可以帮助实时地发出预警等各类动作。我们的系统架设拥有多台服务器，内存中的数据包括了每一个在线玩家近 30 次访问的各类记录，包括道具、交易信息等等，并且这些数据跨服务器存储。

我们的服务器拥有两个角色：首先是接受用户发起的动作，例如交易请求，其次是实时地处理用户发起的交易并根据交易信息发起必要的预警动作。为了保证快速、实时地处理数据，我们需要在每一台机器的内存中保留历史交易信息，这意味着我们必须在服务器之间传递数据，即使接收用户请求的这台机器没有该用户的交易信息。为了保证角色的松耦合，我们使用 Kafka 在服务器之间传递信息 (数据)。

图 1. 游戏设计图

>为了多线程处理，我们为每一个事件处理服务器或者每一个核创建了一个分区。Kafka 已经在拥有 1 万个分区的集群里测试过。

Kafka 的几个特性非常满足我们的需求：可扩展性、数据分区、低延迟、处理大量不同消费者的能力。这个案例我们可以配置在 Kafka 中为登陆和交易配置同一个主题。由于 Kafka 支持在单一主题内的排序，而不是跨主题的排序，所以我们为了保证用户在交易前使用实际的 IP 地址登陆系统，我们采用了同一个主题来存储登陆信息和交易信息。

【事件处理服务器在本地内存调用用户历史信息 预警】

当用户登陆或者发起交易动作后，负责接收的服务器立即发事件给 Kafka。这里我们采用用户 id 作为消息的主键，具体事件作为值。这保证了同一个用户的所有的交易信息和登陆信息被发送到 Kafka 分区。每一个事件处理服务被当作一个 Kafka 消费者来运行，所有的消费者被配置到了同一个消费者群组，这样每一台服务器从一些 Kafka 分区读取数据，一个分区的所有数据被送到同一个事件处理服务器 (可以与接收服务器不同)。当事件处理服务器从 Kafka 读取了用户交易信息，它可以把该信息加入到保存在本地内存中的历史信息列表里面，这样可以保证事件处理服务器在本地内存中调用用户的历史信息并做出预警，而不需要额外的网络或磁盘开销。

• 切换回 Kafka

上面的例子听起来有点绕口：首先从游戏服务器发送信息到 Kafka，然后另一台游戏服务器的消费者从主题中读取该信息并处理它。然而，这样的设计解耦了两个角色并且允许我们管理每一个角色的各种功能。此外，这种方式不会增加负载到 Kafka。测试结果显示，即使 3 个结点组成的集群也可以处理每秒接近百万级的任务，平均每个任务从注册到消费耗时 3 毫秒。

【topic topic 通信】

【预警标志 发送至其他主题】

上面例子当发现一个事件可疑后，发送一个预警标志到一个新的 Kafka 主题，同样的有一个消费者服务会读取它，并将数据存入 Hadoop 集群用于进一步的数据分析。

因为 Kafka 不会追踪消息的处理过程及消费者队列，所以它在消耗极小的前提下可以同时处理数千个消费者。Kafka 甚至可以处理批量级别的消费者，例如每小时唤醒一次一批睡眠的消费者来处理所有的信息。

【LinkedIn数据通道格式】

Kafka 让数据存入 Hadoop 集群变得非常简单。当拥有多个数据来源和多个数据目的地时，为每一个来源和目的地配对地编写一个单独的数据通道会导致混乱发生。Kafka 帮助 LinkedIn 规范了数据通道格式，并且允许每一个系统获取数据和写入数据各一次，这样极大地减少数据通道的复杂性和操作耗时。