十五、kafka高性能、高吞吐的原因
1、应用
日志收集（高频率、数据量大）
2、如何保证
（1）磁盘的顺序读写-pagecache关联
rabbitmq基于内存读写，而kafka基于磁盘读写，但却拥有高性能
传统磁盘读写都是随机读写，数据没有存到一起，浪费了寻址时间和旋转时间
如果是顺序读写：无需寻址 ，一次往后读，同时还有按page预读到内存的机制
容量大，消息堆积能力比内存更强大
（2）零拷贝技术-Linux支持（kafka高性能的原因）
传统方式：用户访问网卡
需要将用户态切换到内核态，由内核线程操作磁盘
使CPU存在上下文切换
此外，读取数据是将文件读到内核缓冲区，并拷贝到用户缓冲区，最后拷贝到内核态的socket缓冲区，将数据发到网卡，响应到客户端（用户态和内核态的两次切换）
零拷贝方式：
磁盘文件--内核缓冲区--网卡接口--消费者进程（不存在CPU的切换，直接在内核态完成消息的读取）
（原因：消息没有必要读到用户，消息只负责传递，无需读到用户缓冲区）【与java应用程序进行数据传递不同】
（3）分区分段+索引
partition可以保证topic的消息堆积，分区可以分散到多个broker，减轻了消息堆积
partition也是逻辑概念，实际存储：多个segment文件存储，针对segment又包含索引文件，提升读取效率，提高了读取数据的并行度（分段加锁）
（4）批量压缩
把多条消息使用gzip压缩，对压缩后的数据进行传输
（5）批量读写
堆积到一定的数量再进行发送，可以节省带宽，并提高效率
（6）直接操作页存
直接操作pagecache（页存），而不是jvm-不需要创建对象等操作
避免了对象创建及GC的耗时，读写速度会更快，进程重启时，数据也不会丢失【堆中的数据会丢失】
pagecache的刷盘时间由操作系统完成，基于内存，效率高
十二、kafka的pull和push各有什么优缺点
1、pull-主动拉取
由消费者根据处理能力，自己控制
按需所取，但不实时
2、push-推送
实时发送消息
缺点：可能会导致消费者压力大，可能会压垮
十三、Kafka、ActiveMQ、RabbitMQ、RocketMQ对比
1、ActiveMQ-半死不活
生产环境中较少，支持的数据量较小
遵循JMS消息中间件的规范，支持事务的ACID特性
支持XA协议（两段式提交，MySQL也支持）
官方维护少，社区不活跃
万级别吞吐量
2、RabbitMQ
基于AMQP协议
使用erlang开发，性能比较好，支持高并发
客户端支持多种语言
社区活跃、文档全面
但erlang语言对java不友好，不利于二次开发
学习成本高、架构复杂
万级别吞吐量，不适用于高并发
3、kafka-高性能、高并发
高可用
生产环境大量使用
ELK使用kafka收集日志
缺陷：单机容量有限，一台broker能放的partition数量有限，64以内最好
社区更新慢，部分代码使用java开发，二次开发有限制
吞吐量百万级别，Apache大数据标配
4、RocketMQ-基于阿里-火箭
性能和吞吐较高，高可用
基于java，利于二次开发
☆高可靠，消息零丢失（适用于互联网金融）
已经被捐赠给阿帕奇，社区活跃度一般
支持语言比较少-java、c++
吞吐量十万级别
作者：哥们要飞
