CAP关注的粒度是数据，而非整个系统

Eric Brewer在《CAP理论十二年回顾》里提到一个极易被忽略但至关重要的细节：”C与A之间的取舍可以在同一系统内以非常细小的粒度反复发生，每一次的决策可能因为具体的操作、乃至因为牵涉到特定的数据或用户而有所不同。”这句话点出了一个常见误解：因为CAP理论的定义和解释都用system、node这类系统级的词汇，很容易让人误以为架构设计时要给整个系统统一选定CP或AP，但现实中一个系统几乎不可能只处理单一类型的数据，不同类型的数据往往有截然不同的一致性/可用性要求——有的数据必须选CP，有的数据必须选AP，如果非要从”整个系统”这个粒度去做单一选择，结果必然是顾此失彼，不管选哪边都会有某些数据的场景不适用。以一个最简单的用户管理系统为例：它同时包含用户账号数据（用户ID、密码）和用户信息数据（昵称、兴趣、性别、自我介绍等）——用户账号数据通常要选CP（密码不一致会直接导致登录判断出错，属于不可接受的场景），用户信息数据通常可以选AP（自我介绍暂时没同步到最新，业务影响很小）；如果把整个系统限定为CP，会不符合用户信息数据这类容忍度更高的场景；如果限定为AP，又会不符合用户账号数据这类要求严格的场景。因此在CAP理论真正落地时，正确的做法是先把系统内的数据按不同的应用场景和一致性要求分类，再针对每一类数据分别选择CP或AP策略，而不是笼统地给整个系统定一个统一策略。