小菜鸟

Kafka 副本管理器（ReplicaManager）详解：高可用的核心保障

Kafka 的副本机制是实现高可用和数据可靠性的核心，而副本管理器（ReplicaManager）则是副本机制的 “执行者”—— 负责管理集群中所有副本的生命周期、数据同步、状态维护及故障处理。本文将深入解析副本管理器的核心功能、工作机制及关键流程。

副本管理器的核心角色

副本管理器运行在每个 Broker 上，是连接控制器（Controller）、日志管理器（LogManager）与客户端的中间层，主要职责包括：

1. 副本生命周期管理：创建、删除副本，维护副本的状态（Leader/Follower）。
2. 数据同步协调：协调 Follower 副本从 Leader 副本拉取数据，确保数据一致性。
3. ISR 维护：动态更新 In-Sync Replicas（同步副本集），仅保留与 Leader 保持同步的副本。
4. 处理控制器请求：响应控制器发送的 LeaderAndIsrRequest（Leader 选举与 ISR 更新）、StopReplicaRequest（停止副本）等指令。
5. 故障响应：当副本故障（如 Follower 宕机）时，配合控制器进行状态切换和 Leader 重新选举。

核心概念：副本与 ISR

在解析副本管理器前，需明确两个核心概念：

• 副本（Replica）：分区的物理副本，分为 Leader（处理读写请求）和 Follower（从 Leader 同步数据）。每个分区的副本集合称为 AR（Assigned Replicas）。
• ISR（In-Sync Replicas）：与 Leader 副本保持同步的副本集合（包含 Leader 自身）。若 Follower 因网络延迟、故障等原因长期落后于 Leader，会被移出 ISR；恢复同步后可重新加入。

副本管理器的核心功能与流程

副本的创建与初始化

当创建主题或分区重分配时，控制器会向目标 Broker 发送 LeaderAndIsrRequest，副本管理器负责在本地创建副本：

Tomcat 性能测试与调优实践指南

性能测试是评估和优化 Tomcat 服务能力的关键环节，通过模拟不同负载场景，可定位系统瓶颈并针对性调优。本文将详细介绍性能测试的核心类型、工具及分析方法，帮助提升系统稳定性和响应速度。

性能测试的核心类型

性能测试并非单一场景，而是通过多种测试类型全面评估系统能力。根据测试目标不同，主要分为以下四类：

1. 负载测试（Load Testing）

定义：模拟逐步增长的正常用户访问量，观察系统在不同负载下的响应表现。
目的：

• 确定系统随并发用户数增加的响应时间变化趋势。
• 找到系统的最佳负载点（响应时间合理且稳定的最大并发数）。
• 验证系统的伸缩性（是否能通过增加资源提升处理能力）。

典型场景：
从 10 个并发用户开始，每次增加 50 个用户，持续 10 分钟，记录不同阶段的平均响应时间、错误率。

2. 压力测试（Stress Testing）

定义：施加远超正常水平的负载（如正常访问量的 5-10 倍），直至系统崩溃，观察临界状态。
目的：

• 确定系统的极限承载能力（崩溃前的最大并发数 / 吞吐量）。
• 发现极端负载下才会暴露的隐藏 Bug（如死锁、内存泄漏、连接池耗尽）。
• 验证系统崩溃后的恢复能力（重启后是否正常工作）。

典型场景：
以 1000 并发用户开始，每 5 分钟增加 500 用户，直至出现大量超时或错误，记录临界值及错误类型。

3. 持续运行测试（Endurance Testing）

定义：在中等负载下让系统不间断运行数天甚至数周，模拟长期生产环境。
目的：

• 发现长期运行中的累积问题（如内存泄漏、连接未释放、日志文件过大）。
• 验证系统的稳定性（是否在持续负载下逐渐退化）。
• 评估资源消耗趋势（CPU、内存、磁盘空间的长期变化）。

典型场景：
以 200 并发用户持续访问系统 72 小时，每小时记录一次 JVM 内存使用、线程状态、数据库连接数。

4. 并发测试（Concurrency Testing）

定义：聚焦于多用户同时访问同一资源（如抢购、秒杀场景），测试系统的并发控制能力。
目的：

Java 并发同步工具：从信号量到交换器的全面解析

在多线程编程中，除了 synchronized 和 Lock 等基础同步机制，JUC（java.util.concurrent）包还提供了多种高级同步工具，用于解决复杂的线程协作问题。本文将详细介绍 信号量（Semaphore）、闭锁（CountDownLatch）、屏障（CyclicBarrier）、移相器（Phaser）和交换器（Exchanger） 的原理、用法及适用场景。

信号量（Semaphore）：控制并发访问数量

Semaphore 用于控制同时访问某一资源的线程数量，通过维护一个许可计数器实现。线程需要先获取许可（acquire()），访问完成后释放许可（release()）。

核心原理

• 许可计数器：初始化时指定许可数量（如 new Semaphore(5) 允许 5 个线程同时访问）；
• 获取与释放：acquire() 减少许可数（无许可时阻塞），release() 增加许可数；
• 公平性：支持公平模式（按请求顺序分配许可）和非公平模式（默认，允许插队）。

源码关键方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 获取 1 个许可（可中断）  
public void acquire() throws InterruptedException {  
    sync.acquireSharedInterruptibly(1);  
}  

// 释放 1 个许可  
public void release() {  
    sync.releaseShared(1);  
}  

// 尝试获取许可（非阻塞）  
public boolean tryAcquire() {  
    return sync.nonfairTryAcquireShared(1) >= 0;  
}  

典型应用：限流

Tomcat 性能优化全指南

Tomcat 作为主流的 Java Web 容器，其性能直接影响应用的响应速度和并发能力。通过合理配置线程池、连接器、JVM 参数等，可以显著提升 Tomcat 的处理能力。本文将从执行器调优、连接器配置、JVM 优化等多个维度，详细介绍 Tomcat 性能优化的核心策略。

执行器（线程池）调优

Tomcat 的线程池（Executor）是处理请求的核心组件，负责管理请求处理线程。合理配置线程池参数可以避免线程频繁创建 / 销毁的开销，提升并发处理能力。

核心配置参数

1
2
3
4
5
6
7
8
9

<Executor 
  name="tomcatThreadPool"        <!-- 线程池名称（唯一标识） -->
  namePrefix="catalina-exec-"    <!-- 线程名称前缀（便于日志排查） -->
  maxThreads="500"               <!-- 最大线程数（并发处理的核心参数） -->
  minSpareThreads="50"           <!-- 最小空闲线程数（启动时初始化的线程数） -->
  maxIdleTime="60000"            <!-- 线程空闲超时时间（毫秒，默认 60000） -->
  maxQueueSize="1000"            <!-- 任务队列最大长度（超出则拒绝请求） -->
  prestartminSpareThreads="true" <!-- 启动时是否初始化 minSpareThreads 个线程 -->
/>

参数调优建议

• maxThreads：
  决定并发处理的上限，需根据服务器 CPU 核心数调整。建议：
  • 4 核 CPU：设置为 200-400
  • 8 核 CPU：设置为 400-800
    过高会导致线程切换开销增大，反而降低性能。
• minSpareThreads：
  避免请求突增时频繁创建线程，建议设置为 maxThreads 的 1/10~1/5（如 500 线程池对应 50-100）。
• maxQueueSize：
  当线程全部繁忙时，请求会进入队列等待。建议设置为 maxThreads 的 2-3 倍（如 500 线程对应 1000-1500），过大可能导致请求超时。
• prestartminSpareThreads：
  生产环境建议设为 true，启动时初始化核心线程，避免首笔请求的线程创建开销。

启用线程池

配置后需在 Connector 中引用，否则不会生效：

Kafka 日志管理器详解：存储、索引与清理机制

Kafka 的日志管理器（Log Manager）是数据持久化的核心组件，负责消息的存储、检索、维护和清理，直接影响 Kafka 的性能、可靠性和磁盘占用。本文将从日志存储结构、索引机制、检索流程到日志清理策略，全面解析日志管理器的工作原理。

日志存储基础

Kafka 中的 “日志” 并非传统意义上的文本日志，而是消息的持久化存储结构。其设计目标是高效支持高吞吐的写入和随机读取，核心特点是 “顺序写、分段存储”。

存储结构概览

• 主题与分区映射：每个主题（Topic）的每个分区（Partition）对应一个独立的日志目录，命名格式为 {topic}-{partition}（如 test-topic-0、test-topic-1）。
• 副本存储：分区的每个副本（Replica）在不同 Broker 上拥有独立的日志目录，确保数据冗余。
• 日志文件组织：每个日志目录包含多个日志段（LogSegment），每个 LogSegment 由 3 个文件组成：
  • .log：存储消息的实际内容（二进制格式）。
  • .index：偏移量索引文件，映射消息偏移量到 .log 文件中的物理位置。
  • .timeindex：时间戳索引文件，映射消息时间戳到偏移量。

日志分段（LogSegment）

Kafka 将每个分区的日志拆分为多个 LogSegment（默认最大 1GB），而非一个巨大的文件，原因如下：

• 便于管理：单个大文件难以高效定位和删除，分段后可按段操作（如删除老数据）。
• 提升性能：索引文件随分段变小，可缓存至内存，加速查询。
• 并行处理：分段操作可分布式进行，避免单文件锁竞争。

日志文件的名称是以偏移量进行命名的，这样是为了方便知道数据在哪个日志段中(采用了跳跃表的方式)

在Log对象中维护了一个ConcurrentSkipListMap(底层是跳跃表)，保存该主题所有分区对应的所有LogSegment

1
2

/* the actual segments of the log */
private val segments: ConcurrentNavigableMap[java.lang.Long, LogSegment] = new ConcurrentSkipListMap[java.lang.Long, LogSegment]

LogSegment中封装有一个FileRecords对象(日志文件)，一个OffsetIndex对象(偏移量索引文件)和一个TimeIndex对象(时间戳索引文件)

1
2
3
4
5
6
7
8

class LogSegment private[log] (val log: FileRecords,
                               val offsetIndex: OffsetIndex,
                               val timeIndex: TimeIndex,
                               val txnIndex: TransactionIndex,
                               val baseOffset: Long,
                               val indexIntervalBytes: Int,
                               val rollJitterMs: Long,
                               val time: Time) extends Logging 

在存储结构上每个分区副本对应一个目录，每个分区副本由一个或多个日志段(LogSegment)组成。每个日志段在物理结构上对应一个以.index后缀的偏移量索引文件、一个以.timeindex后缀的时间戳索引文件和一个以.log结尾的日志文件

使用.index后缀的偏移量索引文件是为了方便定位数据，在.index文件中记录了许多偏移量的索引，每隔一个范围区间创建一个索引，这种方式称之为稀疏索引。这样可以避免索引文件过大，从而使得内存中可以保存更多的索引

使用.timeindex文件是为了kafka清理数据准备的，kafka默认是保留七天内的数据的，主要根据timeindex时间索引文件里最大的时间来判断的，如果最大时间与当前时间差值超过7天，那么对应的数据段就会被清理掉

关键配置：

• log.segment.bytes：单个 LogSegment 的最大大小（默认 1073741824 字节，即 1GB）。
• log.roll.ms/log.roll.hours：LogSegment 滚动周期（即使未达大小上限，超时也会创建新段，默认 7 天）。

日志文件与索引机制

1. 日志文件（.log）

.log 文件是消息的实际存储载体，消息以追加（Append） 方式写入（顺序写磁盘，性能远高于随机写）。每条消息包含以下核心字段：