本篇内容主要讲解“卡夫卡的设计原理及性能应用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“卡夫卡的设计原理及性能应用”吧!
前言
达观数据作为一家提供大数据服务的公司，经常会遇到客户上报数据的需求。这样的请求不需要马上返回处理结果， 而是需要后台将一系列的上报数据进行统一归档整理挖掘， 然后将结果数据呈现给客户。这样的业务需求需要达观提供数据暂存服务，也就是说我们需要一个系统在生产者（客户上报数据）和消费者（后台数据处理）之间进行沟通，简而言之叫系统间通信消息系统，这种模型就是经典的生产者（producer）、消费者（consumer）模型。
然而有一个消息系统正好是为了应对这种业务场景而生，它就是kafka。那么kafka到底是一个什么样的系统？有什么特点？实际吞吐表现又如何？带着这些问题，我们一起来了解一下。
一, Kafka简介
首先根据官网介绍，知道kafka是一个分布式流处理平台，一个可处理企业级发布/订阅的消息系统，并且具有高容错性和消费及时性等特点，那么它是怎么做到这一点的呢？接着往下看。
1，主题和日志：
主题(topic)和日志(log)设置是kafka一大特色，一个kafka集群可以创建多个topic， 每个topic都相当于一个消息队列，这就意味着可以将不同格式的数据发布到不同的topic中，减小消费这些数据时的逻辑难度。那么每个topic中处理的数据结构是怎样呢？我们先来看一张topic的解剖图:
图1：topic原理解析图
从图1中可以看到， 消息传送过来时kafka会通过负载均衡将消息最终写入到磁盘上一个特定分区（partition）。由于在同一个partition上这些消息都是顺序存储的， 所以对一个特定分区每条消息都会有一个基于起始位置的偏移量（offset）， 因此我们在后续消费时只需要指明从哪个partition中哪个offset开始消费，就能达到重复消费目的。
1）虽然kafka可以通过增加partition方式来增加负载，但是它的数据最终是被写入到磁盘中。比如机械磁盘写入效率是很低的， 难道我们需要增大一个topic的负载给它设置更多的partition吗？
机械磁盘驱动器吞吐量跟寻道延时是强关联，也就是说，线性读写速度远大于随机读写。例如，在67200rpm SATA RAID-5磁盘阵列中， 随机写速度大约是100k/s, 然而线性写速度可以达到600M/s，后者大约是前者的6000倍。通过图1可知， kafka采用的即是后者, 利用操作系统read-ahead和write-behind技术，极大提升磁盘访问性能；设置partition数量固然可以从磁盘读写角度增大topic负载，但是partition数量过多会导致cpu计算量增大，所以***办法是根据不同配置的机器， 不同的业务场景设置不同的partition数量。
2）偏移量offset存储类型是什么， 如果消息足够大，offset的值是否会重新置0， 如果置0，后续消费是否会紊乱？
kafka offset 是一个日志序列号（ log sequence number），不必担心offset 长度问题。那么这个日志序列号到底有多大，举个例子：如果一个partition一天接收1T日志， 这个offset至少可以使用1百万年。由于offset足够用，而且不会被置0，所以从这个角度讲消费紊乱情况是不会出现的。
3）写入磁盘的日志会被***保留吗？如果想删除过期消息， 需要怎么操作？
可以通过配置文件中log.retention参数设置消息过期时间，超过过期时间的消息会被系统删除，删除的消息不可再被重新消费。
2，分布式集群
通过前文介绍我们已经了解到kafka通过partition和顺序读写磁盘的方式达到很高吞吐量，可是单台机器吞吐量再高一旦该机发生故障宕掉就会对业务产生灾难性影响，怎么处理这个问题呢？想必你已经知道了，那就是采用集群的方式，一旦一台机器发生故障客户端可以选择链接其它机器， 保证业务稳定性。每一个partition 都会有一个服务器来作为***（leader）， 另外一个或者多个服务器（server）来作为跟随者（follower），leader会处理所有的读写请求，而follower则会从leader那里备份数据， 如果一个leader失败了， 其它的follower会自动选举一个成为一个新的leader， 所以对于一个server来说，他可能是某些partition下的leader， 而对于另外一些partition来说则是follower,这样设计可以将负载更好均衡。
