近闲来无事 学习下kafka 现将笔记总计如下
一.简介
kafka是由Linkedin公司开发，是一个分布式的，分区的，多副本的，多订阅者的，基于zookeeper协调的分布式日志系统（MQ系统），常见可以用于web/ngix日志，访问日志，
消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目
主要应用场景：日志收集系统和消息系统
kafka主要涉及目标：
以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上的数据也能保证常数时间的访问性能。
高吞吐率，即使在非常廉价的商用机器上也能做到单机支持每秒100K条信息的传输。
支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输
同时支持离线数据处理和实时数据处理
Scale Out支持在线水平扩展 (不懂可以翻看我上一篇博客)
二.消息系统介绍
一个消息系统负责将数据从一个应用传递到另外一个应用 ，应用只需关注于数据，无需关注于数据在两个或多个应用间是如何传递的。分布式消息传递是基于可靠的消息队列
在客户端应用和消息系统之间异步传递消息，有两种主要的消息传递模式：点对点传递 发布 订阅方式 大部分的消息系统选用发布 订阅方式 kafka就是一种 发布 订阅模式
1.点对点传递模式
在点对点消息系统中 消息持久化到一个队列中 此时 将有一个或多个消费者消费队列的数据 但是一条消息只能被消费一次 当一个消费者消费了队列的某条数据之后 该条数据则从消息队列
中删除。该模式即使有多个消费者同时消费数据，也能保持数据处理的顺序（生产者发送一条消息到queue 只有一个消费者能收到）
2,发布 订阅者模式
在发布 订阅者系统中 消息被持久化到一个Topic中 与点与点消息系统不同的是 消费者可以订阅一个或多个Topic 消费者可以消费该Topic的所有数据 同一条数据可以被多个消费者消费 数据被消费
后不会立马删除 （发布者发送到topic的信息 只有订阅了topic的订阅者才会收到消息）
二..kafka的优点
1.解耦
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的.消息系统在处理过程中间插入了一个隐含的，基于数据的接口层，两边的处理过程都要实现这一接口，
这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2.冗余
有些情况下 处理数据的过程会失败。除非数据被持久化 否则将造成丢失 消息队列把数据进行持久化 直到它们已经被完全的处理 通过这一方式规避掉了数据丢失风险，
许多消息队列所采用的“插入-获取-删除”范式中，在把一个消息从队列删除之前 需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据安全的保存到你使用完毕。
3.扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码，不需要添加参数。扩展就像调大电力按钮一样简单。
4.灵活性 && 峰值处理能力
在访问量剧增的情况下 应用仍然需要继续发挥作用 但是这样得突发流量并不常见 如果为以能处理这类峰值的访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键
组件顶住突发的访问压力 而不会是因为突发的超负荷请求而完全崩溃
5.可恢复性
系统的一部分组件失效时 不会影响到整个系统 消息队列降低了进程间的耦合度 所以即使 一个处理消息的队列挂掉 加入队列中的消息仍然可以在系统恢复后被处理
6.顺序保证
在大多使用场景下 数据处理的顺序都很重要 大部分消息队列本来就是排序的 并且能保证数据会按照特定的顺序来处理，kafka保证一个Partition内的消息有序性
7.缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间 消息队列通过一个缓冲层来帮助任务最高效率的执行--写入队列的处理会尽可能的快速.
该缓冲有助于控制和优化数据流经过系统的速度。
8.异步通信
很多时候，用户不想也不需要立即处理消息，消息队列提供了异步处理机制，允许用户把一个消息放入队列 但并不立即处理它。想向队列中放入多少消息就放多少 然后在需要的时候再去处理它们
三 kafka中的术语解释
1.概述
上图的一个Topic中配置了三和partition partiton1有两个offset： 0和1 partition2有4个offset partiton3有一个offset 副本的id和副本所在的机器的id恰好相同
如果一个topic的副本数为3 那么kafka将在集群中 为每个paitition创建三个相同的副本 集群中的 每个broker存储一个或多个partition 多个producer和consumer可同时生产和消费数据
2.broker
kafka集群中包含一个或多个服务器 服务器节点称为broker
broker存储topic的数据，如果某topic有N个partition 集群中有N个broker，那么每个broken存储该topic的一个Partition
如果某个topic有N个Partition 集群中有（N+M）个broker 那么其中有 N个Broker存储该topic的一个partition 剩下的M个broker不存储该topic的partition数据
如果某个topic有N个Partiton 集群中broker的数目少于N个 那么一个broker存储该topic的一个或多个partition 在实际生产环境中 尽量避免这种情况发生 这种情况导致kafka集群数据不均衡
3.partition
topic的数据 分割成一个或多个partition 每个topic至少有一个partiton 每个partiton中的数据使用多个segment文件存储 partiton中的数据是有序的 不同partition间的数据丢失了顺序。如果topic
有多个partiton 消费数据时就不能保证数据的顺序 在需要严格保证信息的消费顺序的场景下 需要将partiton的数目设为1
4.producer
生产者即数据的发布者 该角色将消息发布到kafka的topic中 broken接收到生产者发送的消息之后 broken将该消息追加到当前由于追加数据的segment文件中 生产者发送的消息 存储到一个partiton中
生产者也可以指定数据存储的partition
5.Consumer
消费者可以从broken中读取数据 消费者可以消费多个topic中的数据
6.Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定Group Name 若不指定则属于默认）
7.leader
每个partition有多个副本 其中有且仅有一个作为leader leader是当前负责数据读写的partition
8.follwer
follow跟随leader 所有写请求都通过leader路由 数据变更会广播给所有的follwer follwer与leader保持数据同步 如果leader失效 则从Follwer中选举出一个新的Leader 当Follwer 中选举一个新的Leader 当
Follwer与Leader挂掉，卡住或者同步太慢 leader会把这个follwer从 "in sync replicas" (ISR)列表中删除 重新创建一个Follwer