<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>技术总结 on Zampo Blog</title><link>https://blog.cpdd.fyi/tags/%E6%8A%80%E6%9C%AF%E6%80%BB%E7%BB%93/</link><description>Recent content in 技术总结 on Zampo Blog</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Sat, 04 Apr 2026 12:10:00 +0800</lastBuildDate><atom:link href="https://blog.cpdd.fyi/tags/%E6%8A%80%E6%9C%AF%E6%80%BB%E7%BB%93/index.xml" rel="self" type="application/rss+xml"/><item><title>Redis 最容易踩的 7 个坑，问题往往不在 Redis</title><link>https://blog.cpdd.fyi/posts/redis-pitfalls-from-douyin/</link><pubDate>Sat, 04 Apr 2026 12:10:00 +0800</pubDate><guid>https://blog.cpdd.fyi/posts/redis-pitfalls-from-douyin/</guid><description>&lt;p&gt;很多人觉得 Redis 没什么门槛。&lt;/p&gt;
&lt;p&gt;命令不难，接入也快，压测时还总能打出很漂亮的数字。于是项目上线后，大家默认它“应该不会出事”。&lt;/p&gt;
&lt;p&gt;但我看过不少 Redis 问题，最后都不是 Redis 自己不行，而是前面的设计太随便：Key 怎么拆，TTL 怎么设，热点怎么扛，内存打满以后怎么办，这些事一开始没想清楚，后面都会用线上故障补课。&lt;/p&gt;
&lt;p&gt;我最近刷到一条讲 Redis 避坑的短视频，里面提到的点很典型。我没有照着转写，而是按“线上最容易出事故的顺序”重新整理成这篇文章。&lt;/p&gt;
&lt;p&gt;如果你只记一句话，那就是：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Redis 真正危险的坑，大多不是命令层面的，而是设计层面的。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src="https://blog.cpdd.fyi/images/redis-pitfalls-cover.svg" alt="Redis 常见架构陷阱配图：中心是 Redis，周围是 Big Key、TTL、Hot、OOM 等风险信号"&gt;&lt;/p&gt;</description></item></channel></rss>