Kafka到底是怎么撑起Netflix那海量消息洪流的，真有那么神奇吗？

（来源：Netflix技术博客、Kafka官方文档及相关技术社区分享）

“Kafka到底是怎么撑起Netflix那海量消息洪流的，真有那么神奇吗？”这个问题的答案，其实并不是说Kafka本身有什么点石成金的魔法，而是因为它恰好提供了一套非常契合Netflix这种超大规模公司需求的“工具箱”,并且Netflix的工程师们极其擅长使用这套工具。

我们要理解Netflix面对的是什么样的“洪流”。（来源：Netflix技术博客描述其数据规模）Netflix有全球数亿用户，每一天，这些用户在看电影、暂停、快进、搜索、登录、注销……每一个动作都会产生一条小小的消息，这可不是一条小溪，而是每秒钟数百万甚至上千万条消息的、永不间断的洪水，这些消息必须被可靠地收集起来，然后分发给各种需要它们的系统，比如推荐系统（用来实时推荐你可能喜欢的电影）、计费系统、内容制作团队（分析用户观看习惯）以及监控系统（确保服务不宕机）。

Kafka是怎么“接住”这股洪流的呢？

第一招：把“路”修成“高速公路”，而不是“单行道”。 （来源：Kafka核心设计思想）传统的消息系统，消息被一个消费者取走就没了，但在Netflix，同一条用户播放事件，推荐系统需要，数据分析团队需要，安全监控也需要，如果让每个系统都直接去访问用户产生的源头，源头会被拖垮，Kafka的做法是，它像一个巨大的、中央化的“日志”或“流水线”，数据一旦写入Kafka，就会被持久化保存一段时间（比如几天），不同的系统（消费者）可以按照自己的节奏，随时来读取这条“流水线”上的数据，互不干扰，A系统读慢了，不会影响B系统快速读取，这就好比把一条单行道改造成了多车道的高速公路，所有车辆（数据）有序行驶，出口（消费者）众多,各自去往不同的目的地。

第二招：化身“超级快递分拣中心”，把大包裹拆成小件并行处理。 （来源：Kafka分区机制详解）如果所有数据都堆在一条“流水线”上，那很快就会堵死，Kafka的聪明之处在于，它可以把一个大的数据流（称为Topic，用户播放事件”）切分成很多个小的、并行的“子流水线”，这叫“分区”，Netflix可以根据用户ID，把播放事件散列到100个分区里，这样的好处是巨大的：读写负载可以均匀分布到多台机器上，实现了水平扩展，想要处理更多数据？加机器、加分区就行了，保证了顺序性，同一个用户的事件总是被发往同一个分区，这样就能保证这个用户的事件被处理的顺序和他操作的顺序是一致的，不会出现“先记录播放结束，再记录开始”的乱序情况。

第三招：不当“娇气”的宝宝，天生就是“分布式”的硬汉。 （来源：Kafka设计目标）Kafka从诞生起就是为集群设计的，它的数据会在多台服务器（Broker）上存好多份副本，这样，就算某几台机器突然宕机了，数据也不会丢，服务也不会停，其他拥有数据副本的机器会立刻顶上来，对于Netflix这种要求99.99%高可用的服务来说，这个特性是生命线，他们可以放心地对Kafka集群进行维护、升级,而不用担心会中断全球的数据流。

第四招：Netflix自己的“神级操作”。 （来源：Netflix开源项目如Keystone、S3 sink connector）Kafka提供了强大的基础能力，但真正把它用到极致的还是Netflix自己,Netflix在Kafka之上构建了更高级的工具，

• 数据优先级管理： 他们把数据分成不同的优先级，像计费、登录这种关键数据，必须毫秒级处理，就走“高速通道”；而一些用于长期离线分析的数据，可以容忍一些延迟，就走“普通通道”,合理分配资源。
• 与云存储无缝对接： Netflix开发了工具，能把Kafka里的数据近乎实时地备份到亚马逊的S3云存储上，这样既拥有了Kafka的低延迟处理能力，又拥有了S3的海量、廉价存储能力，历史数据可以保存多年,供数据科学家们深度挖掘。
• 强大的监控和自愈能力： Netflix建立了全方位的监控系统，时刻盯着Kafka集群的健康状况，一旦有任何风吹草动，就能自动或手动快速响应,确保数据洪流永远畅通无阻。

回到问题本身，Kafka神奇吗？它本身的设计思想确实非常精妙和强大，是支撑海量数据流的理想基石，但更“神奇”的地方在于，Netflix的工程师们像一群顶级的交响乐指挥家，将Kafka这个强大的乐器，与他们自身庞大的技术生态系统完美融合，最终演奏出了一曲稳定、高效、支撑着全球娱乐的数据交响乐，它不是靠魔法,而是靠卓越的工程实践。