- 博客(130)
- 收藏
- 关注
RSS订阅原创 MySQL 连接数爆满时，运维第一时间该做什么？
MySQL 连接数爆满是“症状”而非“病根”。确认 MySQL 进程存活，通过定位占用连接的来源，杀掉长时间睡眠的连接和执行慢的查询。分析是慢查询导致、连接泄漏、短连接冲击还是配置过小。不同根因对应不同处置方法。从根源解决问题——优化慢查询、修复连接泄漏代码、引入连接池或调整参数配置。配置 Prometheus + MySQL Exporter 监控体系，设置合理的告警阈值，将连接数监控纳入日常巡检。在实际生产环境中，建议运维团队提前准备好上述脚本，放在。
2026-04-14 13:51:37
384
原创 【2026最新收集】github国内镜像站，高速访问
以下镜像站经实测验证，按“直接访问型”“文件加速型”“知名项目专属型”分类，标注实时可用性，方便按需选择。
2026-04-14 13:47:12
500
原创 K8s 部署 Redis 哨兵集群：主从自动切换 + 高可用实战全攻略
d '{"msgtype":"text","text":{"content":"Redis Sentinel 故障转移通知"}}' \。Redis 主从复制保证了数据的冗余备份，但如果主节点挂了，需要人工介入手动切换——在生产环境这是不可接受的。"mymaster", # 与哨兵配置中的 master-name 一致。# Sentinel 会感知主节点变化，master_for 自动返回新主。🟡 Sentinel x3（哨兵节点）—— 监控 + 投票 + 故障转移。
2026-04-02 10:45:59
508
原创 Rsync 增量备份核心实战：配置、优化与落地全解析
备份方案有很多种，但对于 Linux 运维来说，rsync 是最基本也最实用的工具。它不需要额外的备份软件、不需要 agent、不需要 license，一条命令就能做增量备份。我管过的所有环境，不管规模大小，rsync 都是备份体系的基石。源路径末尾的—— 带传目录内容，不带传目录本身。每次用 rsync 先默念这条规则。先 dry-run 再执行—— 特别是带--delete参数的时候，-n参数救人命。--link-dest 做增量—— 每天的备份看起来是完整的，但只占增量空间。
2026-04-02 10:40:23
359
原创 CentOS 7系统 OpenSSH和OpenSSL版本升级指南
2、如果/etc/pam.d/sshd不存在，添加如下配置。1、在sshd_config文件添加如下配置。如果升级后无法登录服务器。
2026-03-18 14:56:16
292
原创 MySQL备份恢复策略：mysqldump、XtraBackup与binlog实战
备份是数据库运维中最重要也最容易被忽视的环节。"重要"体现在数据丢失时备份是唯一的救命稻草，"忽视"体现在很多团队有备份脚本但从未做过恢复演练，等到真正需要恢复时才发现备份文件损坏或恢复流程不熟悉。MySQL 的备份策略需要在 RTO（恢复时间目标）、RPO（恢复点目标）和备份成本之间做权衡。没有一种方案能同时满足"备份快、恢复快、存储小"，选型时必须明确业务对这三个维度的优先级。✅方案选型：50GB 以下用 mysqldump，以上用 XtraBackup，两者都需要配合 binlog 实现 PITR。
2026-03-03 11:07:54
906
原创 Nginx高性能配置：反向代理、负载均衡与缓存优化
Nginx 1.26.x 是当前 mainline 分支的最新稳定线，在 HTTP/3 支持、动态模块加载和内存管理上相比 1.24.x 有明显改进。1.24.x 已进入维护模式，新项目直接选 1.26.x，旧项目建议在下次维护窗口升级。在现代微服务架构中，Nginx 承担的角色已远超传统 Web 服务器。它是流量入口的第一道关卡：接收外部请求、终止 TLS、执行负载均衡、缓存上游响应、转发到后端服务集群。一个配置不当的 Nginx 实例，即便后端服务性能再好，也会成为整个系统的瓶颈。
2026-03-03 11:05:07
1086
1
原创 企业级防火墙配置：iptables与nftables规则管理实战
Linux 防火墙的核心是 Netfilter 框架。Netfilter 工作在内核态，通过在网络协议栈的关键路径上注册钩子函数（hook），对流经的每个数据包进行检查、修改或丢弃。数据包从网卡进入内核后，依次经过 PREROUTING、路由决策、FORWARD/INPUT、POSTROUTING 等处理节点，每个节点上挂载的规则决定了数据包的命运。iptables 作为 Netfilter 的用户态管理工具，从 Linux 2.4 时代沿用至今，四表五链的模型深入人心。
2026-03-02 10:27:22
1179
原创 基于Fail2ban的暴力破解防护：SSH与Web服务安全加固
暴力破解是公网服务器面临的最常见攻击之一。SSH、Web 登录页面、API 接口是主要目标，攻击者使用 Hydra、Medusa、Burp Suite 等自动化工具，以每秒数百次的频率尝试用户名密码组合。一台暴露 22 端口的服务器，上线几小时内就会收到大量暴力破解请求，这在中随处可见。Fail2ban 是 Linux 环境下成熟的入侵防御工具，工作原理直观：监控日志文件 → 正则匹配失败记录 → 达到阈值触发封禁动作（通过 iptables/nftables 封锁 IP）→ 到期自动解封。
2026-03-02 10:23:38
773
原创 别再让 Pod “乱跑”：Kubernetes 调度策略原理与落地指南
Pod调度是Kubernetes的核心机制之一，决定了Pod最终运行在哪个节点上。默认调度器kube-scheduler通过一系列预选（Filtering）和优选（Scoring）算法完成调度决策，但默认行为在生产环境中往往不够用。实际场景中经常遇到的问题：数据库Pod被调度到了没有SSD的节点上，导致IO性能差；两个高负载服务的Pod被调度到同一个节点，互相抢资源；GPU节点上跑了一堆普通业务Pod，真正需要GPU的任务反而调度不上去。这些问题都需要通过调度策略来解决。
2026-02-28 10:00:47
949
原创 vLLM + K8s：大模型推理服务的弹性部署与GPU调度方案
GPU 显存管理：7B 模型 FP16 推理需要约 14GB 显存，70B 模型需要 140GB+，KV Cache 随并发数线性增长，显存碎片化导致实际利用率不足 60%高并发低延迟：在线服务要求 P99 延迟可控，传统静态批处理在请求长度差异大时效率低下弹性伸缩：GPU 资源昂贵（A100 单卡约 $2/h），流量波谷时需要快速缩容降本多模型管理：生产环境通常同时运行多个模型版本，需要灰度发布和流量切分能力。
2026-02-28 09:57:49
1431
原创 从 Pod 重建不丢数据开始：Kubernetes PV/PVC/StorageClass 落地实践
容器本身是无状态的，Pod重启后容器内的数据全部丢失。数据库、消息队列、文件存储这类有状态服务跑在K8s上，必须解决持久化存储问题。Kubernetes通过PersistentVolume（PV）、PersistentVolumeClaim（PVC）和StorageClass三层抽象来管理存储。实际生产中踩过的坑：开发团队直接在Pod里用hostPath挂载宿主机目录，Pod漂移到其他节点后数据就丢了。还有团队手动创建了100个PV，每次扩容都要运维手动操作，效率极低。
2026-02-26 10:01:37
1133
原创 Ingress Nginx 性能调优：单机 10 万 QPS 的配置秘籍
Ingress Nginx 是 Kubernetes 集群中最主流的流量入口组件，承担着集群内所有 HTTP/HTTPS 流量的路由和转发。默认配置能应付开发测试环境，但一到生产环境扛高并发，各种瓶颈就暴露出来了——worker 进程数不够、连接池耗尽、SSL 握手吃满 CPU、upstream 超时雪崩。很多团队遇到性能问题的第一反应是加副本数、加节点，但 Ingress Nginx 的性能瓶颈往往不在资源量上，而在配置参数上。
2026-02-26 09:57:49
756
原创 误删文件恢复指南：rm -rf 后的 3 种“后悔药“
大概是 Linux 世界里杀伤力最大的命令，没有之一。手一抖、路径一错、通配符一飘，几个 G 的数据就没了。更要命的是 Linux 默认没有回收站机制， 删掉的文件不会像 Windows 那样安静地躺在回收站里等你反悔——它直接就没了。但"没了"这个说法并不完全准确。从文件系统的底层机制来看， 命令做的事情远没有大多数人想象的那么彻底。理解这一点，是文件恢复的理论基础。这篇文章从 Linux 文件删除的底层原理讲起，覆盖三种主流的恢复方法，以及更重要的——怎么从根本上避免这种事故发生。原理驱动：从 inod
2026-02-10 14:27:45
1420
原创 本地部署OpenClaw安装配置使用
后面详细了解了下，这个功能其实就是一个npm包，不用买单独的云服务器。作为程序员，可以用的服务器可是有一堆，或者自己开个虚拟机在上面安装就行了。官网地址： https://github.com/openclaw/openclaw1.安装npm（第一种安装方式）首先你得安装22.0以上版本的npm，此版本的npm不支持在类似centos7的低版本系统中运行。例如，以下我是在centos8系统安装的。# centos8、ubuntu22等系统用高版本的2.安装openclaw。
2026-02-10 14:21:21
40261
6
原创 Nginx+Keepalived双主架构：消除单点故障的最佳实践
玩负载均衡的都知道，单台 Nginx 就是个定时炸弹。跑得再稳，硬件故障、网络抖动、内核 panic 这些事谁也说不准啥时候来。我见过太多团队，业务量不大的时候单机裸奔，等出了事故才想起来要做高可用，然后手忙脚乱地上线，结果配置没调好又出问题。传统的 Nginx + Keepalived 主备模式有个明显缺点：备机资源闲置。一台几万块的服务器放在那里只等着主机挂掉才派上用场，这 ROI 怎么算都不划算。双主架构就是为了解决这个问题——两台机器都在干活，互为备份，任何一台挂了另一台顶上，资源利用率直接翻倍。
2026-02-03 09:56:17
1216
原创 一款轻量级 Nginx 访问日志分析与可视化面板，支持实时统计、IP 归属地解析与客户端识别
查看程序日志输出：cat /mnt/nginxpulse_data/nginxpulse.log；此外，它还能自动识别 Caddy 的 JSON 日志格式，支持自定义 Nginx log_format，甚至能解析带。网站 75e7 的远端目标 /var/log/nginx/access.log 扫描完成，解析了 6 条记录。1.4 因为是拷贝过来的日志文件，会导致文件属组不一样，无法解析日志文件。这意味着你可以自由使用、修改、分发，甚至用于商业产品，只需保留原始版权声明即可。设为空数组，立即纳入统计。
2026-02-03 09:48:46
507
原创 K8s Ingress实战：七层负载均衡流量治理
在云原生应用架构中，流量管理是保障服务稳定性和可用性的核心环节。随着微服务架构的普及，单一应用被拆分为数十甚至数百个独立服务，传统的四层负载均衡已无法满足复杂的流量调度需求。Kubernetes Ingress 作为集群的统一流量入口，提供了七层（HTTP/HTTPS）负载均衡能力，支持基于域名、路径、请求头等维度的精细化流量控制。Kubernetes 从 1.19 版本开始将 Ingress API 升级为稳定版本（v1），并在后续版本中持续增强其功能。
2026-01-30 16:47:21
915
原创 Proxmox VE 监控：把集群指标秒级推送到 InfluxDB 2.x，Grafana 大屏一步到位
PVE 自带的pvestatd每 30 秒就把 CPU、内存、磁盘、网络、虚拟机/容器等 200+ 指标采了个遍，可惜默认只躺在里。打开「Datacenter → Metric Server → InfluxDB」开关，数据会实时推送到 InfluxDB 2.x，再用官方 Grafana 模板，3 分钟就能拥有带标签的「下一代监控大屏」，支持 Flux 查询、告警、容量预测，全程无代理、零成本。
2026-01-30 16:41:31
1330
原创 Tomcat JVM调优实战：从频繁GC到稳定运行的蜕变
我至今还记得2020年那个凌晨3点的电话。线上系统突然卡顿，用户投诉如潮水般涌来。登上服务器一看，Full GC每隔几秒就来一次，每次停顿时间长达5秒。CPU被GC线程打满，正常业务根本没法处理。那晚我们临时把堆内存从4G加到了8G，Full GC确实少了，但问题没有根本解决。后来花了两周时间，系统性地学习了JVM调优，把那套系统从"动不动就卡"调成了"稳如老狗"。这篇文章就是我那两周踩坑经历的总结，希望能帮你少走一些弯路。理解内存结构：知道年轻代、老年代、元空间的作用选对GC收集器。
2026-01-27 11:51:12
752
原创 Nginx性能调优20条黄金法则：支撑10万并发的配置模板
说实话，Nginx调优这事儿我踩过无数坑。记得2019年双11，我们电商平台流量暴涨，Nginx直接扛不住了，QPS从平时的2万飙升到8万，响应时间从50ms飙到了2秒，最后还是靠临时加机器扛过去的。那次事故之后，我花了大半年时间专门研究Nginx的性能极限，总结出了这20条黄金法则。Nginx作为目前最流行的Web服务器和反向代理，官方数据显示单机可以轻松处理10万+的并发连接。但实际生产环境中，很多同学拿到默认配置就直接上了，结果发现连1万并发都扛不住。问题不在Nginx本身，而在于配置。
2026-01-27 11:48:02
907
原创 Nginx HTTPS配置与证书自动续期：Let‘s Encrypt实战
证书管理：使用Let's Encrypt免费证书，配置自动续期安全配置：只用TLS 1.2+，启用HSTS，配置安全头性能优化：OCSP Stapling，会话缓存，HTTP/2监控告警：证书过期监控，TLS握手时间监控# 必备配置# 自动续期。
2026-01-27 11:44:11
983
原创 Linux系统性能瓶颈定位：CPU、内存、磁盘IO全面诊断
在实际生产环境中，系统性能问题往往来得突然又难以定位。某天下午，你可能会接到告警：电商平台响应时间从平时的200ms突然飙升到2秒，用户投诉激增，运营团队焦急万分。这时候，如何快速准确地找到性能瓶颈，就成了运维工程师的核心能力。性能问题的表现形式多种多样：应用响应缓慢、页面加载卡顿、API接口超时、数据库查询变慢等等。。很多时候，我们容易陷入"头痛医头、脚痛医脚"的误区。看到CPU使用率高就加CPU，看到内存不足就加内存，结果钱花了不少，问题依然存在。
2026-01-26 15:56:33
828
原创 MySQL数据库备份恢复策略：全量、增量与binlog应用
组件版本要求说明MySQL5.7+/8.0+支持GTID和增强的binlog功能mysqldump与MySQL版本匹配逻辑备份工具，MySQL自带8.0+物理备份工具，支持热备份存储空间数据库大小的3-5倍用于存储备份文件权限要求SUPER、RELOAD、REPLICATION权限备份和恢复需要的权限。
2026-01-26 15:53:31
744
原创 LVM逻辑卷在线扩容实战：零停机扩展磁盘空间
这个粒度在绝大多数场景下都够用，但如果你需要更精细的控制，创建卷组的时候可以指定更小的PE大小。假设我们有一台CentOS 8的服务器（其实Rocky Linux 9、AlmaLinux 9操作都一样），现有一个100G的逻辑卷挂载在/data目录，现在空间不够用了，需要再加100G。物理卷是LVM的最底层，可以是整块磁盘，也可以是磁盘上的一个分区。：在SAN存储多路径环境下，一定要在multipath设备上操作（/dev/mapper/mpatha），不要在单个路径上操作（/dev/sda）。
2026-01-09 09:59:55
1083
原创 Linux内核参数调优实战：让服务器性能提升300%的秘诀
查了半天发现是后端服务器连接Redis的TIME_WAIT太多，把本地端口（默认32768-60999，大约2.8万个）占满了。传统的内存页是4KB，对于大内存应用（数据库、JVM）来说，页表会非常大，TLB（Translation Lookaside Buffer）命中率低。这在大多数场景下没问题，因为程序申请的内存不一定全用。在某些场景下会导致性能问题，因为它会优先回收本地内存（包括页面缓存），而不是使用远程节点的空闲内存。不同版本的内核支持的参数不一样，有些新参数在老内核上根本不存在。
2026-01-09 09:54:47
1412
原创 Tomcat/Nginx 参数调优:让你的服务器吞吐量翻倍的秘密
Tomcat 和 Nginx 作为 Java Web 应用和反向代理的黄金组合,在生产环境中承载着海量的用户请求。然而,大多数开发者往往采用默认配置直接上线,导致在高并发场景下出现响应缓慢、连接超时、CPU 飙升等问题。通过科学的参数调优,可以在不增加硬件成本的情况下,将系统吞吐量提升2-5倍,显著改善用户体验。/bin/bash# 全栈监控脚本whiletrue;do# Nginx监控then。
2025-11-28 10:54:12
935
原创 告别单点故障！Linux双网卡绑定实战
生产环境里，网络就是服务器的“命根子”。想想看：一台承载海量交易的数据库主机，因为一根网线松了或网卡罢工，整个业务链条瞬间崩盘——用户投诉、领导追责undefined加班到天亮……这不是科幻，是每个运维人的真实写照。。它能把两张物理网卡“合体”成一张逻辑网卡，实现自动故障切换和高带宽保障。重点针对，我们只聊最实用的——配置零门槛、无需折腾交换机，纯干货上手即用！
2025-11-25 09:44:55
1036
原创 数据库CPU飙升100%排错思路
• 招式 1 见效最快（5 秒内），无需等待数据库反应• 招式 2 精准（针对 SQL），但需要数据库连接正常• 招式 3 需要重启（有 downtime），是最后手段。
2025-11-22 14:00:50
640
原创 MySQL性能优化圣经：索引、慢查询、分库分表
每增加一个索引，INSERT/UPDATE 会多一次磁盘 I/O（维护索引 B+ 树）。→ 章节 8（最小必要原理）→ 章节 7（实施步骤完整版）→ 章节 11（最佳实践 30 条）→ 章节 12（FAQ）• 单表索引：B+ 树高度限制在 4 层（16KB 页 × 4 = 64KB 树高），单表容量 ≈ 100GB。→ 章节 6（快速清单）→ 章节 7（实施步骤 Step 1-6） → 章节 13（附录：关键脚本）• B+ 树索引：仅需 log₁₆(100w) ≈ 5 次 I/O，成本 ≈ 40KB，
2025-11-22 13:58:26
868
原创 MySQL高可用架构演进：从主从复制到MGR集群的生产实践
MySQL作为互联网应用最广泛的关系型数据库，其高可用性一直是运维工程师关注的核心问题。随着业务规模的扩大，单点故障可能导致严重的业务中断和数据丢失。MySQL高可用架构经历了从简单的主从复制到半同步复制，再到MGR（MySQL Group Replication）集群的演进过程。传统的主从复制存在数据一致性风险和故障切换时间长的问题，半同步复制虽然提升了数据安全性但性能开销较大，而MGR作为MySQL官方推出的原生高可用解决方案，提供了自动故障检测、自动选主和强一致性保证，已成为生产环境的主流选择。
2025-11-22 13:49:20
748
原创 支持百万负载的Nginx配置长什么样？
• HTTP 模块文档：https://nginx.org/en/docs/http/ngx_http_core_module.html。→ 章节 7（Nginx 架构原理） → 章节 6（逐项参数说明） → 章节 8（性能监控）• Nginx 性能优化完全指南：https://www.nginx.com/blog/• Nginx 官方文档：https://nginx.org/en/docs/• wrk 性能测试工具：https://github.com/wg/wrk。
2025-11-20 14:31:33
972
原创 Redis缓存穿透、击穿、雪崩：一文彻底搞懂解决方案
• 注意：布隆过滤器有误判率，可能将不存在的数据判断为存在，但绝不会将存在的数据判断为不存在。：不合理的缓存策略可能导致内存溢出、数据不一致等严重问题，务必在生产环境部署前进行充分测试！• 逻辑过期方案：不会阻塞，永远返回数据（可能是旧数据），适合对可用性要求极高的场景。• 生产环境建议：一般热点数据用互斥锁，超级热点数据（如秒杀商品）用逻辑过期。• 互斥锁方案：简单直接，但会阻塞其他线程，适合一般热点数据。• Docker：注意持久化数据的挂载，避免容器重启数据丢失。
2025-11-13 18:20:23
1217
原创 nginx域名代理dify
如果你希望剥离 /console 或 /api 前缀，可使用 proxy_pass http://dify_backend/;# 常用 proxy 超时/缓冲设置（可放到单独文件 proxy.conf 并 include）ssl_certificate_key "/etc/nginx/ssl/正式.key";ssl_certificate "/etc/nginx/ssl/证书.pem";# WebSocket / 长连接支持（若后端使用）
2025-11-04 09:58:07
588
原创 企业级K8s部署：Helm+Kustomize混合策略实现零配置漂移与10分钟多环境发布
dev→staging→prod 按 Git 分支或 Tag 推进，staging 必须通过自动化测试（冒烟测试 + 性能基线），生产变更需要 2 人 PR 审批。使用 Signed Commit 防止篡改。: 创建多环境 overlays（dev/staging/prod差异化配置）: 集成 ArgoCD 实现 Git 即配置源（暂不执行，提供配置范例）。• 需要管理 3+ 环境（dev/staging/prod）的微服务架构。：对于第三方组件（Redis/MySQL/Kafka），使用。
2025-10-30 14:10:24
1039
原创 X86平台使用Docker模拟麒麟V10 ARM64环境
因为国产化的普及，尤其一些政府部门，已经开始走的路线，自己买 arm 平台的，这个成本着实吃不消，于是尝试 x86 平台运行 arm 平台的容器来降本增效，主要是解决麒麟系统。
2025-10-14 16:13:01
1363
原创 从零搭建企业级DevOps流水线
• 操作系统:CentOS 7.9 或 Ubuntu 20.04。• 3台服务器(最低配置:4核8G,生产建议8核16G):为每个命名空间设置ResourceQuota。:使用HPA根据负载自动调整副本数。• 网络:各节点互通,可访问外网。:定期清理Harbor中的旧镜像。:非生产环境在夜间自动缩容。
2025-10-11 10:40:30
689
原创 SSH端口暴露防护：基于CanaryToken的攻击链溯源与主动防御体系
在网络安全领域，它是一种主动诱饵技术，通过在系统中部署看似真实的敏感资源（但实际上是陷阱），一旦被访问就立即触发告警。SSH攻击已经形成了完整的产业链，从自动化扫描工具、字典生成服务到僵尸网络租赁，攻击者的成本越来越低。：某金融机构需要满足等保三级和PCI-DSS合规要求，需要完整记录所有SSH会话。：针对特定版本的SSH服务进行0day攻击。：只有在攻击成功后才能通过异常行为发现入侵。• 成功追踪到15起APT攻击的完整攻击链。：部署多种类型的陷阱覆盖不同攻击路径。：在攻击链早期阶段就能发现入侵。
2025-10-11 10:37:17
638
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人