kafka learning map （一）_kafka读多写少的map

kafka learning map （一）

kafka是谁？

一言以蔽之：kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等。Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。介绍中可以看到最常用和最重要的两个功能–日志收集和消息系统。

那kafka是为了解决什么问题而设计出来的呢？

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
• 同时支持离线数据处理和实时数据处理。
• Scale out:支持在线水平扩展。

Kafka架构初探

kafka架构图（1）

kafka架构图（2）

整体概述

图（1）中模拟了2个生产者，3个kafka集群以及3个消费者和zookeeper集群。可以看到kafka集群中有3个broker，borker1和broker2有两个partition，broker3有一个partition。
图2中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。
如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。
这里放上了两个图分别从不同的角度对kafka的架构进行抽象，图1结合了zookeeper，而图2则细致的表现了replica。

术语阐述

broker

可以简单的理解为：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic；

• Kafka 集群包含一个或多个服务器，服务器节点称为broker。
• broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
• 如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
• 如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

topic

对于每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。也就是说，当我们生产者向kafka提交消息的时候，这时候需要其有一个tpoic，topic其实也方便了发布订阅模式，也就是说我们订阅消息，具体那一类消息是通过topic类确定的，至于物理上的分区的不同，从依据topic来pick消息的角度来说，在不同partition中相同topic的消息被选择消费的过程可以看作是用户透明的。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）。
这个可以理解对应理解为逻辑上是有关联的，但是物理存储存储上不一定是有关联的，这个可以对比我们的内存分配，当代操作系统不也存在逻辑地址和物理地址的一个映射吗，在我们处理程序的逻辑的时候，其实是操作的逻辑地址。只不过在kafka中，仅仅保持了每个partition内是有序的。多个partition之间的顺序不保证。同时也可以理解为在大型时的业务应用中的分库分表后的情形，多个数据库中有同一表名的表，但是内容组合后才是全部的内容，对此在我们查询选择某个记录可能分配在不同的数据库的同名的表中。总之一句话：在使用topic选择消息时，逻辑上是有联系的，但顺序的保证仅在partition内。

对于topic来说，Topic在逻辑上可以被认为是一个queue，这个也适用于其他的消息队列，如ActiveMQ，RabbitMQ等。每条消费都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。
为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。
创建一个topic时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中。
因为每条消息都被append到该Partition中，属于顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）。

Partition

topic中的数据分割为一个或多个partition。每个topic至少有一个partition。partition的数量则可以依据用户的配置。partition的数量也会影响集群的可用性。这个将会在后面的章节中讲到。对于在实际每个进入partition中的数据则会使用多个segment文件存储。本质上，文件的存储也会有大小，同时也会有过期策略，可以根据时间也可以根据文件的大小选择对应的删除策略。
其次，partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略删除旧数据。
删除策略：一是基于时间，二是基于Partition文件大小。例如可以通过配置$KAFKA_HOME/config/server.properties，让Kafka删除一周前的数据，也可在Partition文件超过1GB时删除旧数据，配置如下所示：

# The minimum age of a log file to be eligible for deletion
log.retention.hours=168
# The maximum size of a log segment file. When this size is reached a new log segment will be created.
log.segment.bytes=1073741824
# The interval at which log segments are checked to see if they can be deleted according to the retention policies
log.retention.check.interval.ms=300000
# If log.cleaner.enable=true is set the cleaner will be enabled and individual logs can then be marked for log compaction.
log.cleaner.enable=false
1
2
3
4
5
6
7
8

针对设计目标中O(1)持久化消息能力的解释

Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高Kafka性能无关。选择怎样的删除策略只与磁盘以及具体的需求有关。
此外，Kafka会为每一个Consumer Group保留一些metadata信息——当前消费的消息的position，也即offset。这个offset由Consumer控制。正常情况下Consumer会在消费完一条消息后递增该offset。当然，Consumer也可将offset设成一个较小的值，重新消费一些消息。因为offet由Consumer控制，所以Kafka broker是无状态的，它不需要标记哪些消息被哪些消费过，也不需要通过broker去保证同一个Consumer Group只有一个Consumer能消费某一条消息，因此也就不需要锁机制，这也为Kafka的高吞吐率提供了有力保障。

Producer

如果把kafka卡做一个消息队列，则可以将其和ACtiveMQ、RabbitMQ等消息队列做个比较，比较中可以发现有些概念是相近的，例如这里的producer。本质上其代表的含义是相似的，都是消息的生产者。
生产者即数据的发布者，该角色将消息发布到Kafka的topic中。其实在例如ActiveMQ中也会有topic的概念。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

Producer发送消息到broker时，会根据Paritition机制选择将其存储到哪一个Partition。如果Partition机制设置合理，所有消息可以均匀分布到不同的Partition里，这样就实现了负载均衡。
如果一个Topic对应一个文件，那这个文件所在的机器I/O将会成为这个Topic的性能瓶颈，而有了Partition后，则可以改变消息持久化的策略，不再串行进入，而是可以将不同的消息并行写入不同broker的不同Partition里，极大的提高了吞吐率。
可以在$KAFKA_HOME/config/server.properties中通过配置项num.partitions来指定新建Topic的默认Partition数量，也可在创建Topic时通过参数指定，同时也可以在Topic创建之后通过Kafka提供的工具修改。

注意key的功能

在发送一条消息时，可以指定这条消息的key，Producer根据这个key和Partition机制来判断应该将这条消息发送到哪个Parition。Paritition机制可以通过指定Producer的paritition. class这一参数来指定，该class必须实现kafka.producer.Partitioner接口。

Consumer/Consumer Group

消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。不同的分配方式则可以实现不同的消息的传递形式：

这是Kafka用来实现一个Topic消息的广播（发给所有的Consumer）和单播（发给某一个Consumer）的手段。一个Topic可以对应多个Consumer Group。如果需要实现广播，只要每个Consumer有一个独立的Group就可以了。要实现单播只要所有的Consumer在同一个Group里。用Consumer Group还可以将Consumer进行自由的分组而不需要多次发送消息到不同的Topic。
实际上，Kafka的设计理念之一就是同时提供离线处理和实时处理。根据这一特性，可以使用Storm这种实时流处理系统对消息进行实时在线处理，同时使用Hadoop这种批处理系统进行离线处理，还可以同时将数据实时备份到另一个数据中心，只需要保证这三个操作所使用的Consumer属于不同的Consumer Group即可。

Leader/fllower

1. 每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
2. Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。
   如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

与其他MQ的比较

RabbitMQ、ZeroMQ、ActiveMQ

RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。

ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。