01 A 线程在经典的 R 设计模式有个「D」的角色，主要用来接收外部请求并分发给下面的际处理线程。在 K 络架构设计中，这个 D 就是「A 线程」,用来接收和创建外部 TCP 连接的线程。在 B 端每个 SS 例只会创建一个 A 线程。它的主要功能就是创建连接，并将接收到的 R 请求传递给下游的 P 线程处理。
1）我们可以看出 A 线程主要使用了 J NIO 的 S 以及 SC 的方式循环的轮询准备就绪的IO事件。
2）将 SSC 通道注册到S 上，并关注络连接创事件：SKOP_ACCEPT。
3）事件注册好后，一旦后续接收到连接请求后，A 线程就会指定一个 P 线程，并将该请求交给它并创建络连接用于后续处理。
02 P线程A只是做了请求入口连接处理的，那么，真正创建络连接以及分发络请求是由 P 线程来完成的。而每个 P 线程在创建时都会创建 3 个队列。
1）C 队列:它主要是用来保存要创建的新连接信息，也就是SC 对象，目前是硬编码队列长度大小为20。每当 P 线程接收到新的连接请求时，都会将对应的 SC 对象放入队列，等到后面创建连接时，从该队列中获取 SC，然后注册新的连接。
2）R 队列：它是一个临时的 R 队列，当 P 线程将 R 返回给 C 之后，要将 R 放入该队列。它存在的意义：由于有些 R 回调逻辑要在 R 被发送回 R 发送方后，才能执行，因此需要暂存到临时队列。
3）RQ 队列：它主要是存放需要返回给R 发送方的所有 R 对象。每个 P 线程都会维护自己的 R 队列。
03 RHP线程池A 线程和 P 线程只是请求和响应的「搬运工」，而「真正处理 K 请求」是KRHP线程池，在上面络超高并发通信架构图，有两个参数跟整个流程有关系，分别是「」、「」。其中 就是IO 工作线程池的大小配置。
下面我们结合 K 超高并发络架构图来讲解下一个完整请求处理核心流程：
1）C 发送请求给 A 线程。
2）A 线程会创建 NIO S 对象，并创建 SSC 通道例，然后将 C 和 OP_ACCEPT 事件绑定到 S 多路复用器上。
6）这个时候客户端就可以源源不断进行请求发送了，服务端通过 S NIO P 不停的获取准备就绪的 IO 事件。
7）然后根据C中获取已经完成的R对象，构建R对象，并将其存入到 R 的 RQ 请求队列中 。
8）这个时候就该IO 线程池上场了，KRH 线程循环地从请求队列RQ 中获取 R 例，然后交由KA 的方法，执行真正的请求处理逻辑，并比较终将数据存储到磁盘中。
9）待处理完请求后，KRH 线程会将 R 对象放入 P 线程的 R 队列。
10）然后 P 线程通过 R 中的 PID 不停地从 R 队列中来定位并取出 R 对象，返还给 R 发送方。
2 了解K高吞吐日志存储架构是如何设计吗?对于 K 来说，它主要用来处理海量数据流，这个场景的特点主要包括：
1) 写操作：写并发要求非常高，基本得达到百万级 TPS，顺序追加写日志即可，需考虑更新操作。
2）读操作：相对写操作来说，比较简单，只要能按照一定规则高效查询即可,支持（或者时间戳）读取。
根据上面两点分析，对于写操作来说，直接采用「顺序追加写日志」的方式就可以满足 K 对于百万TPS写入效率要求。
如何解决高效查询这些日志呢我们可以设想把消息的 O 设计成一个有序的字段，这样消息在日志文件中也就有序存放了，也不需要额外引入哈希表结构，可以直接将消息划分成若干个块，对于每个块我们只需要索引当前块的首条消息的 O ，这个是不是有点二分查找算法的意思。即先根据 O 大小找到对应的块，然后再从块中顺序查找。如下图所示：
这样就可以速定位到要查找的消息的位置了，在 K 中，我们将这种索引结构叫做「稀疏哈希索引」。
上面得出了 K 比较终的存储现方案，即基于顺序追加写日志 +稀疏哈希索引。
接下来我们来看看 K 日志存储结构：
从上图看出来，K 是基于「主题 +分区 + 副本 + 分段 + 索引」的结构进行日志存储的。
了解了整体的日志存储架构，我们来看下 K 日志格式，K 日志格式也经历了多个版本迭代，这里我们主要看下V2版本的日志格式：
02 JVM 监控另一个重要的监控维度就是 JVM 监控。监控 JVM 进程主要是为了让你全面地了解K B 进程。
要监控JVM 进程，需要关注 3 个指标：
「监控F GC 发生频率和时长」、「监控堆上活跃对象大小」、「监控应用线程总数」
03 K 集群监控另外一个重要监控维度就是 K B 集群和各类客户端的监控，主要有3个方法：
1）查看 B 端重要日志：主要包括 B 端服务器日志 ，控制器日志以及主题分区状态变更日志 -。其中， 是比较重要的，如果你的 K 集群出现了故障，你要首时间查看 ，定位故障原因。
2）查看 B 端关键线程运行状态，例如:
L C 线程：日志压缩清理。一旦它挂掉了，所有 C 操作都会中断，但用户对此通常是感知的。
副本拉取消息的线程：主要执行 F 副本向 L 副本拉取消息的逻辑。如果它们挂掉了，系统会表现为 F 副本延迟 L 副本越来越大。
3）查看 B 端关键的 JMX 性能指标:主要有BIBO、NPAIP、RHAIP、URP、ISRSISRE、ACC 这几个指标。
04 K 客户端监控客户端监控主要是生产者和消费者的监控，生产者往 K 发送消息，此时我们要了解客户端机器与 B 机器之间的往返时延 RTT 是多少，对于跨数据中心或者异地集群来说，RTT 会更大，很难支撑很大的 TPS。
P角度:- 是需要重点关注的JMX指标，即消息生产请求的延时；另外 S 线程的运行状态也是非常重要的， 如果 S 线程挂了，对于用户是感知的，表象只是 P 端消息发送失败。
C角度:对于 C G，需要重点关注和指标，它表示 R 的频繁程度。另外还包括消息消费偏移量、消息堆积数量等。
05 B 之间的监控比较后一个监控维度就是 B 之间的监控，主要指副本拉取的性能。F 副本时拉取 L 副本的数据，此时我们希望拉取过程越越好。K 提供了一个特别重要的 JMX 指标，叫做「」，意思就是比如我们规定这条消息，应该在两个 B 上面保存，假设只有一个 B 上保存该消息，那么这条消息所在的分区就叫，这种情况是特别关注的，因为有可能造成数据的丢失。
另外还有一个比较重要的指标是「 」。在整个 K 集群中应该确保只能有一台机器的指标是1，其他全应该是0，如果发现有一台机器大于1，一定是出现脑裂了，此时应该去检查下是否出现了络分区。K本身是不能对抗脑裂的，完全依靠 Z 来做，但是如果真正出现络分区的话，也是没有办法处理的，应该让其速失败重启。
5 针对 K 线上系统, 你是如何进行调的?对 K 来说，「吞吐量」和「延时」是非常重要的化指标。
吞吐量 TPS：是指 B 端或 C 端每秒能处理的消息数，越大越好。
延时：表示从 P 端发送消息到 B 端持久化完成到 C 端成功消费之间的时间间隔。与吞吐量 TPS 相反，延时越短越好。
总之，高吞吐量、低延时是我们调 K 集群的主要目标。
01 提升吞吐量首先是提升吞吐量参数和措施：
B
：表示 F 副本用多少个线程来拉取消息，默认1个线程。如果 B 端 CPU 资源很充足，适当增加该值「但不要超过CPU核数」，以加 F 副本的同步速度。这是因为在生产环境中，配置了 = 的 P 端影响吞吐量的首要因素就是副本同步性能。适当增加该值后通常可以看到 P 端吞吐量增加
：在ISR 中，如果 F 长时间未向 L 发送通信请求或同步数据，则该 F 将被踢出 ISR，该值默认为 30。
