高效建模实践：使用Redis Hash结构存储对象字段，避免String序列化开销；设置合理的TTL过期时间，结合AOF持久化+RDB快照，实现缓存与持久化平衡；采用Pipeline批量操作和Lua脚本原子执行，减少网络RTT，提升系统响应速度至毫秒级。

Redis数据建模基础

在Redis中，选择合适的数据结构是高效建模的关键。对于频繁读写的用户数据，推荐使用Hash类型，每个用户一个Hash key，字段存储属性值，如hset user:100 name "张三" age 25。这样比String存JSON快很多，因为Hash内部是ziplist或hashtable优化。

缓存穿透与雪崩优化

解决缓存穿透：布隆过滤器预判不存在key；缓存雪崩：随机偏移TTL，如set key value ex 3600 + random(0,300)。持久化用AOF everysec模式，RDB 5分钟快照，混合策略下QPS从10w降瓶颈到50w，响应时间稳定20ms内。

Pipeline与Lua脚本实践

单次操作网络来回慢，用Pipeline打包多命令：redis-cli --pipe发送hmget、expire等，吞吐翻倍。Lua脚本如：local key=KEYS[1] redis.call('HMSET',key,'a',ARGV[1],'b',ARGV[2]) redis.call('EXPIRE',key,3600) return 1，一条命令原子执行，避免并发问题。

持久化性能调优

AOF appendfsync everysec，fsync每秒一次，丢失1s数据，性能高；RDB save 900 1 300 5 60 10000，渐进式快照不阻塞主进程。结合主从复制，读写分离，Slave只读，Master持久化，主节点QPS 20w+无压力。

热点key与集群实践

热点key用本地缓存如Caffeine兜底，或Redis Cluster分片均匀分布。建模时key设计如user:region:hashid:uid，避免单key热点。集群下Twemproxy或Codis代理，横向扩展，系统响应从500ms降到50ms。

监控与运维

用Redis info、latency doctor监控慢查询；Prometheus+Grafana dashboard，关注used_memory、evicted_keys。压力测试ab -n 100000 -c 100，优化后P99 latency <100ms。

FAQ
Q: Redis持久化会影响性能吗？
A: 是，但everysec模式下影响小，<1ms/op，结合RDB定期备份。
Q: 如何避免缓存击穿？
A: 互斥锁或setnx实现单线程加载，逻辑过期+异步续期。
Q: Hash适合所有场景吗？
A: 小对象是的，字段多时用多个小Hash拆分。
Q: 集群怎么选key分布？
A: CRC16(key)%slot，业务key加前缀hash标签均匀。