kafka 技术性能分析
1.经过磁盘顺序读写，效率高，appendLog，对比raid-5 7200rpm的磁盘算法
sequence io 600M/s缓存
random io 100kb/s安全
kafka写操做时，依赖底层文件系统的pagecache功能，pagecache会将尽可能多的将空闲内存，当作磁盘缓存，写操做先写到pageCache，并将该page标记为dirty；发生读操做时，会先从pageCache中查找，当发生缺页时，才会去磁盘调整；当有其余应用申请内存时，回收pageCache的代价是很低的网络
，使用pageCache的缓存功能，会减小咱们队JVM的内存依赖，JVM为咱们提供了GC功能，依赖JVM内存在kafka高吞吐，大数据的场景下有不少问题。若是heap管理缓存，那么JVM的gc会频繁扫描heap空间，带来的开销很大，若是heap过大，full gc带来的成本也很高；全部的In-Process Cache在OS中都有一份一样的PageCache。因此经过只在PageCache中作缓存至少能够提升一倍的缓存空间。若是Kafka重启，全部的In-Process Cache都会失效，而OS管理的PageCache依然能够继续使用。并发
2.sendFileapp
传统网络IO模型dom
① 操做系统将数据从磁盘拷贝到内核区的pagecache异步
② 用户程序将内核区的pagecache拷贝到用户区缓存socket
③ 用户程序将用户区的缓存拷贝到socket缓存中高并发
④ 操做系统将socket缓存中的数据拷贝到网卡的buffer上，发送
问题：四次system call 两次context切换，同一份数据在缓存中拷贝屡次，效率很低，拷贝动做彻底能够在内核中进行，将2 3 步去掉，sendfile就是完成这一功能
kafka设计初衷是数据的拷贝彻底经过pageCache来进行，尽可能减小磁盘读写，若是kafka生产消费配合的好，那么数据彻底走内存，这对集群的吞吐量提高是很大的
当集群只有写操做时，此时的集群只有写，没有读操做。10M/s左右的Send的流量是Partition之间进行Replicate而产生的。从recv和writ的速率比较能够看出，写盘是使用Asynchronous+Batch的方式，底层OS可能还会进行磁盘写顺序优化。而在有Read Request进来的时候分为两种状况，第一种是内存中完成数据交换。
② 已经从pageCache刷出的数据，这时候的数据能够看出大部分走的是磁盘io
TIPS
① kafka官方不建议使用log.flush.interval.messages和log.flush.interval.ms来强制刷盘，由于高可靠应该经过replica副原本保证，强制刷盘对系统性能影响很大（生产是100000 和60000）
② 能够经过调整/proc/sys/vm/dirty_background_ratio和/proc/sys/vm/dirty_ratio来调优性能。
a. 脏页率超过第一个指标会启动pdflush开始Flush Dirty PageCache。
b. 脏页率超过第二个指标会阻塞全部的写操做来进行Flush。
c. 根据不一样的业务需求能够适当的下降dirty_background_ratio和提升dirty_ratio。
（生产是10 和 20）
2 partition
Partition是Kafka能够很好的横向扩展和提供高并发处理以及实现Replication的基础。
扩展性方面。首先，Kafka容许Partition在集群内的Broker之间任意移动，以此来均衡可能存在的数据倾斜问题。其次，Partition支持自定义的分区算法，例如能够将同一个Key的全部消息都路由到同一个Partition上去。 同时Leader也能够在In-Sync的Replica中迁移。因为针对某一个Partition的全部读写请求都是只由Leader来处理，因此Kafka会尽可能把Leader均匀的分散到集群的各个节点上，以避免形成网络流量过于集中。
并发方面。任意Partition在某一个时刻只能被一个Consumer Group内的一个Consumer消费(反过来一个Consumer则能够同时消费多个Partition)，Kafka很是简洁的Offset机制最小化了Broker和Consumer之间的交互，这使Kafka并不会像同类其余消息队列同样，随着下游Consumer数目的增长而成比例的下降性能。此外，若是多个Consumer恰巧都是消费时间序上很相近的数据，能够达到很高的PageCache命中率，于是Kafka能够很是高效的支持高并发读操做，实践中基本能够达到单机网卡上限。
不过，Partition的数量并非越多越好，Partition的数量越多，平均到每个Broker上的数量也就越多。考虑到Broker宕机(Network Failure, Full GC)的状况下，须要由Controller来为全部宕机的Broker上的全部Partition从新选举Leader，假设每一个Partition的选举消耗10ms，若是Broker上有500个Partition，那么在进行选举的5s的时间里，对上述Partition的读写操做都会触发LeaderNotAvailableException。
再进一步，若是挂掉的Broker是整个集群的Controller，那么首先要进行的是从新任命一个Broker做为Controller。新任命的Controller要从Zookeeper上获取全部Partition的Meta信息，获取每一个信息大概3-5ms，那么若是有10000个Partition这个时间就会达到30s-50s。并且不要忘记这只是从新启动一个Controller花费的时间，在这基础上还要再加上前面说的选举Leader的时间 -_-!!!!!!
此外，在Broker端，对Producer和Consumer都使用了Buffer机制。其中Buffer的大小是统一配置的，数量则与Partition个数相同。若是Partition个数过多，会致使Producer和Consumer的Buffer内存占用过大。
tips
1. Partition的数量尽可能提早预分配，虽然能够在后期动态增长Partition，可是会冒着可能破坏Message Key和Partition之间对应关系的风险。
2. Replica的数量不要过多，若是条件容许尽可能把Replica集合内的Partition分别调整到不一样的Rack。
3. 尽一切努力保证每次停Broker时均可以Clean Shutdown，不然问题就不只仅是恢复服务所需时间长，还可能出现数据损坏或其余很诡异的问题。
3
Producer
Kafka的研发团队表示在0.8版本里用Java重写了整个Producer，听说性能有了很大提高。我尚未亲自对比试用过，这里就不作数据对比了。本文结尾的扩展阅读里提到了一套我认为比较好的对照组，有兴趣的同窗能够尝试一下。
其实在Producer端的优化大部分消息系统采起的方式都比较单一，无非也就化零为整、同步变异步这么几种。
Kafka系统默认支持MessageSet，把多条Message自动地打成一个Group后发送出去，均摊后拉低了每次通讯的RTT。并且在组织MessageSet的同时，还能够把数据从新排序，从爆发流式的随机写入优化成较为平稳的线性写入。
此外，还要着重介绍的一点是，Producer支持End-to-End的压缩。数据在本地压缩后放到网络上传输，在Broker通常不解压(除非指定要Deep-Iteration)，直至消息被Consume以后在客户端解压。
固然用户也能够选择本身在应用层上作压缩和解压的工做(毕竟Kafka目前支持的压缩算法有限，只有GZIP和Snappy)，不过这样作反而会意外的下降效率！！！！ Kafka的End-to-End压缩与MessageSet配合在一块儿工做效果最佳，上面的作法直接割裂了二者间联系。至于道理其实很简单，压缩算法中一条基本的原理“重复的数据量越多，压缩比越高”。无关于消息体的内容，无关于消息体的数量，大多数状况下输入数据量大一些会取得更好的压缩比。
不过Kafka采用MessageSet也致使在可用性上必定程度的妥协。每次发送数据时，Producer都是send()以后就认为已经发送出去了，但其实大多数状况下消息还在内存的MessageSet当中，还没有发送到网络，这时候若是Producer挂掉，那就会出现丢数据的状况。
为了解决这个问题，Kafka在0.8版本的设计借鉴了网络当中的ack机制。若是对性能要求较高，又能在必定程度上容许Message的丢失，那就能够设置request.required.acks=0 来关闭ack，以全速发送。若是须要对发送的消息进行确认，就须要设置request.required.acks为1或-1，那么1和-1又有什么区别呢？这里又要提到前面聊的有关Replica数量问题。若是配置为1，表示消息只须要被Leader接收并确认便可，其余的Replica能够进行异步拉取无需当即进行确认，在保证可靠性的同时又不会把效率拉得很低。若是设置为-1，表示消息要Commit到该Partition的ISR集合中的全部Replica后，才能够返回ack，消息的发送会更安全，而整个过程的延迟会随着Replica的数量正比增加，这里就须要根据不一样的需求作相应的优化。
tips
1. Producer的线程不要配置过多，尤为是在Mirror或者Migration中使用的时候，会加重目标集群Partition消息乱序的状况(若是你的应用场景对消息顺序很敏感的话)。
2. 0.8版本的request.required.acks默认是0(同0.7)。
4
Consumer
Consumer端的设计大致上还算是比较常规的。
• 经过Consumer Group，能够支持生产者消费者和队列访问两种模式。
• Consumer API分为High level和Low level两种。前一种重度依赖Zookeeper，因此性能差一些且不自由，可是超省心。第二种不依赖Zookeeper服务，不管从自由度和性能上都有更好的表现，可是全部的异常(Leader迁移、Offset越界、Broker宕机等)和Offset的维护都须要自行处理。
• 你们能够关注下不日发布的0.9 Release。这帮货又用Java重写了一套Consumer。把两套API合并在一块儿，同时去掉了对Zookeeper的依赖。听说性能有大幅度提高哦~~
tips
强烈推荐使用Low level API，虽然繁琐一些，可是目前只有这个API能够对Error数据进行自定义处理，尤为是处理Broker异常或因为Unclean Shutdown致使的Corrupted Data时，不然没法Skip只能等着“坏消息”在Broker上被Rotate掉，在此期间该Replica将会一直处于不可用状态。