浅谈开源Kafka与腾讯云cKafka

今天下午参加了腾讯云+社区组织的kafka公开课，收获良多。正巧在工作中也遇到过kafka的问题，今天听完之后产生了非常多的感想。无奈篇幅有限，本人又文笔愚钝，所以今天的分享主要提及对我感触最深的内容。分享的顺序还是按照老形式来进行吧（提出疑问——解决疑问）

【提出疑问】

1、为什么要设计kafka？

2、开源的kafka架构是怎么样的？

3、腾讯云的ckafka架构是怎样的？

4、腾讯云的ckafka架构解决了什么样的问题？

5、我对开源kafka的设想？

一、为什么要设计kafka？

扩容性

过去生产消费模型采用的消息队列一般为RabbitMQ、ZeroMQ（最快）等。这些消息队列对于数据的处理量存在一个上限，也就是说随着信息化的数据爆炸式增长会出现一个吞吐量的瓶颈。下图是我在网上找的图，表示的是以往消息队列的形式。过去MQ的瓶颈存在的原因在于这个队列不能很好的支持扩容。举个通俗点的例子来说过去的MQ是一条乡间小路，路的大小是事先设计好的。而kafka则是一条高速公路，且这条高速公路可以根据业务的需求进行扩展（流量大时采用5车道，闲时采用2车道）。因此这同时也是一种非常节约资源的解决方案。

统一处理

上图表示的是以前的处理方式。举个案例来说，现在公司里有两个数据源（oracle和mysql），我需要给每个业务都定义一个使用数据库的接口。然而随着公司业务的不断扩展，数据源的种类越来越多，添加了诸如redis等，同时业务的变更也扩展地非常快。这时如果对每个业务都编写一个接口就会显得非常麻烦。kafka则可以很好的应对上述场景，这也是基于避免重复造轮子的思想。

上图是简单的kafka架构。kafka的开源版本里提供了很多数据源的接口，业务只需要对kafka集群进行连接就可以实现对数据的抓取。与此同时，kafka集群还可以进行对数据的筛选。也就是后面会提到的日志存储。

二、开源的kafka架构是怎么样的？

Broker

Kafka集群包含一个或多个服务器，这种服务器被称为broker

Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

Partition

Parition是物理上的概念，每个Topic包含一个或多个Partition.

Producer

负责发布消息到Kafka broker

Consumer

消息消费者，向Kafka broker读取消息的客户端。

Consumer Group

每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

topic&partition理解

每个topic都可以看成是一个队列，消费必须指定它的topic。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。

日志存储

开源kafka的日志存储可以实现数据解耦、多消费者读取等功能。如下图所示

对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略删除旧数据。一是基于时间，二是基于Partition文件大小。

为了提高Kafka的容错能力，需要将同一个Partition的Replica尽量分散到不同的机器。如果某个Broker宕机了，需要保证它上面的负载可以被均匀的分配到其它幸存的所有Broker上。此外，还涉及了投票选举机制。也就是说当一个leader挂了之后会投票选出一个新leader。（具体机制改天再整理出个详细的文档）。

开源的kafka架构是将各个topic冗余备份分步到各个broker上，当一个broker挂了之后能够很快的根据备份信息恢复。