apache 在热重载（如 `systemctl reload` 或 `apachectl graceful`）时出现丢包，通常是因为旧进程关闭监听套接字与新进程重新绑定之间存在时间差，导致内核队列中的连接被重置。优化配置的核心在于启用 tcp 快速回收机制并调整内核参数，确保新进程能无缝接管端口。具体做法是修改 apache 配置文件以支持优雅重启，同时在系统层面调整 `net.ipv4.tcp_fin_timeout` 和 `tcp_tw_reuse` 等参数，减少 time_wait 状态对端口占用的影响。
如何配置 Apache 实现优雅重启以减少服务中断
通过配置 Apache 的 `Graceful` 信号处理机制，可以确保在重载配置时，正在处理的请求完成后再关闭旧工作进程，从而避免主动断开客户端连接。主要涉及 `AcceptFilter` 和 `Timeout` 指令的调整，以及确保操作系统正确传递 `SIGHUP` 信号。
Listen 80 ServerRoot "/etc/httpd" Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 5 # 确保使用 prefork 或 worker MPM 时正确处理信号 # 在 systemd 环境中，reload 操作会发送 SIGHUP # Apache 主进程接收 SIGHUP 后： # 1. 重新加载配置文件 # 2. 启动新的工作进程 # 3. 等待现有工作进程完成当前请求 # 4. 终止旧的工作进程 # 验证配置语法 httpd -t # 执行优雅重启 systemctl reload httpd
上述配置中，`Timeout` 设置了服务器等待请求完成的超时时间，`KeepAlive` 保持长连接以减少握手开销。当执行 `systemctl reload` 时，Apache 主进程不会立即关闭监听端口，而是先 fork 出新进程绑定到同一端口（如果内核支持 SO_REUSEPORT 或依赖内核的 backlog 队列管理），然后逐步淘汰旧进程。这种机制依赖于内核 socket 状态的平滑过渡。
哪些内核网络参数能有效缓解重载期间的连接丢失
调整 Linux 内核的网络栈参数是解决重载丢包的关键。重点在于缩短 `TIME_WAIT` 状态的持续时间，并允许重用处于该状态的端口，从而加快端口的释放和重新绑定速度。主要涉及 `/etc/sysctl.conf` 中的 `net.ipv4.tcp_*` 系列参数。
通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。
# /etc/sysctl.conf # 缩短 TIME_WAIT 状态的持续时间，默认 60 秒 net.ipv4.tcp_fin_timeout = 15 # 允许重用 TIME_WAIT sockets 用于新连接 net.ipv4.tcp_tw_reuse = 1 # 增加本地端口范围，避免端口耗尽 net.ipv4.ip_local_port_range = 1024 65535 # 增加监听队列长度，防止高并发下连接被拒 net.core.somaxconn = 1024 net.ipv4.tcp_max_syn_backlog = 1024 # 应用更改 sysctl -p
这些参数直接影响了 socket 的生命周期。`tcp_fin_timeout` 控制的是本端主动关闭连接后，socket 保持在 `FIN-WAIT-2` 状态的时间，而 `tcp_tw_reuse` 允许将处于 `TIME_WAIT` 的 socket 用于新的出站连接，虽然这对服务端监听端口的重用帮助有限，但有助于整体连接回收。更关键的是，确保在重载期间，内核能够正确处理 socket 的迁移。在某些情况下，启用 `SO_REUSEPORT`（需内核 3.9+ 且 Apache 编译支持）可以让多个进程同时绑定同一端口，但这通常用于负载均衡而非简单的重载场景。对于标准的 `graceful` 重载，内核的 backlog 队列起到了缓冲作用，新进程在旧进程完全退出前即可开始接受新连接。
重载过程中 Apache 子进程状态转换的具体表现是什么
在重载过程中，Apache 的子进程会经历从 `running` 到 `gracefully closing` 再到 `terminated` 的状态变化。这一过程由主进程调度，确保没有请求被强制中断。具体表现为工作进程在处理完当前请求后，不再接受新的连接，并等待所有活跃连接关闭，最后退出。
以下代码展示了如何通过监控 Apache 状态来观察这一过程：
# 安装 mod_status 并启用
LoadModule status_module modules/mod_status.so
<location>
SetHandler server-status
Require ip 127.0.0.1
</location>
# 在另一个终端监控状态
watch -n 1 'curl -s http://127.0.0.1/server-status?auto | grep -E "(BusyWorkers|IdleWorkers|TotalAccesses)"'
当执行重载命令后，你会观察到 `BusyWorkers` 数量逐渐下降，而 `IdleWorkers` 数量先上升（新进程启动）后稳定。如果配置得当，`TotalAccesses` 应该连续增长，中间没有明显的断崖式下跌，这表明连接没有被丢弃。如果出现丢包，通常是因为 `BusyWorkers` 骤降为零，而 `IdleWorkers` 尚未完全接管，或者内核层面的 socket 迁移失败。此时检查 `dmesg` 日志，看是否有 `TCP: request_sock_TCP: Possible SYN flooding` 或 socket 错误信息，有助于进一步诊断。
