kafka详解

1基于页缓存技术，优于进程内存中
2常量耗时需求，基于磁盘的，顺序读顺序写操作性能为o（1）
3效率，过多的小io和过多的字节拷贝导致性能下降为了避免这种现象，kafka引入消息集合概念，那么消费者一堆数据的读取，生产者变成一堆数据的写入
4批压缩技术，生产者可以将数据压缩之后发送到kafka中，在消费者消费的时候才会被解压缩目前支持的压缩格式有snappy，gzip和lz4
5pull格式更适用于消费者，消费者可以依照自己的消费速率进行消费不会是消费者过载，但是相应的缺点是如果broker没有数据则消费者会不停的轮询等待消费所以需要配置参数long pull等待时长
6消费历史:消费者自行维护offset将其与数据一同维护到数据库中，特点是可以指定旧的offset重新消费，这与其他的消息队列不同
7exactly-once:数据安全性不丢不重刚好一次，生产者将数据发送到broker中的消息成为幂等性（未来可能加入的功能），从消费者意义来看将偏移量和数据存放到一起即可实现刚好一次的意义(0，1，-1)
8isr队列同步副本数保证数据高可用，假设这里的isr都done了有俩种方法第一个是等待isr中一个副本恢复，另一个是选择一个作为leader（无需在isr中）

9以上都是基于一个日志来说，在成千上万topic和分区中我们可以以一个更好的方法代替选举机制，优化Leader的选举过程也是非常重要的，因为这是系统不可用的窗口期。一个直观的实现是，如果一个节点故障了，为这个节点上所有的分区都独立的执行一次选举。代替这种方式，我们选择一个Broker作为Controller，Controller负责一个故障节点影响的所有分区的Leader变更。这样的好处是我们可以批量处理，减少独立选举时大量的通知，这使得大量分区需要选举时变得更快，代价更小。如果Controller故障了，剩余的Broker中会有一个节点成为新的Controller。
10日志压缩:kafka中的当前日志成为loghead，loghead包含了连续的offset和消息，历史日志（默认是24小时）成为logtail，logtail的日志会被压缩如有相同的key则压缩前面的key，只显示最新的key，如果设置日志压缩允许被删除，则删除标记将会引起之前相同的key被移出（包括拥有key相同的最新消息），压缩操作会在后台周期性的拷贝日志，清除操作不会影响阻塞读取
日志压缩提供下面保证:
1所有跟上消费的consumer能消费到所有消息，且offset是连续的，可以设置Top里的min.compaction.lag.ms用于设置保留loghead多久后才被压缩
2消息的顺序会被保留压缩不会重新排序，只是移出部分
3消息的offset不会改变，这是消息日志中的永久标志
4任何从头开始处理的consumer都会拿到每个key的最终状态另外只要consumer只要小于topic的delete.retention.ms设置（默认24小时），将会看到所有删除记录的所有删除标。
参考http://www.jasongj.com/2015/03/10/KafkaColumn1/
转自https://blog.youkuaiyun.com/weixin_43680708/article/details/89522696