kafka深入研究之路(2) kafka简介与专业术语解释说明

目录：
1、kafka简介 什么是kafka？ 设计目标是什么？
2、kafka的优缺点
3、kafka中专业术语解释说明

官方网站： http://kafka.apache.org/intro
kafka中文教程 http://orchome.com/kafka/index

1/ kafka 简介
Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。//发展近十年的项目 目前很成熟了

主要应用场景是：日志收集系统和消息系统。

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

Kafka就是一种发布-订阅模式 在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。 // 发布者发送到topic的消息，只有订阅了topic的订阅者才会收到消息。

为什么要使用kafka？
1、作为缓存
2、解（系统）耦合
3、时间小于10ms 基本上是一种实时的
他能简化，我们系统的设计，提示公司的开发速度，和效率

2/kafka优点
1、解耦
//S 系统与 A、B、C 系统紧密耦合。由于需求变动，A 系统修改了相关代码，S 系统也需要调整 A 相关的代码。 过几天，C 系统需要删除，S 紧跟着删除 C 相关代码；又过了几天，需要新增 D 系统，S 系统又要添加与 D 相关的代码；再过几天，程序猿疯了 这样各个系统紧密耦合，不利于维护，也不利于扩展。现在引入 MQ，A 系统变动，A 自己修改自己的代码即可；C 系统删除，直接取消订阅；D 系统新增，订阅相关消息即可。这样通过引入消息中间件，使各个系统都与 MQ 交互，从而避免它们之间的错综复杂的调用关系。
2、冗余（副本）
//有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3、扩展性
//因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
4、灵活性&峰值处理能力(削峰)
//数据库的处理能力是有限的，在峰值期，过多的请求落到后台，一旦超过系统的处理能力，可能会使系统挂掉。 系统的处理能力是 2k/s，MQ 处理能力是 8k/s，峰值请求 5k/s，MQ 的处理能力远远大于数据库，在高峰期，请求可以先积压在 MQ 中，系统可以根据自身的处理能力以 2k/s 的速度消费这些请求。这样等高峰期一过，请求可能只有 100/s，系统可以很快的消费掉积压在 MQ 中的请求。
5、可恢复性
//系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6、顺序保证
//在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。
7、缓冲
//在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。 在用户请求和数据库之间 MQ起到很大到缓冲作用 在削峰上有很大到体现
8、异步通信
//很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

优点小结：
1、单机吞吐量：
10万级别，这是kafka最大的优势，就是他的吞吐量高，一般配合大数据类的系统来进行实施数据计算，日志采集等场景
2、topic数据对吞吐量的影响：
topic从几十个到上百个不等，但是topic越多，会很大程度的影响吞吐量，所以在同等机器下，kafka经量保证topic数量不要过度。如果要支撑大规模的topic的话，需要增加更多的集群资源。
3、时效性：
延迟控制在ms以内
4、可用性：
非常高，kafka是分布是的，一个数据多个副本，少数机器的宕机，不会丢数据，不会导致不可用
5、消息可靠性
经过参数优化配置，消息可以做到0丢失
6、功能支持
功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准

优劣势总结
kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供较高的吞吐量，ms级别的延迟，较高的可用性以及可靠性，而且是分布式的，可以任意的扩展，同时kafka也是做好的是支撑少量的topic数量即可，保证其吞吐量，而且kafka唯一的一点劣势就是可能出现就消息的重复消费(为什么会出现消息到重复消费，见后期博客内容)，那么对数据准确性会产生影响，在大数据领域中以及日志收集中，这点轻微可以忽略。 kafka的特性就是天然适合大数据实时计算以及日志的收集。

3/kafka中专业术语解释说明(相关概念)
在深入理解kafka之前，有必要先了解和弄懂kafka中会出现到的相关术语概念：
1、Broker：Kafka 集群中包含的服务器。
//一个安装kafka的服务器节点 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集群数据不均衡。
比如我们有5个broker节点 那么尽量创建的topic的partition分区个数为5的倍数 10 20 30... 50都可以 这样可以让kafka的数据均匀分布

2、Producer：消息生产者。
//生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

3、Consumer：消息消费者。
//消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

4、Consumer Group：每个 Consumer 都属于一个 Consumer Group，每条消息只能被 Consumer Group 中的一个 Consumer 消费，但可以被多个 Consumer Group 消费。
//每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

5、Topic：消息的类别。每条消息都属于某个 Topic，不同的 Topic 之间是相互独立的，即 Kafka 是面向 Topic 的。
//每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处） 类似于数据库的表名

6、Partition：每个 Topic 分为多个 Partition，Partition 是 Kafka 分配的单位。Kafka 物理上的概念，相当于一个目录，目录下的日志文件构成这个 Partition。
//topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

7、Replica：Partition 的副本，保障 Partition 的高可用。
//每个topic将被分成多个partition(区),此外kafka还可以配置partitions需要备份的个数(replicas)

8、Leader：Replica 中的一个角色， Producer 和 Consumer 只跟 Leader 交互。
//每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

9、Follower：Replica 中的一个角色，从 Leader 中复制数据。
//Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个server为"leader";leader负责所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follower只是单调的和leader跟进,同步消息即可..由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个"leader",kafka会将"leader"均衡的分散在每个实例上,来确保整体的性能稳定.
其中partition leader的位置(host:port)注册在zookeeper中

10、Controller（调节器）：Kafka 集群中的其中一个服务器，用来进行 Leader Election（leader 选举） 以及各种 Failover（故障转移）。
//Controller（调节器） 节点都分片在 zk中记载 在哪个broker节点上 以及 controller 创建的时间 //查看方式 get /kafkagroup/controller

11、Zookeeper：Kafka 通过 Zookeeper 来存储集群的 Meta 信息。(问题：kafka的哪些元数据信息在zk中，见后期博客)

12、Coordinator：类似 Broker 中选了一个 Controller 出来，消费也要从 Broker 中选一个 Coordinator，用于分配 Partition。

————————————————————————————————————————————————————————————————————————————————————————————————————————————————
参考链接：
kafka基本原理重要概念优缺点 https://blog.51cto.com/12445535/2353399
架构成长之路：Kafka设计原理看了又忘，忘了又看？一文让你掌握 https://www.toutiao.com/i6714606866355192328/
Kafka学习之路 （一）Kafka的简介 https://www.cnblogs.com/qingyunzong/p/9004509.html
消息队列kafka特性 https://blog.csdn.net/qq_36236890/article/details/81174504