#kafka为什么有高吞吐量
1 由于接收数据时可以设置request.required.acks参数，一般设定为1或者0，即生产者发送消息0代表不关心kafka是否接收成功，也就是关闭ack；1代表kafka端leader角色的patation（多个patation，并且每个会有多个副本）接收到数据则返回成功不管副本patation的状态。
2 由于消费者的消费情况不归kafka消息管理引擎维护，而是放在消费者组端（***同一消费者组不会消费相同数据）。这样也能减少kafka的核心消息引擎能够减少工作只负责输出数据，pull工作模式的好处是可以根据消费者的能力拉取数据，但是消费端获取数据实质是准实时的；
以上两点可以保证kafka具有较强的吞吐量，消息中心也只负责输入和输出，并不关心多余的操作
===
#min.insync.replicas 这个参数设定patation中的最少副本数是多少，默认值为1 ；
===
#废弃了replica.lag.max.messages参数(0.9及以后)：
该参数为follower是否生效的判断，而在实际的生产中很难确定这个值，由于吞吐量在不同时间点可能数量级不同，导致follower拉取leader数据很难跟上节奏，这样就会在ISR队列中不断的加入移除这个follower。
****
那么有什么可能的原因会使得follower副本与leader副本不同步呢？归纳起来有三种原因:
- 速度跟不上——follower副本在一段时间内都没法追上leader副本的消息写入速度，比如follower副本所在broker的网络IO开销过大导致备份消息的速度慢于从leader处获取消息的速度
- 进程卡住了——follower副本在一段时间内根本就没有向leader副本发起FetchRequest请求(该请求就是获取消息数据)，比如太过频繁的GC或其他失败导致
- 新创建的——如果用户增加了备份因子，很显然新follower副本在启动过程初始肯定是全力追赶leader副本，因而与其是不同步的
replica.lag.max.messags参数就是用于检测第一种情况的。当然Kafka还提供了一个参数 replica.lag.time.max.ms来检测另外两种情况。比如如果设置 replica.lag.time.max.ms=500ms，只要follower副本每隔500ms都能发送FetchRequest请求给leader，那么该副本就不会被标记成dead从而被踢出ISR。
===
#“消费数据”策略和“生产数据”策略
consumer消费partation中的数据只能保证partation内数据的顺序，而不能保证partation间的顺序；
product可以通过rank策略或者hash策略(默认)来把数据具体分发到某个partation中；
一个partation的数据被消费时只能流向1个consumer，partation内部数据是1个单元。