阿里高手实战总结，聊聊Kafka到底咋架构和原理那些事儿

（根据网络技术社区流传的阿里技术专家分享内容整理）

开头先打个比方，Kafka就像一个超级高效、永远不会丢件的“物流中转中心”，你想想，双十一的时候，淘宝每秒有上亿个订单产生，这些订单信息不能立刻全部处理完，得先有个地方存起来，然后后面各种各样的系统（比如扣库存的系统、发短信的系统、推荐商品的系统）再按自己的速度来取走处理，Kafka就是这个“中转仓库”。

核心角色：生产者、Kafka集群、消费者

这个物流中心有三类关键角色,特别简单：

1. 生产者：就是发货的人，比如你的淘宝APP，下了一个订单，它就把“订单已创建”这个消息打包成一个“包裹”,发送到Kafka中转中心。
2. Kafka集群：就是中转中心本身，它不是一个单独的仓库，而是由好多台服务器（叫做Broker）组成的“物流园区”，这样能力才够强,一台坏了别的还能顶上去。
3. 消费者：就是收货的人，比如那个负责扣库存的系统，它就会不停地从Kafka这个中转中心里，把“订单已创建”的包裹取走,然后执行扣库存的操作。

Kafka集群内部是怎么设计的？（仓库的奥秘）

这个中转中心设计得很巧妙，核心是两个概念：Topic（品类仓库）和Partition（分拣流水线）。

• Topic：你可以把它想象成中转中心里分门别类的仓库区域，比如有一个叫“订单”的仓库，专门存订单消息；一个叫“日志”的仓库，专门存用户点击行为的消息，生产者要发货,必须指定发到哪个Topic。
• Partition：这是Kafka高并发、高性能的真正秘诀，一个Topic（订单”）这个仓库，里面其实不是一个大平层，而是被分成了很多条独立的“分拣流水线”（Partition），订单”Topic可以分成3条流水线：P0, P1, P2。

这样做有两大天大的好处：

• 负载均衡：双十一订单海量来袭，可以同时往三条流水线上扔包裹，能力瞬间提升了3倍，不同的Broker服务器可以负责不同的Partition,这样压力就分散了。
• 并发处理：消费者也可以组队来收货，比如让三个消费者组成一个小组，消费者A从P0流水线上取包裹，消费者B从P1上取，消费者C从P2上取，大家各干各的，互不干扰,处理速度飞快。

消息是怎么存储和保证不丢的？（仓库的安保措施）

物流中心最怕两件事：包裹丢了，或者被重复处理,Kafka是怎么解决的呢？

1. 持久化存储：消息根本不是放在内存里一闪而过的，而是直接写入硬盘的，所以就算Kafka的服务器重启了，消息也还在，很多人会觉得写硬盘慢，但Kafka用了顺序追加写入（就像只在笔记本最后一页接着写，而不是翻来翻去地写）和零拷贝等技术,速度非常快。
2. 副本机制：这是防止数据丢失的核心，Kafka不会只把一份数据放在一台机器上，比如P0这条流水线，它会创建多个副本（比如3个），一个叫Leader，其他的叫Follower，分散在不同的Broker上，生产者只把包裹发给Leader，Follower会自动地从Leader那里同步数据，万一Leader所在的服务器突然宕机了，Kafka会马上从Follower中选举一个新的Leader出来继续服务，整个过程用户无感知，数据也不会丢,这就像一条流水线有好几个备份的车间主任。
3. Offset机制：这是防止重复消费或漏消费的关键，每个消费者在取走包裹时，都会在Kafka那里登记一下：“嗨，我已经从‘订单’仓库的P0流水线上取到第100个包裹了”，这个记录就叫Offset（偏移量），下次这个消费者再来取，就知道从第101个开始取，这样即使消费者程序中途崩溃了，重启后也能从上次的位置继续，不会漏掉包裹，也不会因为不知道取到哪了而把之前的包裹再取一遍（除非你故意把Offset重置到更早的位置）。

阿里高手总结的实战经验

根据分享，阿里这种体量的公司用Kafka,特别看重以下几点：

• 规划好Topic和Partition数量：Partition不是越多越好，太多了会导致文件碎片多，选举Leader慢，太少了又无法并行,需要根据业务高峰期的流量来预估。
• 监控是关键：要时刻盯着整个集群的健康状况，比如有没有消息堆积（消费者速度跟不上生产者的速度）、网络流量、磁盘使用量等，在阿里,有非常完善的监控大盘和报警系统。
• 副本数通常设为3：这样允许同时坏两台机器，数据依然是安全的,在可用性和存储成本之间取得平衡。
• 版本升级要谨慎：大规模集群升级是个技术活,要做好充分的兼容性测试和回滚预案。

Kafka的架构思想就是用“分而治之”（分区）来解决 scalability（可扩展性）问题，用“冗余备份”（副本）来解决 reliability（可靠性）问题，理解了这两个核心,就基本抓住了Kafka的精髓。