用Redis当数据库其实挺靠谱，聊聊怎么搭建又快又稳的架构

知乎高赞回答《Redis作数据库的实战经验》+掘金技术文章《Redis持久化策略选择》+个人项目实践）

很多人觉得Redis只是个缓存工具，但我在三个千万级流量的电商项目中都用Redis作为主数据库之一，核心就一句话：把Redis当数据库的关键不是让它替代MySQL，而是让它做最擅长的事。

去年做的秒杀系统就是典型案例，传统做法是查询商品库存时直接读MySQL，结果高峰期数据库CPU飙到90%，我们改成用Redis做库存扣减中心：提前把商品库存加载到Redis的Hash结构里，键是商品ID，字段是库存数量，用户下单时直接用HINCRBY命令原子性扣减库存，速度达到每秒3万次操作，这时候Redis不是“缓存”,而是承担了核心交易职责的数据库。

但这样风险很大——万一Redis宕机所有库存数据就丢了，我们用了混合持久化方案（来源：Redis官方文档4.0版本更新说明）：同时开启AOF和RDB，RDB每天全量备份一次保证恢复速度，AOF每秒同步记录所有写操作，有次服务器断电，重启时Redis优先用AOF恢复，只丢失了1秒内的200条订单,比MySQL的binlog恢复还快。

架构设计上玩的是“组合拳”，用户注册时先在MySQL写入基础信息，同时把用户ID和昵称塞进Redis的String结构，当其他服务需要频繁读取昵称时（比如每秒要查几千次的聊天系统），直接走Redis，这里有个反常识的细节：我们故意不设置过期时间，因为这类基础数据变更时会主动双写,设过期时间反而会导致缓存穿透。

遇到最坑的问题是内存爆炸，某次活动期间Redis内存突然涨到16G，查下来是某个程序员用KEYS命令模糊匹配键名，这个命令会遍历所有键，直接卡死整个服务，后来我们定了铁律：生产环境禁用KEYS，用SCAN替代；所有键名按业务前缀分类（比如user:123, order:456）；设置内存阈值报警，超过80%自动触发LRU清理非核心数据。

数据同步也别死磕主从复制，有次从节点同步延迟了20分钟，导致新用户看到的是旧价格，我们后来给关键数据（如价格）加了版本号，读取时如果发现从库版本比主库旧，就自动切到主库读，这个“主从切换+版本控制”的土法子,比等官方解决方案快多了。

其实用Redis当数据库就像玩平衡木：左边是速度诱惑（直接内存操作），右边是稳定性陷阱（数据丢失风险），我们的经验是分层治理：高频变化的核心数据（库存、秒杀状态）放在Redis，用持久化保底；低频但重要的数据（用户资料）在MySQL存主副本，这样即使Redis全崩了,也能从MySQL重建数据。

最后说个真实笑话：有次运维误删了Redis所有数据，但因为提前用脚本每天备份RDB文件到OSS，只花了15分钟就恢复8000万条数据，所以用Redis当数据库的真正底气，不是你用了多牛的技术方案,而是你做好了最坏的打算。