kafka

kafka是linkedin开源出来的一个高吞吐的分布式消息系统。

kafka是使用scala开发，支持多种语言客户端（c++，java，python等）

其具备以下特点：

1支持高吞吐量的应用，其实原因就是它是多分区的，每个分区都可以作为数据的进出点，每个topic默认是两个分区

2无需停机即可扩展机器

3持久化：通过将数据持久化到硬盘以及replication防止数据丢失

4支持online，和offline两种场景，就是实时消费和离线消费都支持。storm是不支持离线消费的kafka，storm只进行实时计算，所以只实时消费。

offline消费：定期消费一次，比如按小时，或按天，离线。离线计算：spark，mapreduce

kafka主要是进行离线计算的，比如报表一天跑一次，kafka作为数据的缓冲层，避免了很大的消费成本。

／／

传统的消息队列产品：

jboss里的jms，单分区，就是无分区，它所有的接受数据和发出数据只有一个点。

阿里开源的recodemq，多实例，和kafka区别较大，支持多分区，前生是metaq。它开源比较晚，所以用的比较少，而且它本身是国内的产品。

kafka架构：

broker：服务端进程，消息中间件处理节点。

一个kafka节点就是一个broker

每个partition是数据进出的点。每个broker有很多topic，每个topic有很多partition

增加broker就可以扩容集群。

topic：比如我流量是一个topic，订单是一个topic，每个topic里面放的是一类相同的数据。根据数据量设计不同的分区数

partition中的每条消息都会被分配一个有序的id（offset，消费位置）

message：消息，最小订阅单元。

消费数据有两种：

push：服务端推送给消费者（以前绝大多数消息队列都是这种），增加了服务端的压力，服务端需要维护每个consumer的offset

所以这种消息队列在kafka里面不支持，这种低效的模式已经被淘汰了

pull：kafka唯一的消费模式，拉，consumer主动去拉，自己维护自己的offset，对我们开发来讲稍微麻烦些，因为需要我们自己维护offset。

写数据时，可以指定写topic的哪个分区。

如某topic建24个分区，每个分区存一个小时的数据，消费时指定对应的分区消费数据。

＝＝＝

高吞吐是kafka需要实现的核心目标，为此kafka做了一下一些设计：

1，数据持久化磁盘：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能，所以broker没有内存压力

2，zero－copy：减少io操作步骤

3，数据批量发送

4，数据压缩

5，topic划分为多个partition，提高partition（并行度）

负载均衡：

kafka实现方式：

1，producer根据用户指定的算法（划分分区的方式，比如按小时），将消息发送到指定的partition

2，存在多个分区，每个分区有自己的副本，每个副本存在不同的broker上

3，多个分区时需要选取出leader partition（通过zk的选举机制），leader partition负责读写，并由zookeeper负责fail over

4，通过zookeeper，管理broker与consumer的动态加入与离开。

扩容：增加broker，新增的broker都会向zookeeper注册，而producer及consumer会根据注册在zookeeper上的watcher感知这些变化，并及时作出调整