Codis生产环境实践经验合集

Codis作者在分享中给出的多条一线运维经验，共同的主题是”分布式系统的可用性不只由核心算法决定，大量细节决定了系统能不能扛住真实故障”：第一，多产品线共用同一套Codis集群时，必须用product_name做逻辑隔离，让不同业务的元数据、监控和迁移互不干扰，避免一个业务的误操作波及其他业务；第二，ZooKeeper必须和使用它的Codis组件部署在同一机房，跨机房访问ZooKeeper是明确的反模式（作者原话是”跨机房，想都别想”），因为ZooKeeper对网络延迟和分区极其敏感，跨机房会显著放大不可用的概率；第三，Codis采用了两层高可用设计——Proxy层的HA用Jodis（基于ZooKeeper的客户端库，能感知Proxy节点的增减）实现，底层Redis本身的HA则用专门的Codis-ha组件实现，两层职责分开、互不耦合；第四，Dashboard作为集中管理组件，必须保证和集群内所有Proxy、Redis节点的网络连通性，一旦连通性出问题，集群的元数据变更和监控会立即失效；第五，队列型数据结构的设计要避免”把所有消息都塞进一个key对应的List”这种反模式，一旦某个业务量暴涨，单个key会成为热点、拖垮所在分片，应当提前做好分片打散；第六，主从Redis做Bgsave（RDB持久化）时会瞬间占用大量内存和CPU，如果主从的Bgsave时间点没有错开，容易造成同时抖动，需要在运维策略上主动错峰调度。这些经验的共同价值在于：它们大多不是Codis特有的问题，而是任何”多组件协同+分片+持久化”的分布式存储系统都会遇到的通用运维陷阱。