张鹏的博客

高流量场景下不对客户端做约束，一个失控的爬虫就能把后端拖垮。Nginx 给了两道闸门：limit_req 限请求频率，limit_conn 限并发连接。两者看着像，实际拦的是不同维度——一个管”每秒来多少次”，一个管”同时挂着几个”。这篇把两个模块的生效阶段、配置写法讲清，并用 nginx/1.31.5 容器实测三组典型行为：burst 突发放行、严格限速拒绝、并发连接超限。 实验环境 nginx/1.31.5（nginx:alpine 容器） 所有实测在容器内自测（curl 打 127.0.0.1），不做端口映射 limit_rate 用于人为拖慢响应，制造真实的并发连接场景 核心机制一句话limit_req 基于令牌桶：按 rate 匀速往桶里放令牌，请求来了取一个令牌，取不到就拒绝；burst 是桶的容量，允许短时间攒着的令牌被一次性用掉。limit_conn 基于实时计数：某个键（通常是客户端 IP）当前有几个活动连接，超过阈值就拒绝新连接。 limit_req：限请求频率配置写法limit_req_zone 声明共享内存区（只能放 http 层），...

一个请求进来该由哪个 location 处理，取决于 Nginx 的 location 匹配规则。这套规则网上说法很多——“最长匹配””正则优先”各种版本都有流传，有的还是错的。本文用 nginx/1.31.5 容器把四类匹配模式逐一实测，给出经过验证的优先级结论：精确匹配怎么命中、^~ 到底”跳过”了什么、正则是按顺序还是按最长、嵌套 location 如何生效。 实验环境 nginx/1.31.5（nginx:alpine 容器） 验证方法：每个 location 里放 return 200 "标记"，curl 不同 URI 看返回的标记——命中哪个块一目了然，这也是排查 location 问题时最实用的技巧 四类匹配模式 写法 名称 语义 location = /uri 精确匹配 URI 完全相等才命中 location ^~ /uri 前缀匹配（跳过正则） 前缀命中且是同类最长时，不再查正则 location ~ 正则 正则匹配（区分大小写） 按配置顺序取第一个命中 location ~* 正则 正则匹配（不...

旧链接要平滑跳到新地址、请求路径要按语言分发，这类需求在 Nginx 上都归 rewrite 模块管：它基于正则匹配和条件判断来修改请求的 URI，重写结果既可以走内部重定向（用户无感知），也可以把浏览器引到别的 URL（返回 301/302）。rewrite 的规则写起来只有一行，但”改写后的 URI 会重新走一遍匹配流程”这个特性让新手经常踩进死循环。本文在 nginx:alpine 容器里把三个典型场景逐个跑通，包括一次真实的循环翻车与修复。 实验环境 nginx:alpine（nginx/1.31.5），配置写在 /etc/nginx/conf.d/default.conf 静态目录 /usr/share/nginx/html 下预置了 new-path、zh/docs/intro、en/docs/intro 几个文件作为重写目标 验证工具 curl，全部在容器本机 127.0.0.1 完成 先搞清楚 rewrite 在哪一步执行一...

服务器磁盘 IO 上不去时，先别急着换硬件——调度器、挂载参数、写缓存这些软件层面的调整往往就有明显收益。但这套手段在机械硬盘（HDD）和固态硬盘（SSD）上不能混着用：两种盘的瓶颈完全不同，给 HDD 减少寻道、给 SSD 减少无谓写入，才是各自对症的药。这篇按实例过一遍主要优化点，调度器、TRIM、atime 和 LVM 建卷都在 Rocky 9 容器里实跑验证过，命令和输出可以直接对照改。 实验环境 Rocky Linux 9.3 容器（一次性 docker run --privileged，lvm2 2.03.33、e2fsprogs 1.46.5、sysstat 12.5.4）； 容器里没有真实机械盘，块设备用 loop 回环盘代替，命令语法与实机一致； 原文基于 CentOS 7，两代系统的差异在对应位置标明； hdparm 写缓存涉及真实 ATA 盘，容器无法模拟，未实跑。 先搞清楚盘的类型两种盘的物理结构决定了优化方向完全不同： HDD 的瓶颈在旋转延迟和寻道时间。磁头跳来跳去的时间远多于真正读写的时间，随机 IO 一多吞吐就崩，优化思路是减少磁头动作、合并写...

ZooKeeper 在分布式系统里干的活不算显眼，但缺了它很多组件跑不起来：Kafka 的元数据、Hadoop 的高可用选主、各类中间件的配置协调都靠它。这类组件的特点是一旦上线就轻易不动，所以第一次部署值得花心思装对。本文记录在 Rocky Linux 9.3 上搭一套三节点 ZooKeeper 3.8.6 集群的完整过程——从装 Java 到跨节点读写验证，CentOS 7 时代的差异放在文末单列。 环境与验证边界：本文全部命令在三个 Rocky Linux 9.3 容器（自定义 docker 网络，主机名 zk1/zk2/zk3 互通）里真实执行并验证，选举、读写、节点重连均为实测输出。物理机/虚拟机部署的步骤与此完全一致，只是节点 IP 换成真实地址。 系统和环境准备示例环境是三台 Rocky Linux 9 机器，下文用 zk1、zk2、zk3 指代。开始前确认两件事：节点之间网络互通（后面的 2888/3888 端口靠它），机器时间保持同步（Rocky 9 默认装了 chronyd，chronyc sources 有输出即可...

站点要停机维护，你不想让用户撞上一堆后端报错；旧链接换了域名，你不想写一行跳转代码；内网探活想要个固定应答，你不想为此起一个服务。这些事的共同点是：不需要任何后端参与，Nginx 自己就能把响应给出去。干这活的指令是 return，属于内置的 rewrite 模块（ngx_http_rewrite_module）——指定状态码、跳转地址，甚至响应正文，请求到它这里就地终结。 本文按配置实战组织：先交代实验环境，再给三组可直接复制的配置与真实输出（维护页、重定向、文本应答），加上 server 级整站开关，最后用实测说清两个容易踩的坑。所有输出均为 nginx/1.31.5 实跑结果，未验证的结论会明确标注。 实验环境所有实例在容器里可复现： nginx/1.31.5（docker 镜像 nginx:alpine）； 配置挂载到 /etc/nginx/conf.d/，每轮改动后 docker exec 容器名 nginx -s reload； 容器内用 curl 验证，不映射端口。 指令语义：一句话短路return 的心智模型一句话：执行到它，请求立即结束，...

Nginx 做反向代理时，后端看到的 $remote_addr 往往是代理服务器自己的 IP，真实客户端被藏在了 X-Forwarded-For 这类请求头里。日志、限流、风控如果直接用 $remote_addr，结果都会失真：封禁封到代理头上，限流把所有用户算成一个。 ngx_http_realip_module 就是解决这个问题的：让 Nginx 从可信代理传来的请求头里还原出真实客户端 IP。核心就三条指令——set_real_ip_from 圈定可信代理名单，real_ip_header 指定从哪个头取值，real_ip_recursive 决定多层代理时要不要回溯。 本文在 nginx:alpine 容器里把三种典型场景各跑一遍，每种结果都给出实拍输出。 实验环境 nginx:alpine 官方镜像，nginx -v 确认版本为 nginx/1.31.5； 请求在容器内自发自收：发起请求的源地址是 127.0.0.1，把它当作转发请求的那一层代理； 客户端 IP 用回环之外的地址（203.0.113.7 属于文档保留测试段），通过 X-Forwarded-Fo...

传统分区一旦划死，扩容就要动分区表，风险高还常常得停机。LVM（Logical Volume Manager，逻辑卷管理器）在物理磁盘和文件系统之间加了一层抽象，让存储空间可以像内存一样按需分配、在线扩容。这篇把 LVM 的核心概念、适用场景和从零建卷的完整流程一次讲清，建卷、扩容、缩容防呆均在 Rocky Linux 9.3 容器（lvm2 2.03.33）用两块 loop 盘实测。 三个核心概念LVM 的存储虚拟化靠三层结构撑起来： 物理卷（PV）：最底层的基本单位，一块整盘或一个分区，初始化后即可交给 LVM 使用。 卷组（VG）：把多个物理卷攒成一个存储池，容量在池里统一调度。 逻辑卷（LV）：从卷组里切出来的可用空间，相当于增强版的分区——可以动态调整大小而不影响已有数据。 一句话串起来：盘初始化成 PV，PV 攒成 VG 池子，LV 是从池子里切出来直接格式化挂载的”分区”。池子不是无限细分的：空间按 PE（Physical Extent，物理扩展单元，默认 4MB）切分，LV 的容量只能是 PE 的整数倍——这解释了后面”要 30M 拿到 32M”的现象。 什么...

给新盘分区、扩容时改分区大小，parted 是比 fdisk 更顺手的工具：它支持 MBR 和 GPT 两种分区表，fdisk（旧版本）处理不了的大于 2TB 磁盘它直接管，命令形式还适合写进脚本，自动化装机很常用。这篇按日常操作过一遍 parted 的用法，全部命令在 Rocky Linux 9.3 容器（GNU parted 3.5）里用 loop 盘（稀疏文件模拟的块设备）实跑验证，并指出几个容易出事的点：脚本模式缩小分区会被拦、resizepart 不会帮你扩文件系统、-s 配合管道应答会静默失效。 使用场景 创建新磁盘分区：在新磁盘上创建一个或多个分区 调整已有分区：改变现有分区的大小（配合文件系统层扩容） 格式化分区：将分区设置为特定文件系统类型（实际格式化用 mkfs 系列） 转换分区表：将磁盘分区表类型从 MBR 转换为 GPT，反之亦然 脚本化磁盘管理：在自动化部署和脚本中管理磁盘分区 安装 parted多数发行版的仓库里都有，用各自的包管理器装即可： 123456789# Debian/Ubuntusudo apt-get updatesudo apt-g...

磁盘快满、又不想停机，就是云磁盘热扩容的用武之地：控制台把盘调大，系统里再把分区和文件系统跟着拉长，全程服务不中断。这篇以 50GB 扩到 100GB 为例走一遍完整流程。整个操作分两半：平台侧只负责把盘变大，系统内的三步——确认、分区拉长、文件系统扩展——才是决定扩容成败的部分。 实测说明：文中流程已在 Rocky Linux 9.3 容器用环回设备完整复现（50M 盘扩到 100M，growpart、resize2fs 输出均为实测），命令与真实云盘一致。环回实验需要 --privileged 容器：losetup、mount 都要特权位。 什么是热扩容，什么场景用热扩容指在不关闭系统、不终止服务的情况下动态增加存储容量。云环境里尤其常用——服务要保高可用，不能为了加块盘停一次机。典型场景：数据快速增长的业务平台、不允许停机的数据库、需要动态扩容的大数据分析、以及容器宿主机。共同点是”存储跟着业务长，服务不能停”。 前提条件：root 或 sudo 权限；文件系统支持在线扩展（ext4、xfs 都支持）；系统里有 growpart（cloud-utils-growpart...