Redis 架构那些事儿，聊聊规范化怎么做才能不乱套

主要综合自知乎专栏“Redis实战精讲”和某技术博客“码农翻身”的相关文章观点,并结合常见的项目实践经验）

Redis架构那些事儿，聊聊规范化怎么做才能不乱套

Redis这东西，用好了是神器，用不好就是一场灾难，很多团队刚开始用Redis的时候，觉得它简单又快，随便找个服务器装上去就开始用了，结果随着业务发展，数据量上来了，访问量也爆了，之前随便搞搞的架构就开始到处出问题：内存不够了、响应变慢了、甚至整个缓存崩了导致网站打不开，今天就来聊聊，怎么从一开始就把Redis的架构规划好，让这套缓存系统能稳稳当当地支撑业务,不乱套。

第一件事：别把Redis当垃圾桶，先想清楚数据往哪放

这是最最容易出问题的地方，很多人把Redis当成了一个万能仓库，什么数据都往里塞，用户信息、商品列表、会话、计数器、消息队列……全堆在一起，结果就是键名（Key）起得乱七八糟，比如有的叫“user_123”，有的叫“product_list_category_5”，还有的叫“today_active_users”，时间一长，连开发者自己都记不清某个键是干嘛的,更别说清理和维护了。

规范化怎么做？ 得有个清晰的“命名空间”概念，就像你整理电脑文件夹，不会把所有文件都扔在桌面，而是会建不同的文件夹分类存放，在Redis里，可以用冒号“:”来模拟文件夹，所有和用户相关的数据，键名都以“user:”开头：

• user:123:info 存储ID为123的用户基本信息。
• user:123:orders 存储这个用户的订单列表。
• user:session:abc123 存储会话ID为abc123的用户状态。

同样，商品相关的就是“product:”开头，统计相关的就是“stats:”开头，这样一做，首先键名一目了然，其次方便管理，你想批量查找或删除所有用户相关的键，可以用keys user:*命令（生产环境慎用，可以用SCAN替代），这套规范需要写成文档，要求所有开发人员遵守,从源头上避免键名混乱。

第二件事：别让一台Redis服务器扛下所有，学会“分家”

就算你键名规划得再好，如果所有数据、所有读写请求都集中在一台Redis服务器上，风险也非常大，这台机器一旦出故障，整个服务就瘫痪了,单台机器的内存和性能总有上限。

规范化怎么做？ 根据数据的重要性和用途，把Redis实例拆开，这叫“实例隔离”。

1. 缓存和持久化数据要分开：有的数据只是临时缓存，丢了也没关系，可以从数据库再查，但有的数据，比如用户购物车，可能需要在一定时间内持久保存，丢了会引起客诉，这两类数据应该放在两个不同的Redis实例里，给持久化数据配置AOF持久化策略，确保数据安全；而缓存实例可以配置更宽松的策略,甚至禁用持久化来追求极致性能。
2. 不同业务线数据要分开：如果公司业务复杂，有电商、论坛、用户中心等多个模块，最好为每个核心业务创建独立的Redis实例（或集群），这样做的最大好处是“故障隔离”，比如论坛的缓存出了问题，内存被打满,不会影响到电商核心的交易流程。
3. 主从复制是必备的：只要不是特别小的项目，都应该给重要的Redis实例配置“主从复制”，主节点（Master）负责写，从节点（Slave）负责读和备份，一旦主节点宕机，可以手动或自动地将一个从节点切换成新的主节点，快速恢复服务,大大提高了系统的可用性。

第三件事：别等到内存报警才手忙脚乱，提前做好“容量规划”

Redis是内存数据库，内存就是最宝贵的资源,很多故障都是因为内存突然被占满导致的。

规范化怎么做？

1. 预估容量：在项目上线前或进行重大活动前，要根据业务量预估Redis需要的内存，一个用户对象大概1KB，预计100万用户，那至少需要1GB内存，还要留出30%以上的余量应对增长和峰值。
2. 设置过期时间：对于缓存数据，99%的情况都应该设置一个合理的过期时间（TTL），这能避免无效数据永久占用内存，相当于给缓存数据一个“自动清理”的机制，比如商品信息缓存1小时,用户会话缓存7天。
3. 配置淘汰策略：在Redis配置文件中，一定要设置maxmemory-policy（内存淘汰策略），当内存用完时，Redis会根据这个策略来删除一些数据，而不是直接报错，常用的策略是allkeys-lru，即淘汰最近最少使用的键，这算是一种保护机制，保证在内存不足时，系统还能继续提供服务,只是可能会淘汰掉一些不常用的缓存。

第四件事：别以为装上去就完事了，日常“巡检”不能少

再好的车也需要定期保养，Redis也一样,把它部署上线只是开始。

规范化怎么做？ 建立一套监控和报警机制,需要持续关注几个核心指标：

• 内存使用率：这是重中之重，设置一个阈值（比如80%）,超过就报警。
• 连接数：看看是否有很多闲置连接或者连接数是否接近上限。
• 慢查询：Redis可以记录执行时间超过设定阈值的命令，定期检查慢查询日志，能发现哪些业务代码用了不合适的命令（比如一次查询几百条数据的hgetall）,从而进行优化。
• 网络流量：观察输入输出流量是否正常,有没有异常暴增。

把这些指标用监控工具（如Prometheus+Grafana）展示出来,让人一眼就能看清Redis的健康状况。

让Redis架构不乱套，核心思想就是“规范”和“规划”，通过规范的键名设计管理数据，通过合理的实例拆分隔离风险，通过超前的容量规划和监控预警来保证稳定性，把这些事儿做到位，Redis才能真正成为你系统里可靠的性能加速器,而不是一个随时会引爆的炸弹。