八月份第一课,云小通小课堂继续开课咯,这次技术部小伙伴给大家讲的是云通使用的kafka,对于绝大部分程序员来说,kafka这一名词/概念还是比较陌生的,因此下文将从kafka定义、作用、特性描述、核心概念以及云通是如果使用的这五个方面对kafka加以介绍。
kafka定义
Kafka是由Apache软件基金会开发的一个开源流处理平台,其编写语言为Scala和Java。有人将其描述为一种高吞吐量的分布式订阅消息系统。
Kafka作用
Kafka作为MQ(消息队列)的一种,在以下几个领域都有应用到:
1、网站活动追踪:Kafka诞生的初衷就是为了做网站和用户的活动追踪,并将其发布到不同的话题中心(就是下文会提到的Topic)
2、指标:Kafka也可以用来做数据监测,将各种应用程序(通常是分布式的)所生成的数据集中统计。
3、日志聚合:类似于上面的指标,本质上也是对于分布式程序的聚合,但是这里聚合的是日志而非数据。
4、流处理:由于Kafka中的消息处理一般都可分为多个阶段/多个分块,因此其天生就是一个完美的流处理工具。
Kafka特性
1、高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作;
2、可扩展性:kafka集群支持热扩展;
3、持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失;
4、容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败);
5、高并发:支持数千个客户端同时读写.
Kafka核心概念
在这一段中需要介绍的就是六个概念:
1、broker:kafka集群包含一个或者多个服务器,服务器就称作broker;
2、producer:负责发布消息到broker;
3、Consumer group:消费者,从broker获取消息一个consumer group通常由多个consumer组成;
4、topic:发布到kafka集群的消息类别;
5、partition:每个topic划分为多个partition;
6、Offset:记录每一个partition-group对的消息偏移量。
理解这一段可能需要读者有一定的生产者消费者模式以及MQ(消息队列)的基础知识。如果不知道的可以自行了解一下,所谓生产者消费者模式,即N个线程进行生产,同时N个线程进行消费,两种角色通过内存缓冲区进行通信;消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。目前在生产环境,使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。
其中produce和cosumer其实就对应生产者消费者模式中的生产者和消费者,而topic、partition及broker则对应中间媒介,用一张图来说明会比较直观:
![6076944c850271dc9504fca6c043a71d.png](https://i-blog.csdnimg.cn/blog_migrate/8bccc644da6b826f1eca5c53a45871a1.jpeg)
其中group对应的就是comsumer group,一个group下可以有很多个不同的consumer,例如GROUP D下就有C0,C1,C2,C3四个consumer。
Partition和topic应该是两个捆绑起来的概念,一个topic可以有好几个partition(就像一个group下可以有很多个consumer一样)。图中的P0,PI,P2就对应三个partition,他们合起来就是一个topic(这里我们暂定为topic的名字为A)。producer发送的所有消息必须指定topic,但是不需要指定具体的partition,因为kafka会对所有接收到的消息进行自动平衡。
不难注意到图中ABCD四个GROUP分别有1-4个消费者,从图中的连线也不难看出Partition和consumer之间是有关系的。
根据consumer和partition的数量可以分成三种情况,如果一个consumer group里面consumer的数量小于topic里面partition的数量,就会有consumer同时处理多个partition(这个是kafka自动的机制,我们不用指定,就像Group A中的C0处理所有的PO,P1,P2的数据,而图中Group B中的C0则处理P0,P1的数据,C1处理P2的数据)。
如果一个consumer group里面consumer的数量等于topic里面partition的数量,那这样这样效率是最高的,因为这样一个consumer 就处理一个partition,就像图中group C中的C0处理P0的数据,C1处理P1的数据,C2处理C2的数据。
如果一个consumer group里面consumer的数量大于topic里面partition的数量,多出的consume就会闲着啥也不干,剩下的是一个consumer 处理一个partition,这就造成了资源的浪费,因为一个partition不可能被同一group下的两个consumer去处理。就像图中的GROUP D中,只有C0,C1,C2能处理到消息,而C3则会闲置。
关于Offset,其实这也是kafka受到欢迎的主要原因之一,我们可以将他和其他消息队列中间媒介,比如redis做对比。Offset可以理解为一个自增id,标志着这个topic下当前处理到的位置,只有在完全处理完之后offset才会增加。这样有什么好处呢?让我们来做一个假设,如果consumer设置的是一次处理1K条数据,运气不好,在处理第一条的时候服务器就挂了,如果使用的是redis,那很不幸地告诉你,这1K条数据就不见了。这时kafka的好处就体现出来了,如果这1K条没有全部处理成功,consumer是不会发送offset+1K的指令的,这样哪怕服务器挂了也不会出现数据消失不见的情况,可谓是运维的福音。
Kafka在云通中的使用
云通技术部主要将其应用于数据库的数据同步及同步删、私募公募基金指标实时运算等。下面也用一张图来帮助理解。
![3dc0d1e46e8093dae8737453749e0eaa.png](https://i-blog.csdnimg.cn/blog_migrate/6e1e766d692c876e271b7cc4fecfcea9.jpeg)
图中所有的“触发”都是生产者生产的步骤,生产者通过事先存在redis中的update_time(该update_time代表了该表目前已经处理完的所有数据中的最大更新时间)。下面做一个实例假设:
我们假设redis中的key值为fund_nv_date_standard对应的update_time为2020年8月3日 10:03:30。通过一句sql语句:
“select update_time, count(*) as count from fund_nv_data_standardwhere update_time > '2020-08-03 10:03:30' group by update_time order byupdate_time”
![eb15f98e4843c3eef49c00445fa11b29.png](https://i-blog.csdnimg.cn/blog_migrate/60369cc363d119093ea51f57b07fd53b.jpeg)
统计出所有在2020年8月3日 10:03:30之后所有更新的数据,随后2W条数据为一批,分批写入kafka队列中。在所有数据全部写完后将redis中的update_time更新到目前最新,即'2020-08-03 10:32:51'。一次生产任务就完成了。
小结
作为一种功能强大的MQ实现,Kafka在市面上的运用越来越广,腾讯云也成立了专门的Kafka服务ckafka消息订阅服务,可以大胆预测kafka在未来一段时间内会成为主流技术之一。各位程序猿小伙伴可以深入了解掌握一下这一技术,走在时代的前沿。欢迎和云通数科技术部小伙伴一起探讨
![26be4021f1b40562cc56f14752c39086.png](https://i-blog.csdnimg.cn/blog_migrate/9e3aae3206acc24ec6ff68d6920857d8.jpeg)