CAP理论是讨论分布式系统设计优劣时的老生常谈，最近学习极客时间上周志明的软件架构课，对几个之前以为通透了的理论进行了重新理解与消化，并对过去的错误考虑进行了勘误，有必要重新梳理下。 CAP理论是我接触分布式设计过程中最初遇到的理论之一，最初去了解相关理论的出发点是为了做职级晋升答辩。不同于日常业务开发的关注点为系统的快速设计与落地，答辩更关注对具体问题的思考是否足够科学，推理是否缜密，能否契合具体的业务场景，用相对静态的理论来承接场景。可以说一开始是很不适应的，又经过了1、2年，走到了另一个极端，各种名词不离口（可用性、一致性、性能、安全性、ACID、BASE、鲁棒），但并没有真正的指导开发，也就是说一套做一套，更甚者说了不做，先做再往理论上靠的懒惰行为也有。19、20年以来逐渐找到了以解决问题为导向，行动符合科学理论的感觉，也就是摸索知行合一。

本文从灰度系统的设计背景出发，分别讨论了灰度子系统的主要挑战、实现原理、行业内最佳实践，对灰度子系统在工程实践上的落地做了简单总结。

在高流量的C端业务中常常广泛使用memcache做缓存，而memcached本身不支持分布式，业务上经常会使用客户端分布式算法（一致性hash）保证分布式缓存集群性能和高可用。客户端将多个mc实例维护成一个缓存池，根据缓存key值进行一致性hash计算，写入具体指定的hash节点。由于单机可用性无法保证，若要体现此mc集群的高可用，对于单点故障机器的剔除就十分重要。但目前框架内使用的memcached扩展（也是行业内一致推荐的扩展）却没能很好的完成这一功能（或者是设置上没有正确配置），当集群中一个实例挂掉之后，hash到这台机器上的set、get方法全部失效，没有保证集群层面的高可用。而memcache扩展在出现单节点挂掉的情况下，会把key路由到新的alive节点上，保证集群的可用性。那么问题就来了，为什么在更“新”，更“先进”的memcached扩展内却没有完成如此好特性？是有坑？还是实现上会有问题？值得深究一番。