2016年1月13日星期三

Kafka_001:基本特点与原理 (摘录+整理)

Kafka 是 LinkedIn 开发并开源出来的一个高吞吐的分布式消息系统。特点如下:
  • 高吞吐量
    在标准硬件之上,支持每秒数百万的消息。
  • 横向扩展
    不停机扩展机器节点。
  • 数据持久化
    保证消息不丢失,时间复杂度为O(1)的磁盘结构,提供了常量时间的性能,即使是海量信息(TB级)。
  • 实时
    生产者产生的消息对消费者立即可见,对基于事件的系统(比如CEP)是至关重要的。
  • 多客户端支持
    客户端支持:java、.NET、PHP、Ruby、Python。
  • 分布式
    支持消息分区,以及在消费机器集群上的分发消息,并维护每个分区的排序语义。
1. 适用与不适用场景
(1)Kafka 不能保证消息的发送与接收绝对可靠性,因此不适用于对消息可靠性要求很高的消息系统。
(2)用户行为数据
跟踪网页活动(Websit Activity Tracking)的最佳工具;可以将网页/用户操作等信息发送到 Kafka 中,并实时监控或离线分析。
(3)Kafka 适合收集日志,应用可以把操作日志批量、异步地发送到 Kafka 集群中,这对 Producer 端而言,几乎感觉不到性能的开支,而且 Consumer 端可以使用 Hadoop 等其他系统化的存储和分析系统。
(4)基于事件的消息

2.  架构图


多个broker协同合作,producer和consumer部署在各个业务逻辑中被频繁的调用,三者通过zookeeper管理协调请求和转发。
producer到broker的过程是push,也就是有数据就推送到broker,而consumer到broker的过程是pull,是通过consumer主动去拉数据的,而不是broker把数据主动发送到consumer端的。
启动顺序如下:
(1)启动 zookeeper 的 server,即图中的ZooKeeper。
(2)启动 kafka 的 server,即图中的Broker。
(3)启动 Producer,如果生产了数据,会先通过 ZooKeeper找到Broker,然后将数据存放进Broker。
(4)启动 Consumer,如果要消费数据,会先通过ZooKeeper找到对应的Broker,然后消费。

ZooKeeper 用于管理、协调 Broker。每个 Broker 都通过 ZooKeeper 协调其它 Broker。当 Kafka系统中新增了代理或者某个代理故障失效时,ZooKeeper 服务将通知生产者和消费者。生产者和消费者据此开始与其它 Broker 协调工作。
3. 小结
Kafka提供了一个实时的发布/订阅解决方案,它克服了消费实时大数据的挑战。Kafka还支持在Hadoop系统上做并行数据载入。

参考文献:
1. http://blog.csdn.net/yfkiss/article/details/17348693
2. http://blog.csdn.net/chszs/article/details/20875793
3. http://m.open-open.com/m/lib/view/1354277579741.html

没有评论: