feat: 每日一问

.github/copilot-instructions.md

@@ -5,7 +5,7 @@ GoClub 是一个 Hugo 静态文档站，内容面向 Go 后端面试准备、学
 审查 Pull Request 时，请使用简体中文回复。重点关注会影响站点发布、内容质量或读者体验的具体问题：
 
 - Hugo 构建正确性，包括 front matter、shortcodes、模板、依赖子模块的主题用法，以及 `content/`、`layouts/`、`assets/`、`static/`、`data/`、`scripts/` 下的路径。
-- 中文文档质量，包括技术表述准确性、标题清晰度、术语一致性、结构可读性和明显错别字。
+- 中文文档质量，包括技术表述准确性、标题清晰度、术语一致性、结构可读性、明显错别字、病句、低俗词、冒犯性表达，以及不适合公开文档的口语化玩笑，并给出更正式的替代表达。
 - 导航一致性：`content/docs/**` 下新增页面如需出现在分区导航中，应同步更新相关 `_index.md`。
 - 链接和资源正确性，包括相对链接、`static/` 下的图片路径、外部 URL、锚点和中文文件名。
 - 贡献者数据流程：涉及 `scripts/generate_contributors.py`、`data/contributors.json`、`data/maintainers.json` 的改动，应保持 GitHub Pages 构建路径可用。

content/docs/baguwen/每日一问.md

@@ -7,6 +7,20 @@ weight: 8
 
 记录微信交流群中每天的提问。
 
+## 2026.05.19
+
+### Redis 宕机如何处理？
+
+评级：中级八股、中频
+
+重点：快速恢复服务、确认数据是否丢失、排查原因、后续优化。
+
+1. 先确认 Redis 是否真的宕机，可以从应用报错、监控告警、连接测试、端口状态、进程状态和实例健康检查入手。单机实例优先快速重启恢复服务；主从、哨兵或 Cluster 环境先查看节点状态、主从复制状态、故障转移结果和客户端路由情况，再确定重启、切主、扩容或摘除异常节点。
+2. 恢复后重点确认数据是否完整。Redis 主要依靠 RDB 和 AOF 做持久化恢复：RDB 是某个时间点的快照，恢复速度快，但会丢失快照之后的写入；AOF 记录写命令，数据更完整，恢复时会重放日志。实例拉起后要检查加载日志、key 数量、核心业务数据、主从一致性和应用读写结果。
+3. 查看日志和监控排查宕机原因。常见方向包括内存打满、`maxmemory` 配置异常、磁盘空间不足、AOF rewrite 或 `fsync` 抖动、RDB fork 卡顿、慢查询、大 Key、网络抖动、机器 OOM、容器资源限制、主从复制异常和版本缺陷。定位原因后按问题类型处理，比如清理大 Key、调整内存策略、扩容、优化持久化参数或修复部署环境。
+4. 生产环境要做高可用和兜底。推荐使用主从 + Sentinel 或 Redis Cluster，开启合适的 RDB/AOF 持久化策略，配置监控告警，关注内存、连接数、慢日志、复制延迟、`fork` 耗时和磁盘 I/O；业务侧准备本地缓存、限流、降级、熔断和数据回源策略。
+5. 面试收口：Redis 宕机处理顺序是先恢复服务，再确认数据，再排查原因，最后补齐高可用、持久化、监控和降级能力。
+
 ## 2026.05.18
 
 ### HTTPS 的 S 是什么？为什么要有 TLS？TLS 的过程？
@@ -192,7 +206,7 @@ weight: 8
 
 ### Redis 缓存与数据库如何保证最终一致性？
 
-评级：中级八股、项目中用到缓存问的概率很大
+评级：中级八股、项目中缓存相关问题出现概率较高
 
 1. 讲清三种方案：更新数据库后删除缓存、删除缓存后更新数据库、延迟双删；其中主流写法是 Cache Aside 里的“更新数据库后删除缓存”。
 2. 讲出三种方案的并发风险：更新数据库后删除缓存会遇到删缓存失败和旧值回填；删除缓存后更新数据库会遇到数据库更新窗口里的旧值回填；延迟双删通过第二次删除清理并发窗口里的脏缓存，效果取决于延迟时间设置。
@@ -220,7 +234,7 @@ weight: 8
 
 ## 2026.04.15
 
-### 讲一下 Redis 过期删除与内存淘汰
+### Redis 过期删除与内存淘汰
 
 评级：中等八股、中频八股
 
@@ -250,14 +264,14 @@ weight: 8
 
 ## 2026.04.10
 
-### 介绍下 GMP 是什么东西？
+### GMP 是什么？核心作用是什么？
 
-1. 如果在早期的 GM 模型中，我们直接给每个 M 分配一个本地队列和上下文资源，不也能解决全局锁冲突的问题吗？为什么非得在 G 和 M 之间，再凭空造出一个 P 的抽象层呢？
-2. M 没法窃取吗？为什么非要 P？
+1. 在早期 GM 模型中，如果直接给每个 M 分配本地队列和上下文资源，是否也能缓解全局锁冲突？为什么仍需要在 G 和 M 之间引入 P 这个抽象层？
+2. M 是否可以直接进行任务窃取？为什么调度设计中仍需要 P？
 3. 如果 M 阻塞掉，P 会怎么处理？
 4. 怎么动态知道 M 会阻塞，并提前退回 P？
-5. M 被解绑后，它还有 P 吗？新接手的 M 是哪来的？
-6. 如果所有的 M 都进行了系统调用，程序会停止吗？存在这种情况吗？
+5. M 被解绑后，P 的归属会如何变化？新的 M 如何接手该 P？
+6. 如果所有 M 都陷入系统调用，程序是否会停滞？调度器如何避免这种情况？
 
 ## 2026.04.09
 
@@ -277,14 +291,14 @@ weight: 8
 ### 进程的 5 个状态是什么？状态在什么情况下会转变？
 
 1. 讲出五种状态。
-2. 讲出是如何转换的。
+2. 讲出状态之间如何转换。
 
 ## 2026.04.07
 
 ### 如何保证消息队列的可靠性？
 
 1. 从链路作答：生产者发送消息 -> Broker 存储消息 -> 消费者消费消息。
-2. 想一想生产者和消费者分别有哪些确认机制。
+2. 讲出生产者和消费者分别有哪些确认机制。
 3. 考虑消息重复消费。
 
 ## 2026.04.02
@@ -309,7 +323,7 @@ weight: 8
 
 ### AI 相关基础概念科普
 
-讲一下你理解的：
+讲出你对以下概念的理解：
 
 1. token
 2. llm