这篇文章中讲到了kafka中的比较重要的概念，而我则是主要说一下我自己对这些概念的理解吧。刚开始学习的时候还不太理解，后面慢慢开始有了自己的见解。
之前有学习过redis的集群，redis有哨兵、主从复制以及集群三种方式实现集群。主从复制主要是将节点进行备份，将不同的副本复制在不同的节点上，防止某个节点宕机了而导致数据的丢失，但是这样并不能做到很好的集群，因此就有了redis的集群。redis集群是通过ruby来实现的，一个key-value主要保存在某个主节点中，但是可以通过其他的主节点间接的访问到该key所对应的主节点，通过这样可以有效的提高高可用，而主从复制则是保证了数据的高可靠性。
而kafka的集群我个人觉得跟这个有点相似。kafka中的消息是有分类的，这样有利于消息的发送和消息的消费，不同的业务产生的消息也是有不同的，因此消息的topic就是为了进行分类的。每一种类别的topic都有两个属性：分区和副本，分区的话就是将消息均匀的放在不同的区间，即不同的节点（broker），副本就类似于redis中的主从复制，防止宕机后消息的丢失。每一个分区对应有一个leader，0个或多个follower，即副本，leader宕机了，副本就会顶上去，这个就有点像redis里面的集群了，而这个分区对应的节点就是由zookeeper来负责负载均衡了，这个就像redis里面的ruby一样了，所以两者的集群方式我感觉是有点相像的。
kafka的特点：
1、同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。
2、可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。
3、分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。
4、消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。
5、支持online和offline的场景。
使用场景：
1、Messaging
对于一些常规的消息系统,kafka是个不错的选择;partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS中的"事务性""消息传输担保(消息确认机制)""消息分组"等企业级特性;kafka只能使用作为"常规"的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息重发,消息发送丢失等)
2、Websit activity tracking
kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等
3、Log Aggregation
kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.
