——从单机到集群的高可用架构深度解析

核心架构:• Sentinel哨兵:3节点监控集群,自动选举新主节点(故障切换<200ms)• Cluster集群:分片存储+多主架构,支持动态扩容

选型优势:• 数据安全:RDB快照+AOF日志双保险,支持秒级持久化• 功能丰富:原子操作(WATCH/MULTI)、Lua脚本支持• 生态完善:Spring Boot/Python等主流语言无缝集成
适用场景:• 电商秒杀(库存扣减)• 分布式锁(RedLock算法)• 会话存储(需持久化)
局限性:• 大Key(>10MB)需拆分存储• 集群模式下避免使用KEYS命令
2. Memcached:极简主义架构核心架构:• Magent代理:主从同步+故障切换(VIP漂移机制)• Keepalived:虚拟IP自动转移(健康检查间隔5秒)

选型优势:• 极致性能:单节点QPS达20万+(NIO模型)• 冷热分离:LRU淘汰策略自动清理低频数据
适用场景:• 传统企业缓存(如会话存储)• CDN缓存(静态资源加速)
局限性:• 数据完全依赖内存,宕机即丢失• 仅支持字符串类型,复杂业务需二次开发
3. Codis:Redis集群管理专家核心架构:• Proxy层:透明路由+负载均衡(支持动态扩容)• ZooKeeper:分片信息同步+故障检测(session超时30秒)

选型优势:• 平滑扩容:在线调整分片规则,业务无感知• 多租户支持:租户隔离,资源配额可动态分配
适用场景:• 大规模Redis集群(如从3节点扩展到100节点)• 多业务线共享缓存(租户隔离)
局限性:• 分片数量建议为2的幂次(如1024)• 定期执行redis-cli --cluster reshard平衡数据
4. Twemproxy:轻量级代理方案核心架构:• 一致性哈希:数据均匀分布(虚拟节点数建议≥160)• 自动剔除:节点故障30秒后从路由表中移除

选型优势:• 低延迟:C语言实现,单线程模型(QPS上限约10万)• 协议兼容:支持Redis/Memcached双协议
适用场景:• 轻量级缓存代理(如小型服务缓存)• 临时扩容(快速接入新节点)
局限性:• 无法处理业务逻辑(纯代理)• 不支持Lua脚本和事务
5. Pulsar:云原生消息缓存核心架构:• 分层存储:热数据存内存,冷数据转存对象存储(成本降低60%)• 多租户支持:资源隔离(CPU/内存配额可动态调整)

选型优势:• 全球复制:跨地域数据同步延迟<100ms(金融级一致性)• 弹性伸缩:自动扩展Broker节点(K8s部署5分钟完成扩容)
适用场景:• 跨国企业消息同步(如海外支付回调)• 边缘计算(车联网实时数据缓冲)
局限性:• 生态薄弱(监控工具不如Redis完善)• 运维门槛高(BookKeeper组件调试复杂)
三、选型决策路径是否需要持久化?• 是 → Redis(Sentinel/Cluster)• 否 → Memcached是否需要动态扩容?• 是 → Codis/Redis Cluster• 否 → Twemproxy是否需要全球部署?• 是 → Pulsar• 否 → Redis/Codis是否需要简单配置?• 是 → Memcached/Twemproxy• 否 → Redis/Codis四、生产环境关键配置Redis集群:# 启用AOF持久化(每秒同步) appendfsync everysec # 禁用高危命令 rename-command FLUSHALL ""Codis分片:# 扩容示例(增加1个分片) codis-config slot -C 127.0.0.1:9090 reshard 1024 128Twemproxy优化:# 启用自动剔除故障节点 auto_eject_hosts: true # 设置哈希算法为ketama distribution: ketama五、总结建议• 强一致性需求:首选Redis Cluster,次选Codis• 低成本扩容:Codis分片管理更灵活• 全球业务场景:Pulsar跨地域复制优势明显• 轻量级缓存:Memcached/Twemproxy部署更简单
通过明确业务需求(数据一致性、扩展性、运维成本),结合各方案特性,可快速定位最适合的缓存架构。
