Kafka学习笔记02 - 适用场景

不要求消息准确性很高，可是消息的吞吐量大

因为Kafka能够处理高吞吐量的消息，因此很是适合处理系统点击日志收集。即便是有的消息被消费了一次以上，但并不影响统计结果的精确性。

并且系统点击日志通常都量很大，放到单一的硬盘中很容易把硬盘撑爆。而Kafka的分布式存储系统，能够自动的实现消息分片和服务器扩容的功能，适合收集日志。

不少实时分析系统，都是经过Kafka + Storm进行日志收集和计算分析的。

业务代码实现幂等性，且消费者速度与生产者基本匹配

若是业务代码已经实现了幂等性，那么能够经过Kafka大幅提高业务系统的性能。实现幂等性有两种方式，一种是屡次调用方法都会返回一样的结果，而不是累加的结果；另外一种是在消费者端增长一个缓存，缓存中存储已经消费消息的主键，一旦缓存中存在这个主键，则再也不重复消费。

另外一个须要注意的问题就是消费者的速度不能和生产者差异太大，若是消费者速度远远小于生产者速度，致使时间差大于消息保存的时间，则会致使消息还将来得及消费就被删除。好比大于7天的消息就会删除，可是消费者还将来得及消费7天以前的消息，那么消息将丢失。遇到这种状况能够增长消息中介的分区和消费者实例，并行消费。可是若是瓶颈在数据库等其余资源，那么这种场景就不适合使用Kafka。

若是想使用Kafka处理仅仅发送一次的消息

因为Kafka的性能超过了传统的消息中间件不少，因此使用Kafka带来的优点很明显。

若是也想使用Kafka处理仅仅发送一次的消息，好比，业务端程序并无实现幂等性。使用这种消息消费模型，须要以牺牲性能做为代价，可是因为其天生支持高可用和消息分片，则仍然比ActiveMQ这种消息中间件更好用。

首先须要每次存储消息都刷入磁盘。Kafka为了提高性能，通常是先将消息放入内存，等到必定数据或时间，才写入磁盘。设置为每写入一次消息，就刷一次盘。

开启事务永远是最保险的回滚数据的方式，若是将消息消费的偏移量放在Zookeeper或者消费者的客户端，是不能保证偏移量和业务数据在一个事务中一块儿回滚的。因此这里须要修改Kafka的程序，将消息的偏移量存入业务数据的数据库。若是是一个库，只要开启事务就能够，若是是在不一样的库，则须要分布式事务。

在Kafka公布的0.9的新版本中提供了将偏移量存入本身定制的数据库中。预计在2014年12月发布。

Kafka的不适用场景，不支持消息失败的自动重试

ActiveMQ等JMS消息中间件，是支持消息失败重试的，自动重试n次在将消息放入死消息队列，供人工审查。不会由于某个消息有问题，影响后面的消息消费。可是Kafka这点要很是当心，若是采用将偏移量存入数据库，和业务数据一个事务，那么一旦某个消息有问题，须要完善的判断机制来判断消息是否已经消费，不然可能出现因为某一个消息消费不了而致使后面的消息都不能消费的状况。