1. 设计
   1. 结构
      1. zookeeper
         1. 帮助管理kafka的重新选举
      2. 问题：leader的选举是实时性还是阶段的还是一次性的
      3. Topic=一类消息，分为多个partition
         1. partion（分区=一个apped log文件，任何发布到此的消息直接追加到文件位置尾部~有单文件最大容量的限制）-里面消息数据为有序队列
            1. （replica）副本n
            2. 宕机数目<= (副本数)n - 1
            3. 在创建topic时指定，一般3个
            4. 分布不同节点（broker）
            5. 保证数据的容错安全性
            6. offset=追加的消息在文件中的位置
            7. long型数字
            8. 标记一条消息
            9. 选举一个leader
            10. 负责用户的读写请求
            11. 同步消费操作给其它副本
            12. 定期的消除数据
            13. 一般七天
            14. 减少消息消费后对文件内容改动的磁盘IO开支
            15. 目的：
            16. 通过分区来避免文件尺寸达到单机磁盘上限
            17. 日志内容可以分散到多个server（kafka的实例）
            18. 每个partition都会被当前的server保存
            19. 提供高并发存取
            20. 更多partition意味着更多的consumer
         2. partitions数目 = leader数目
            1. 将“leader”均衡分布在每个实例（server 节点）上
      4. producer
         1. 将信息发送到指定的Topic
            1. 也可决定到哪一个partition上
            2. 基于“round-robin”方式或者通过其他算法
      5. consumer 属于 group
         1. 一个partition中消息只会被group中的一个consumer消费
            1. 每个group中consumer消息消费互相独立
            2. 对于那个cunsumer消息是有序的
            3. 从Topic角度，消息仍不是有序地
         2. kafka只能保证一个
         3. offset（偏移量）数据
            1. 专一的负责输出和输入
            2. consumer可以按照偏移量自定义读取
            3. 线性向前消费
   2. 设计要求
      1. 一个topic来说
         1. 同一个group中不能有多余partitions数目的consumer同时消费，某些无法得到消息
      2. Guarantees
         1. 1.发送到partitions中的消息会按照它接收的顺序追加到日志中
            1. 自由主题
            2. 自由主题
            3. 自由主题
         2. 2.对于消费者，消费顺序和日志顺序一致
         3. 3.如果Topic的“replicationfactor”为N，那么允许N-1的kafka实例失效
   3. 强依赖zookeeper
      1. zookeeper负责维护任何consumer，producer状态信息，分担kafka的压力
         1. producer,consumer客户端实现轻量级
            1. 可以随意离开不造成影响
      2. 子主题 2
   4. 定义
      1. 有JMS特性