乘与零-cenyuio

线上CPU飙高如何排查？

本文详细介绍了如何排查和定位系统中高 CPU 使用情况，特别是针对 Java 进程的高 CPU 问题。主要步骤包括：首先通过 `top` 命令查看系统整体 CPU 使用情况，重点关注用户态和内核态的 CPU 占比；其次，使用 `top` 命令定位高 CPU 的 Java 进程，并记录其 PID；最后，通过 `top -H -p <PID>` 命令查看该进程下的线程 CPU 占用情况，并将高消耗线程的 TID 转换为 16 进制，使用 `jstack` 抓取该线程的堆栈信息，分析 `RUNNABLE` 状态的线程以确定 CPU 消耗原因。常见的高 CPU 场景包括正则表达式灾难性回溯、频繁序列化大对象以及线程池积压等问题。文章还补充了线上应急排查的建议，推荐使用 `top + jstack` 组合，并提到在容器环境中如何进行排查。总结指出，CPU 飙高排查的核心是通过系统、进程、线程/堆栈三步递进，关键命令包括 `top`、`printf`、`jstack`，常见问题多为正则回溯、大对象序列化和线程池积压。

2026-03-21 疑难杂症 16

cenyuio

RabbitMQ 消息重复消费问题处理方案（消息幂等性）

本文讨论了RabbitMQ中消息重复消费的问题及其解决方案，特别是如何通过幂等性来确保消息处理的可靠性。文章首先分析了消息重复消费的三个主要原因：生产者重试、消费者确认超时和网络波动。接着，解释了幂等性的概念，即同一条消息被多次消费时，业务结果应与一次性消费一致。为实现消息的幂等性，文章提出了三种解决方案： 1. **唯一标识 + 幂等表**：为每条消息分配唯一ID，消费者在处理消息前通过查询幂等表来确认消息是否已被消费过。如果未消费，则处理消息并更新幂等表；否则，直接丢弃消息。 2. **基于Redis的SETNX**：利用Redis的SETNX命令，以消息唯一ID作为key，在消费前检查key是否存在，若不存在则处理消息，否则直接丢弃。 3. **业务逻辑天然幂等**：某些业务操作本身天然具有幂等性，如更新操作或查询操作，执行多次结果一致。最后，文章强调了实现幂等性时需要注意的关键事项，如消息唯一ID的生成、手动ACK机制、幂等表或Redis的过期设置，以及异常处理的区分。总结来说，保证RabbitMQ消息幂等性的核心是通过唯一标识和幂等校验，确保消息不会被重复处理，从而提高系统的可靠性和稳定性。

2026-03-18 疑难杂症 49

cenyuio

数据库的脏读、不可重复读和幻读

文章主要介绍了数据库事务中的三种常见问题及其对应的隔离级别： 1. **脏读（Dirty Read）**：事务A修改数据但未提交，事务B读取了这些未提交的数据，随后事务A回滚，导致事务B读取到无效数据。 2. **不可重复读（Non-repeatable Read）**：在同一个事务中，事务A两次读取同一行数据，结果不一致，因为事务B在两次读取之间修改了数据并提交。 3. **幻读（Phantom Read）**：事务A两次查询的行数不一致，因为事务B在两次查询之间插入了新的数据并提交。 **隔离级别及解决方案**： - **读未提交**：三种问题都可能发生。 - **读已提交**：解决脏读问题。 - **可重复读**（MySQL默认）：解决脏读和不可重复读问题。 - **串行化**：完全解决所有问题，但性能最差。

2026-03-15 疑难杂症 33

cenyuio

畅快观影（MoonTV）

**摘要：** MoonTV 是一个基于 Next.js 14、Tailwind CSS 和 TypeScript 构建的跨平台影视聚合播放器，支持多资源搜索、在线播放、收藏同步等功能。用户可以通过 Docker Compose 轻松部署，配置包括 Redis 存储和自定义环境变量。视频源配置丰富，涵盖爱奇艺、豆瓣、电影天堂等多个资源站点。MoonTV 还支持 PWA 技术，提供离线缓存和移动端原生体验，具备智能去广告功能。项目开源，可在 GitHub 上找到相关代码。

2026-03-15 项目分享 32

cenyuio

Redis 雪崩场景重现与解决方案

本文详细介绍了Redis雪崩问题的产生原因及解决方案。Redis雪崩是指大量缓存在同一时间失效，导致所有请求直接打到数据库，造成数据库压力骤增甚至宕机的现象。文章首先通过模拟1000个缓存key在10秒后同时失效，并使用多线程模拟高并发请求，重现了雪崩场景。结果显示，缓存失效后，10000个请求全部打到数据库，导致数据库连接池被打满，总请求耗时大幅增加，数据库CPU和IO飙升。为了解决雪崩问题，文章提出了四种核心方案： 1. **过期时间随机化**：为每个缓存key的过期时间增加随机偏移量，避免集中失效。 2. **互斥锁**：当缓存失效时，只有一个线程去查询数据库，其他线程等待，防止缓存击穿。 3. **缓存预热+永不过期key**：核心数据设置永不过期，并通过后台线程定期更新缓存，避免失效。 4. **限流+降级**：通过信号量限制并发请求数，超出部分直接降级返回默认值，保护数据库。最后，文章整合了上述方案，形成了一套完整的解决方案，优化后的请求耗时从秒级降至百毫秒级，数据库压力大幅降低。总结指出，雪崩问题的核心在于大量缓存集中失效，解决方案的重点在于避免key集中失效、防止缓存击穿、保护数据库并定期更新缓存。

2026-03-04 疑难杂症 27

cenyuio

为什么 MySQL 选择使用 B+ 树作为索引结构？

数据库索引的核心需求是加速数据查找，同时减少磁盘 I/O 次数和支持范围查询、排序等常见场景。B+ 树作为数据库索引的核心结构，因其多路平衡查找树的特性，能够有效减少磁盘 I/O，支持高效的范围查询和排序，且查询效率稳定。相比其他数据结构（如哈希表、红黑树、B 树），B+ 树在磁盘 I/O 次数、范围查询支持、空间利用率等方面具有明显优势。 B+ 树的主要特性包括：1）层级低，磁盘 I/O 少；2）数据集中在叶子节点，查询效率稳定；3）叶子节点有序且通过双向链表连接，完美支持范围查询、排序和分页；4）空间利用率高，进一步降低树的高度。 MySQL 的 InnoDB 存储引擎对 B+ 树做了进一步优化，如聚簇索引、页缓存和自适应哈希索引，以更好地适应实际业务场景。总的来说，B+ 树因其低 I/O 成本、场景适配性强、效率稳定和空间利用率高，成为关系型数据库索引的“事实标准”。

2026-02-10 底层剖析 23

cenyuio

Gitea 迁移（环境：Docker + MySQL）

本文详细介绍了如何备份和恢复Gitea服务的过程，分为五个步骤： 1. **备份Gitea**：通过Docker进入Gitea终端，切换到git账号，使用`gitea dump`命令备份到指定目录，并确认备份成功。 2. **上传备份文件**：将生成的备份文件（如`gitea-dump-<时间戳>.zip`）上传到另一台Gitea主机，同时将数据库备份文件（如`gitea-db.sql`）上传到MySQL主机。 3. **恢复MySQL备份**：在MySQL终端中创建gitea数据库，并使用`mysql --default-character-set=utf8mb4`命令恢复备份。 4. **恢复Gitea备份**：解压备份文件，替换配置文件和仓库，调整文件权限，修改数据库连接方式（如需），并重新生成Git钩子。 5. **重启Gitea容器**：完成所有恢复步骤后，重启Gitea容器以确保所有更改生效。整个过程涵盖了从备份到恢复的详细操作，适用于需要迁移或恢复Gitea服务的场景。

2026-01-18 操作指引 56

cenyuio

飞牛OS-管理员密码忘记自救指南（grub方式）

本文介绍了如何在Linux系统中通过GRUB命令行界面修改用户密码的详细步骤。首先，重启电脑并在系统引导页面按下`E`键进入GRUB菜单，在`linux`行后添加`init=/bin/bash`，然后按`F10`启动系统进入单用户模式。接着，挂载根文件系统为可读写权限，使用`passwd`命令修改指定用户的密码，并输入两次密码进行确认。最后，重启电脑以应用新密码。文章还提供了检验密码和重置密码的步骤，确保操作的准确性和安全性。

2026-01-17 疑难杂症 41

cenyuio

飞牛OS-网络恢复（将ip获取方式改回DHCP）

本文介绍了如何在飞牛OS系统中通过终端命令修改网络连接的IP获取方式为DHCP。首先，用户需要连接屏幕并登录终端，使用`sudo -i`命令获取管理员权限。接着，通过`nmcli connection show`命令列出所有网络连接，找到需要修改的连接名称（如“eno1-ovs”）。然后，使用`nmcli connection modify`命令将该连接的IP获取方式设置为自动（DHCP），并通过`nmcli connection down`和`nmcli connection up`命令重启网络连接以使更改生效。文中还附有两张图片，展示了相关命令的执行结果。

2026-01-17 疑难杂症 30

cenyuio

Java面试-22：HashMap 的原理？

HashMap 是一种基于数组和链表（或红黑树）的数据结构，通过 key 的 hash 值定位桶位置。数组初始长度为 16，负载因子为 0.75，当元素达到 12 个时会扩容以避免性能下降。key 的 hash 值经过扰动运算后用于定位桶位置，采用位运算而非取模以提高效率。链表长度超过 8 且数组长度大于等于 64 时，链表会转换为红黑树以优化查询性能。put 操作流程包括计算 hash、定位桶、插入元素并判断是否扩容，而 get 操作则是反向查找。HashMap 在多线程环境下可能导致环形链表，因此是非线程安全的，建议在并发场景下使用 ConcurrentHashMap。

2026-03-25 Java面试八股文 14

cenyuio