震惊了！原来这才是kafka！.docxVIP

震惊了！原来这才是kafka！ kafka是一个分布式消息队列。具有高功能、长久化、多副本备份、横向扩展力量。生产者往队列里写消息，消费者从队列里取消息进行业务规律。一般在架构设计中起到解耦、削峰、异步处理的作用。 kafka对外使用topic的概念，生产者往topic里写消息，消费者从读消息。为了做到水平扩展，一个topic实际是由多个partition组成的，遇到瓶颈时，可以通过添加partition的数量来进行横向扩容。单个parition内是保证消息有序。 每新写一条消息，kafka就是在对应的文件append写，所以功能格外高。 kafka的总体数据流是这样的： kafka data flow 或许用法就是，Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉去指定Topic的消息，然后进行业务处理。图中有两个topic，topic 0有两个partition，topic 1有一个partition，三副本备份。可以看到consumer gourp 1中的consumer 2没有分到partition处理，这是有可能消灭的，下面会讲到。 关于broker、topics、partitions的一些元信息用zk来存，监控和路由啥的也都会用到zk。 生产 基本流程是这样的： kafka sdk product flow.png 创建一条记录，记录中一个要指定对应的topic和value，key和partition可选。先序列化，然后依据topic和partition，放进对应的发送队列中。kafka produce都是批量恳求，会积累一批，然后一起发送，不是调send()就进行马上进行网络发包。假如partition没填，那么情况会是这样的： key有填依据key进行哈希，相同key去一个partition。（假如扩展了partition的数量那么就不能保证了） key没填round-robin来选partition 这些要发往同一个partition的恳求依据配置，攒一波，然后由一个单独的线程一次性发过去。 API 有high level api，替我们把很多事情都干了，offset，路由啥都替我们干了，用以来很简约。还有simple api，offset啥的都是要我们本人记录。 partition 当存在多副本的情况下，会尽量把多个副本，安排到不同的broker上。kafka会为partition选出一个leader，之后全部该partition的恳求，实际操作的都是leader，然后再同步到其他的follower。当一个broker歇菜后，全部leader在该broker上的partition都会重新选举，选出一个leader。（这里不像分布式文件存储系统那样会自动进行复制保持副本数） 然后这里就涉及两个细节：怎样安排partition，怎样选leader。 关于partition的安排，还有leader的选举，总得有个执行者。在kafka中，这个执行者就叫controller。kafka使用zk在broker中选出一个controller，用于partition安排和leader选举。 partition的安排 将全部Broker（假设共n个Broker）和待安排的Partition排序 将第i个Partition安排到第（i mod n）个Broker上 （这个就是leader） 将第i个Partition的第j个Replica安排到第（(i + j) mode n）个Broker上 leader容灾 controller会在Zookeeper的/brokers/ids节点上注册Watch，一旦有broker宕机，它就能晓得。当broker宕机后，controller就会给遭到影响的partition选出新leader。controller从zk的/brokers/topics/[topic]/partitions/[partition]/state中，读取对应partition的ISR（in-sync replica已同步的副本）列表，选一个出来做leader。选出leader后，更新zk，然后发送LeaderAndISRRequest给受影响的broker，让它们转变晓得这事。为什么这里不是使用zk通知，而是直接给broker发送rpc恳求，我的理解可能是这样做zk有功能问题吧。 假如ISR列表是空，那么会依据配置，任凭选一个replica做leader，或者干脆这个partition就是歇菜。假如ISR列表的有机器，但是也歇菜了，那么还可以等ISR的机器活过来。 多副本同步 这里的策略，服务端这边的处理是follower从leader批量拉取数