在分布式系统领域，有一个理论，对于分布式系统的设计影响非常大，那就是 CAP 理论，即对于一个分布式系统而言，它是无法同时满足 Consistency(强一致性)、Availability(可用性) 和 Partition tolerance(分区容忍性) 这三个条件的，最多只能满足其中两个。但在实际中，由于网络环境是不可信的，所以分区容忍性几乎是必不可选的，设计者基本就是在一致性和可用性之间做选择，当然大部分情况下，大家都会选择牺牲一部分的一致性来保证可用性（可用性较差的系统非常影响用户体验的，但是对另一些场景，比如支付场景，强一致性是必须要满足）。但是分布式系统又无法彻底放弃一致性（Consistency），如果真的放弃一致性，那么就说明这个系统中的数据根本不可信，数据也就没有意义，那么这个系统也就没有任何价值可言。
在 Java 并发编程实践或看涉及到 Java 并发相关的代码时，经常会遇到一些线程（比如做 metrics 统计的线程等）会通过 setDaemon() 方法设置将该线程的 daemon 变量设置为 True，也就是将这个线程设置为了守护线程(daemon thread)，那么什么是守护线程呢？或者说守护线程与非守护线程（普通线程）的区别在什么地方呢？这个就是本文主要讲述的内容。
前面7篇对 Kafka Controller 的内容做了相应的总结，Controller 这部分的总结算是暂时告一段落，本节会讲述 Kafka 源码分析系列中最后一节的内容，是关于 Server 端对不同类型请求处理的网络模型。在前面的文章中也讲述过几种不同类型的请求处理实现，如果还有印象，就会知道它们都是通过 KafkaApis 对象处理的，但是前面并没有详细讲述 Server 端是如何监听到相应的请求、请求是如何交给 KafkaApis 对象进行处理，以及处理后是如何返回给请求者（请求者可以是 client 也可以是 server），这些都属于 Server 的网络处理模型，也是本文讲述的主要内容。
本篇算是 Controller 部分的最后一篇，在前面讲述 ReplicaManager 时，留一个地方没有讲解，是关于 Broker 对 Controller 发送的 LeaderAndIsr 请求的处理，这个请求的处理实现会稍微复杂一些，本篇文章主要就是讲述 Kafka Server 是如何处理 LeaderAndIsr 请求的。
本篇主要讲述 Controller 向各个 Broker 发送请求的模型，算是对 Controller Channel Manager 部分的一个补充，在这篇文章中，将会看到 Controller 在处理 leader 切换、ShutDown 请求时如何向 Broker 发送相应的请求。
本篇接着讲述 Controller 的功能方面的内容，在 Kafka 中，一个 Topic 的新建、扩容或者删除都是由 Controller 来操作的，本篇文章也是主要聚焦在 Topic 的操作处理上（新建、扩容、删除），实际上 Topic 的创建在 Kafka 源码解析之 topic 创建过程（三） 中已经讲述过了，本篇与前面不同的是，本篇主要是从 Controller 角度来讲述，而且是把新建、扩容、删除这三个 Topic 级别的操作放在一起做一个总结。
本篇接着讲述 Controller 对于监听器的处理内容 —— Broker 节点上下线的处理流程。每台 Broker 在上线时，都会与 ZK 建立一个建立一个 session，并在 /brokers/ids 下注册一个节点，节点名字就是 broker id，这个节点是临时节点，该节点内部会有这个 Broker 的详细节点信息。Controller 会监听 /brokers/ids 这个路径下的所有子节点，如果有新的节点出现，那么就代表有新的 Broker 上线，如果有节点消失，就代表有 broker 下线，Controller 会进行相应的处理，Kafka 就是利用 ZK 的这种 watch 机制及临时节点的特性来完成集群 Broker 的上下线，本文将会深入讲解这一过程。
前面两篇关于 Controller 的内容分别讲述了 Controller 选举和启动，以及副本状态机和分区状态机的内容，从本文开始会详细讲述 Controller 的一些其他功能，主要是 Controller 的对不同类型监听器的处理，这部分预计分三篇左右的文章讲述。Controller 在初始化时，会利用 ZK 的 watch 机制注册很多不同类型的监听器，当监听的事件被触发时，Controller 就会触发相应的操作。
上篇讲述了 KafkaController 的启动流程，但是关于分区状态机和副本状态机的初始化并没有触及，分区状态机和副本状态机的内容将在本篇文章深入讲述。分区状态机记录着当前集群所有 Partition 的状态信息以及如何对 Partition 状态转移进行相应的处理；副本状态机则是记录着当前集群所有 Replica 的状态信息以及如何对 Replica 状态转变进行相应的处理。
从本篇文章开始，Kafka 源码解析就正式进入了 Controller 部分，Controller 作为 Kafka Server 端一个重要的组件，它的角色类似于其他分布式系统 Master 的角色，跟其他系统不一样的是，Kafka 集群的任何一台 Broker 都可以作为 Controller，但是在一个集群中同时只会有一个 Controller 是 alive 状态。Controller 在集群中负责的事务很多，比如：集群 meta 信息的一致性保证、Partition leader 的选举、broker 上下线等都是由 Controller 来具体负责。Controller 部分的内容还是比较多的，计划分5篇左右的文章讲述，本文先来看下 Controller 的简介、Controller 的选举、Controller 选举后服务的启动流程以及 Controller 的四种不同 leader 选举机制。分区状态机、副本副本状态机以及对各种 listener 的处理将在后续的文章中展开。
前面几篇文章讲述了 LogManager 的实现、Produce 请求、Fetch 请求的处理以及副本同步机制的实现，Kafka 存储层的主要内容基本上算是讲完了（还有几个小块的内容后面会结合 Controller 再详细介绍）。本篇文章以 ReplicaManager 类为入口，通过对 ReplicaManager 的详解，顺便再把 Kafka 存储层的内容做一个简单的总结。
在上篇文章中讲述了 Fetch 请求是如何处理的，其中包括来自副本同步的 Fetch 请求和 Consumer 的 Fetch 请求，副本同步是 Kafka 多副本机制（可靠性）实现的基础，它也是通过向 leader replica 发送 Fetch 请求来实现数据同步的。本篇文章我们就来看一下 Kafka 副本同步这块的内容，对于每个 broker 来说，它上面的 replica 对象，除了 leader 就是 follower，只要这台 broker 有 follower replica，broker 就会启动副本同步流程从 leader 同步数据，副本同步机制的实现是 Kafka Server 端非常重要的内容，在这篇文章中，主要会从以下几块来讲解：
上一篇讲述完 Kafka 如何处理 Produce 请求以及日志写操作之后，这篇文章开始讲述 Kafka 如何处理 Fetch 请求以及日志读操作。日志的读写操作是 Kafka 存储层最重要的内容，本文会以 Server 端处理 Fetch 请求的过程为入口，一步步深入到底层的 Log 实例部分。与 Produce 请求不一样的地方是，对于 Fetch 请求，是有两种不同的来源：consumer 和 follower，consumer 读取数据与副本同步数据都是通过向 leader 发送 Fetch 请求来实现的，在对这两种不同情况处理过程中，其底层的实现是统一的，只是实现方法的参数不同而已，在本文中会详细讲述对这两种不同情况的处理。
这部分想了很久应该怎么去写才能更容易让大家明白，本来是计划先把 Kafka 存储层 Log 这块的写操作处理流程先详细介绍一下，但是这块属于比较底层的部分，大家可能对于这部分在整个处理过程处在哪个位置并不是很清楚，所以还是准备以 Server 端如何处理 Producer Client 的 Produce 请求为入口。但是 Server 端的内容较多，本篇文章并不能全部涵盖，涉及到其他内容，在本篇文章暂时先不详细讲述，后面会再分析，本篇文章会以 Server 处理 produce 为主线，主要详细讲解 Kafka 存储层的内容。
上篇文章在介绍完 Kafka 的 GroupCoordinator 之后，下面开始介绍 Kafka 存储层的内容，也就是 Kafka Server 端 Log 部分的内容，Log 部分是 Kafka 比较底层的代码，日志的读写、分段、清理和管理都是在这一部分完成的，内容还是比较多的，会分为三篇左右的文章介绍，本篇先介绍最简单的部分，主要是日志的基本概念、日志管理、日志刷新和日志清理四部分（后两个其实也属于日志管理，为便于讲解，这里分开讲述），日志的读写和分段将在下一篇讲述。
在 Kafka 的存储层这部分代码时，看到了很多地方使用操作系统的共享内存机制，Kafka 中所有日志文件的索引都是使用了 mmap 做内存映射，mmap 这块刚好也是一个值得深入学习的知识点，于是就就深入地看了一下、做了一下总结，本文的内容主要来自《深入理解操作系统》第三版 9.8 存储器映射部分。
突然发现距离上一篇文章，已经过去两个多月了，有两个月没有写博客了，之前定的是年前把这个系列写完，现在看来只能往后拖了，后面估计还有五篇文章左右，尽量在春节前完成吧。继续之前的内容开始讲解，这篇文章，主要是想把 GroupCoordinator 的内容总结一下，也算是开始了 Kafka Server 端的讲解，Kafka 的 Server 端主要有三块内容：GroupCoordinator、Controller 和 ReplicaManager，其中，GroupCoordinator 的内容是与 Consumer 端紧密结合在一起的，有一部分内容在前面已经断断续续介绍过，这里会做一个总结。
今天是第三次刷《肖生克的救赎》，记得第一次看的时候应该是在大学，具体是哪一年级，已经忘记了，第二次看的时候隐隐约约记得应该是假期在家的时候看的。这部电影就是让人有一种：心里不爽的时候，刷一遍就豁然开朗。如果你真正投入其中，这部电影可能会引起你得共鸣。触及你内心的深处，它会让你思考：
紧接着上篇文章，这篇文章讲述 Consumer 提供的两种 commit 机制和两种 partition 分配机制，具体如何使用是需要用户结合具体的场景进行选择，本文讲述一下其底层实现。
在前面两篇 Kafka Consumer 的文章中，Consumer Poll 模型这部分基本上已经完整结束，Consumer 这块的文章计划是要写五篇，这篇是 Consumer 这块的第三篇，本来计划是要从其中的三个小块细节内容着手，这三个地方有一个相同之处，那就是在 Kafka Consumer 中都提供了两个不同的解决方案，但具体怎么去使用是需要用户根据自己的业务场景去配置，这里会讲述其底层的具体实现（但为了阅读得更为方便，本来计划的这篇文章将拆分为两篇来，第一篇先讲述第一点，后面两点放在一起讲述）。