Kafka是由Apache软件基金会开发的一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作已经成为现代网络上的许多社会功能的一个关键因素。为了让大家进一步了解kafka,飞马网于5月29日晚，邀请到游戏公司资深大数据SRE工程师，数据中心基础服务负责人刘镇砚老师为大家分享该领域的内容。
以下是这次线上直播的分享实录：
今天分享的主要分为四个内容：第一部分是kafka基础，包括为什么需要分布式消息队列系统，kafka相关概念与基础原理；第二部分主要是程序常用的设计方法，一些需要注意的地方；第三部分介绍典型的应用场景，方便大家以后上线业务的时候作为参考；第四部分是总结。
一、Kafka基础
在介绍Kafka基础之前，先介绍一些经常遇到的业务场景，比如说线上有许多生产服务器，这些服务器都运行着不一样的服务，如web系统，还有各种管理的平台，还有APP的系统，如何对每个服务产生的大量日志和消息进行处理和分析是值得考虑的问题。
首先，可以看一下传统的处理方法，如图，线上有许多业务的前端，都需要将业务产生的线上日志和消息分到后端的业务分析平台，比如说web系统的负责人，他实现了多套系统的的技术方案，然后把数据分别传送到Hadoop集群还有监控系统等等。一个APP系统，它需要走同样的流程，就能发现我们的产品一直在做实现分析对接这样的一个事情，带来的问题也很明显，比如说我们的数据流程太过复杂，对于产品部门来说，他们重复实现数据的一个收集还要考虑框架的一系列复杂的场景。而且这个复杂的场景完全是用于给用户老实现，所以这个用户体验就比较差。
基于上述，我们就可以得出我们需要引入一个消息的中间件，对于这个中间件而已，他屏蔽了用户与客户端分析平台的直接交互，对于用户来说，他们只要考虑如何将这个数据分发到这个数据中间件就可以了，后面的操作我们会统一在后面的环节来进行处理。
回到刚才的问题，我们为何要引入消息队列。我们就要看下它给我们带来的一些好处：
1、解耦：需求是变化的，比如说，我们会有不同的产品都需要接入分析平台，另一个就是说我们分析平台自身也需要不断就调整我们的技术框架。
1、冗余：在我们线上的生产环境当中，机器故障几乎是不可避免的，如何去避免数据丢失是我们主要考虑的一个方向。
2、扩展性：消息解耦扩大了我们，所以我们增大消息入队速度和处理频率都是非常容易去实现的，增加额外的处理过程就可以，不需要改变代码。
3、灵活性与峰值处理能力：消息队列是一个分布式的架构，比较容易横向扩展
，满足业务的线上的一个压力。
如果把我们的消息队列换成我们的Kafka组件，那对于我们的整个系统来说，进入kafka页面，我们的业务前端是可以多种多样的，比如说一个web系统或者是游戏的一个服务器或者是一个管理平台的后端，同样的在kafak以后，我们后端的一个组件也要比较灵活，比如我们的监控平台、APP系统等。
Kafka介绍：
首先，kafka是一个Linkedln开源的分布式发布-订阅消息系统，数据发布到kafka的集群当中，用户可以集群的订阅这些消息并及时处理，kafka有以下的特点：
1、高吞吐率，低延迟：可以每秒处理几十万条消息，但延迟最低几毫秒
2、可扩展性：支持动态扩展节点
3、持久性与可靠性：数据被持久化到磁盘上，并且能支持多个副本并防止数据丢失。
4、高容错：某些节点失败后不会影响整个执行，允许节点失败
5、高并发：支持上千个客户端同时读写
Kafak架构图
1、生产者producer:
生产者可以向broker发送消息，然后一般会批量发送多条消息，另外它会通过一个任意一个broker去发现其他broker的位置信息。比如说对应的topic和所在的partition。消息组成的话，会有以下几个部分，第一个是topic，每条发送到kafka集群的消息都是有一个类别的，这个类别就被称之为topic，物理上这个topic 的消息分开存储，存在一个或者多个broker，但用户只需指定消费，而不需要关注数据储存在何处;第二是key，在发送一条消息的时候，我们会指定key,根据这个key，也就是partition来将这条消息发送到哪条partition；第三个部分是value，是我们发送信息的一个主体；最后是timestamp的一个参数，它允许producer去指定时间，如果不指定的话就默认当前时间。
2、节点broker:
是producer和consumer的一个中间桥梁，从producer端去接收消息并保存下来，并且把消息发送给订阅的consumer，另外的话，他可以将消息可靠的缓存一段时间，比如说我们每个消息都可以保存为多个副本，默认是3个，另外我们可以设置保存时间，比如一周，一周过后，这个数据就会从本地磁盘上面删除。
然后看producer是如何生产数据到broker上的，首先producer调用了一个线的方法，并且指定了topic、value的参数，然后经过partition的一个处理，然后确定把数据写到对应的kafka集群的partition之中，然后数据是按顺序的方式写入的。
Partition和topic的关系：topic在逻辑上就可以认为是一个cue,每条消费都必须指定它的topic，简单理解为我们必须指定把这条消息放到哪个cue里面，而partition则是物理上的概念，每个topic包含一条或者多条partition，为了将kafka的吞吐量可以先行的提高，物理上可能把topic分成一个活多个partition，每个partition在物理上对应一个文件夹，然后该文件夹为存储该partition的所有消息与所应文件。Partition是横向扩展和一切并行化的基础，每个topic至少被切成一个partition，消息在partition中是有编号的，称为offset，kafka以partition为单位对消息进行备份，每个partition可以至少有一个replic（副本）。
3、消费者consumer：
它的基本职责就是用户应用程序，负责从kafka中读取数据，并进行处理，另外它有一个重要的概念，就是consumer group，多个consumer可以组成一个逻辑group，然后同时去读取某个topic，然后每个consumer都可以读取一个或多个partition。对于同一个topic来说，我们可以取多个consumer group分别去订阅他的消息，用于不同的作用。还有一个概念就是consumer position，每个consumer可以自己维护读取的位置offset，一旦挂掉后，重启后可继续读取，
4、协调组件zookeeper
接下来介绍kafka的其他一些特点：
服务保证的特性：
顺序保证（同一个producer发送到某个topic的同一个partition中的消息是顺序的，consumer按照消息在日志中的写入顺序读取消息）顺序写顺序读
Producer产生的数据由consumer消费
容错性：我们的数据是有副本的话，那我们能永远n-1台机器宕掉后不会导致数据丢失，因为我们还有最后的一个数据节点来保证数据的可用性
Kafka应用场景：
监控场景，监控message的变化指标
消息队列，用于我们消息的一个缓存
用户活动追踪
流处理
日志聚合
二、kafka程序设计
kafaka程序设计方法：
内核实现语言是Scala，推荐程序设计语言是Java，当然其他语言也是可以的，比如c/c++，php，python等，但是遇到一些比较高级的功能的时候，比如我们的kafka集群是经过Kerberos认证的，数据要基于压缩格式，那么对应的支持可能没有那么完善。
程序设计流程
1.kafak在整个数据流中的角色
2.producer设计（考虑partition、数据格式等）
考虑点：基本需求（有哪些topic、如何对消息进行分区、消息数据格式-字符串，json，protobuf）
具体实现：（同步或是异步、是否是批发送、单线程还是多线程）
案例：
初始化配置对象，创建producer；
创建消息并发送，默认是异步发送；同步发送比较少用，效率低
重要参数：
Bootstrap.servers（用作初始化broker列表，指定一个或多个，多个需分割）
Key和value序列化器
Acks
Buffer.memory（存满自动发送到broker）
Compression.type（指定数据压缩方式，默认不压缩，如果选择压缩，除了可以节省broker节点存储外还可以节省数据的传输的网络带宽，但是代价是额外消耗CPU）
Max.request.size/batch.size（指定batch数据量大小）
Client.id(唯一标示，默认为空)
Partitioner.class（默认是轮询的方式）
3.consumer设计（取决于应用需求）
考虑点：
基本需求（需要处理哪个topic中的数据，如何处理这些topic）
具体实现（是否启动多个consumer，形成一个group；是否是批处理；单线程还是多线程）
程序示例
初始化并创建kafka consumer
读取数据
重要参数
Bootstrap（引导程序）.servers（初始化broker自动列表）
Key.deserializer(并行器)/value.deserializer（反序列化器）
Fetch.min.bytes（每次请求至少返回的数据大小，默认1k）
Group.id(重要概念)
Session.timeout.ms（超时，移除）
Enable.auto.commit（是否自动提交offset，默认自动，多久自动提交）
相关程序说明：
1、如果某个topic的分区数小于接收线程数，则部分线程空闲
2、如果topic的分区数大于接收线程，则部分接收线程会同时读取多个分区中的数据
3、同一个线程收到的数据可能来自多个partition，不保证数据的顺序性
对于同一个consumer group来说，partition同时只能给一个consumer来消费，说明partition的数据只能被一个consumer来消费。
三、kafka应用场景
1、在线与离线的一个连接件
实时的数据中心：主要是对于实时数据的一个分析或者监控系统的一些业务，对于数据的延迟是有比较高的要求
离线数据中心：是对于离线数据的计算，每天固定的指标，对数据的延迟要求相对没有那么高，但是读取的数据量会相对较大。
（不会互相受影响）
2、跨数据中心的数据备份与集成
基于业务和机房物理性质来划分多个kafka业务集群，基于数据备份和聚合的需求，会部署一个汇总的kafka集群，然后把数据都同步到这里，然后统一的消费分析和处理。，比如说可以把两个不同集群的业流攥起来统一做分析
3、实时计算
常用的话是在数据源端来部署我们的一个数据ession，常用的一般是……或者自定义实现的一些生产者，如果是……，我们会使用kafka，然后把数据发布到kafka集群，对应的话，实时计算这部分。
四、总结
基础介绍、程序设计介绍、应用场景介绍
这四大部分就是关于kafka的介绍。下面我们一起来看看在最后的答疑过程中，都有些什么问题呢？
1、最大的区别是什么？
刘老师：区别是比较多的， 比如架构、协议、吞吐量对我们业务来说 更看重的是大数据的一个处理能力以及跟分析框架的兼容性
刘老师：不是很了解微信内部的情况 因为业务部门比较多 但是kafka的场景一定会有的
3、问producer可以多线程吗？
刘老师:可以的。每次发送数据都是一个独立的过程，数据会自动分区到不同的partiton去，同样也可以使用多个客户端来发送数据。
4、问kafka可以发布多大数据？
刘老师：需要看你kafka集群的配置，几百M都是没有问题的，但主要用途还是消息数据为主，大数据体的话效率是很慢的，数据在集群内还要做备份。
5、问请问在现在mq种类繁多的情况下，通过哪些指标来衡量是否适合自己的应用场景。谢谢。
刘老师：我们主要是考虑大数据的业务场景以及与实时计算框架的融合，比如说storm spark flink等。另外，还要考虑集群的管理。
6、请问老师你们项目中消息模快流程是怎样？
刘老师我们回去埋点收集数据,然后通过代理层来接受数据,屏蔽用户直接访问kafka 后续就是数据分发到各种业务平台了。
7、请问老师,broke是不是可以对应实际中的一台服务器,多个broke就可以组成了一个kafka集群吗?
刘老师：broker就是我们的kafka节点 一般一个服务器部署一个就够了 因为kafka对磁盘io以及网络带款要求还挺高的
8、业务层直接推到Kafka呢还是先推到中间表，再定时扫描中间表推到Kafka？
刘老师:都可以 看你业务的需求 就看你是分布式推送还是先聚合再推送了。
9、我们最近就用到了kafka,我们是负责收集各个业务系统的处理数据,他们把处理数据发送给我们,我们把数据汇总后再发送给集团的kafka.？
刘老师:这样处理也是可以的，如果后续需要做实时分析就不行了。
10、分布式推送和先聚合再推送的优缺点是什么呢？
刘老师:感觉可以考虑数据量的大小，数据量大的话，先聚合处理效率很快就会有性能瓶颈。另外一方面，埋点多少的问题。
11、老师,下次直播能直接视频吗?就是可以直接看到分享桌面,类似于直播,这样总觉得不太适应!
刘老师:今天第一次分，以后可以考虑一下，谢谢支持。
以上就是本次线上直播的主要内容，相信你对kafka有了一定的认识。想了解更多更详细内容的小伙伴们，可以关注服务号：FMI飞马网，点击菜单栏飞马直播，即可进行学习。
閱讀更多 飛馬網FMI 的文章
