kafka的特性
它的设计初衷就是成为统一、实时处理大数据的平台，所以它必须支持几个场景：
1.高吞吐量的日志事件流
2.能承受大量积压
3.低延迟处理消息
4.能支持分区、分布式，实时处理且容错能力。
持久化，消息系统一般不同提供持久化，因为消息被消费了也就没有意义了，它不像数据库。不过kafka收到消息会顺序写入日志一旦数据落盘也就实现了持久化。Kafka在设计上采用O1的磁盘结构，也就是数据访问性能不随数据量增大而增加。用户可以自己设置Kafka把消息保存多久，这样重启后已经存储的消息可以继续恢复使用。
高吞吐量，它设计的目的就是高吞吐量，从写入方面来说，虽然Kafka会持久化数据到磁盘，但是每次写操作都只是写入系统页缓存中，然后由OS决定什么时候写入磁盘，而且写入磁盘时充分利用顺序读写方式，Kafka采用追加方式写入只能写入到日志文件末尾且不能修改。从读取的方面来说，会先从OS的页缓存中读取，如果消息存在就直接发送到Socket，由于大量使用页缓存所以命中概率很大尤其是最新的消息。再加上同时在数据写入和数据同步时采用了零拷贝技术，采用sendFile()函数。所谓零拷贝就是用户空间到内核空间之间的拷贝，这个过程省去了，比如要读取的数据在磁盘上，那么OS会把磁盘数据会拷贝到内核读缓存中，然后直接发往网卡缓存等待发送给用户，这个过程不再经过用户空间。
扩展性，有良好的横向扩展能力，它依赖Zookeeper来做集群协调者，使用普通PC服务器就可以搭建大规模集群。
多客户端支持，JAVA、C、PYTHON、Node.js等主流语言都支持。
丰富的安全机制
数据备份，副本机制
轻量级，Kafka代理是无状态的，代理不记录消息是否被消费，消费者偏移量的管理由消费者自己或者组协调器来维护，集群本身也不需要生产者和消费者的状态信息。
支持压缩，GZIP、SNAPPY、LZ4这三种压缩方式。通常把多条消息放到一个消息集合中，然后再把消息集合放到一条消息里，从而提高压缩率。
应用场景
通常用来解耦、异步通信、流量控制。从而构建一个高效、灵活、消息同步和异步传输处理、存储转发、可伸缩和最终一致性的系统平台。目前流行的消息系统有Kafka、RocketMQ、RabbitMQ、ZeroMQ、ActivieMQ、MetaMQ、Redis(属于NoSQL但是具有发布订阅功能)，各有所长。不过Kafka常用在高吞吐量和支持大量积压的环境中、应用系统监控、网站用户行为跟踪（将用户行为信息发送到Kafka上在通过其他大数据平台进行分析梳理）、流处理、持久性日志。
1.网站活动追踪
kafka原本的使用场景：用户的活动追踪，网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理，实时监测，也可加载到Hadoop或离线处理数据仓库。
每个用户页面视图都会产生非常高的量。
2.指标
kafka也常常用于监测数据。分布式应用程序生成的统计数据集中聚合。
3.日志聚合
使用kafka代替一个日志聚合的解决方案。
4.流处理
kafka消息处理包含多个阶段。其中原始输入数据是从kafka主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题，例如，一个推荐新闻文章，文章内容可能从“articles”主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。从0.10.0.0开始，轻量，但功能强大的流处理，就进行这样的数据处理了。
除了Kafka Streams，还有Apache Storm和Apache Samza可选择。
5.事件采集
事件采集是一种应用程序的设计风格，其中状态的变化根据时间的顺序记录下来，kafka支持这种非常大的存储日志数据的场景。
6.提交日志
kafka可以作为一种分布式的外部提交日志，日志帮助节点之间复制数据，并作为失败的节点来恢复数据重新同步，kafka的日志压缩功能很好的支持这种用法，这种用法类似于Apacha BookKeeper项目。