分布式消息系统：Kafka（二）使用场景和（三）设计原理

2、使用场景

　　通常用来解耦、异步通信、流量控制。从而构建一个高效、灵活、消息同步和异步传输处理、存储转发、可伸缩和最终一致性的系统平台。目前流行的消息系统有Kafka、RocketMQ、RabbitMQ、ZeroMQ、ActivieMQ、MetaMQ、Redis(属于NoSQL但是具有发布订阅功能)，各有所长。
　　不过Kafka常用在高吞吐量和支持大量积压的环境中、应用系统监控、网站用户行为跟踪（将用户行为信息发送到Kafka上在通过其他大数据平台进行分析梳理）、流处理、持久性日志。

（１）Messaging

　　对于一些常规的消息系统,kafka是个不错的选择;partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS中的”事务性”“消息传输担保(消息确认机制)”“消息分组”等企业级特性;kafka只能使用作为”常规”的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息重发,消息发送丢失等)；

（２）Websit activity tracking

　　kafka可以作为”网站活性跟踪”的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等

（3）Log Aggregation

　　kafka的特性决定它非常适合作为”日志收集中心”;application可以将操作日志”批量”“异步”的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

3、设计原理

（1）持久性

　　kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数.