1. Redis单线程模型的高效秘密Redis的单线程模型经常让初学者感到困惑——为什么一个单线程的程序能支撑每秒十万级的请求这背后其实是一套精妙的设计哲学。我自己在电商系统开发中就深刻体会过它的威力当时用单实例Redis扛住了双十一秒杀活动的流量洪峰。先说内存操作这个最直接的优势。内存的访问速度是纳秒级的而SSD硬盘是毫秒级机械硬盘更是到了10毫秒级别。这意味着Redis的每次读写操作都比传统数据库快了几个数量级。但内存操作只是基础真正的魔法在于I/O多路复用技术。在Linux系统下Redis默认使用epoll机制。简单来说epoll就像个超级高效的前台接待员。当10万个客户端同时连接时传统多线程模型需要开10万个线程来接待而epoll让单个线程就能同时监控所有连接。我做过实测在8核服务器上单线程Redis处理简单GET/SET请求能达到12万QPS而开启多线程后性能提升不到15%反而增加了复杂度。单线程还有个意想不到的好处完全避免了锁竞争。记得有次排查一个Java系统的性能问题发现30%的CPU时间都花在了锁等待上。而Redis的所有操作都是原子性的比如DECR命令减库存时完全不用担心并发问题。不过要注意这里的原子性是指命令级别的多个命令的事务并不能保证原子性这个后面会详细讲。2. 缓存异常三剑客的破解之道2.1 缓存雪崩多米诺骨牌效应去年我们系统就遭遇过一次典型的雪崩事故。当时给一批缓存设置了相同的1小时过期时间结果到期瞬间数据库QPS直接飙升到5万导致整个系统瘫痪。后来我们摸索出几个实用方案第一个是错峰过期策略。不要用固定的过期时间而是在基础值上增加随机浮动。比如expire_time 3600 random.randint(0, 600) # 1小时±10分钟第二个是多级缓存架构。我们在应用层加了本地缓存用Guava Cache做一级缓存Redis作为二级缓存。这样即使Redis集群挂掉系统还能撑一段时间。关键配置如下CacheBuilder.newBuilder() .maximumSize(10000) .expireAfterWrite(5, TimeUnit.MINUTES) .build();2.2 缓存穿透如何防御空气攻击有个恶意爬虫曾经用不存在的用户ID疯狂请求我们的接口导致大量请求穿透到数据库。后来我们用布隆过滤器完美解决了这个问题。具体实现是这样的启动时把所有合法用户ID加载到Redis的布隆过滤器查询前先用BF.EXISTS检查对于确实不存在的key也缓存一个空值比如NULL并设置较短过期时间实测下来这个方案拦截了99.9%的非法请求。布隆过滤器的内存开销也很小100万个元素只需要约1MB内存。2.3 缓存击穿热点数据的保护策略某次明星离婚事件导致我们娱乐频道的热点新闻缓存被击穿。后来我们采用双重检查锁的方案先用GET检查缓存如果不存在则用SETNX抢锁抢到锁的线程去重建缓存。核心代码如下def get_data(key): data redis.get(key) if data is None: if redis.setnx(key:lock, 1, 10): # 获取分布式锁 try: data db.query(...) redis.setex(key, 3600, data) finally: redis.delete(key:lock) else: time.sleep(0.1) return get_data(key) # 重试 return data3. 持久化机制的深度抉择3.1 RDB内存的快照艺术RDB就像给Redis数据拍照片。我们在游戏服务器上用RDB做每日存档配置如下save 900 1 # 15分钟至少有1个key变化 save 300 100 # 5分钟至少有100个key变化 save 60 10000 # 1分钟至少有10000个key变化但要注意RDB保存时fork出的子进程可能导致瞬间延迟。有次我们的Redis实例用了20GB内存fork耗时达到2秒导致部分请求超时。解决方案是控制单个实例的内存大小或者改用AOF。3.2 AOF操作日志的可靠性金融类业务我们推荐使用AOF配置为appendfsync everysec # 每秒刷盘 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb曾经遇到过一个坑AOF文件增长到50GB后重写操作卡死了服务。后来我们改为定时在低峰期手动执行BGREWRITEAOF并监控文件大小。3.3 混合持久化Redis 4.0的最佳实践现在的生产环境我们基本都用混合模式aof-use-rdb-preamble yes这样既保证了恢复速度又能获得AOF的安全特性。恢复时先加载RDB部分再重放AOF日志速度比纯AOF快10倍以上。4. 集群化部署的实战经验4.1 主从复制读写分离的陷阱我们曾经在社交APP上吃过亏——把粉丝关系数据放在从库读取结果用户刚关注某人后刷新页面发现没生效。这是因为主从同步有延迟解决方案有几种对一致性要求高的操作强制走主库使用WAIT命令阻塞直到同步完成监控复制延迟延迟过大时告警4.2 Redis Cluster数据分片的智慧Cluster模式我们跑了三年总结几个关键点每个节点内存建议不超过20GB避免大key会导致数据倾斜使用-c参数启动客户端自动处理MOVED重定向定期检查集群状态redis-cli --cluster check 127.0.0.1:70004.3 跨机房同步方案对于多机房部署我们开发了基于redis-dump和redis-restore的同步工具配合Kafka做数据中转。关键命令redis-cli -h source_host --scan | while read key; do redis-cli -h source_host --raw dump $key | \ kafka-console-producer --topic redis_sync done5. 内存优化的十八般武艺5.1 淘汰策略的选择我们电商平台用的是volatile-lru只淘汰设置了过期时间的key。配置示例maxmemory 16gb maxmemory-policy volatile-lru而内容推荐系统用的是allkeys-lfu因为需要根据访问频率保留热门内容。5.2 大Key拆分技巧遇到过存储用户关系链的Hash key达到500MB导致迁移时超时。后来拆分为user:relations:1000 - user:1000:followers:{shard_id}用CRC16算法做分片shard_id crc16(user_id) % 10245.3 内存碎片整理Redis 4.0以后支持自动碎片整理activedefrag yes active-defrag-ignore-bytes 100mb active-defrag-threshold-lower 10我们设置每天凌晨低峰期执行MEMORY PURGE碎片率从1.8降到了1.1。