"牺牲"不等于什么都不做：分区期间记日志，为恢复后收敛做准备

CAP理论说三者只能取二、必须”牺牲”另一个，但”牺牲”这个词很容易被误解成”什么都不做”，实际上CAP所说的牺牲，只是指在分区持续期间无法同时保证C和A，并不代表系统从此彻底放弃另一个属性。而且从时间尺度看，一个系统整个运行周期里绝大多数时间都是正常的，真正发生分区的时间占比其实很小——比如99.99%可用性（俗称4个9）的系统一年下来不可用时间只有约50分钟，99.999%（5个9）一年下来只有约5分钟，分区期间放弃C或A，绝不等于永远放弃它们，而是可以在分区期间做一些操作，让分区故障恢复后系统重新收敛回CA状态。最典型的做法是分区期间记录日志，等分区恢复后据此做数据恢复。以[[CAP关注的粒度是数据，而非整个系统]]提到的用户管理系统为例：假设用户账号数据选了CP，分区发生后节点1可以继续接受新用户注册，节点2则不行（收到注册请求会直接返回error，这正是不满足A的地方），此时节点1把这些暂时无法同步给节点2的新注册记录写进日志；分区恢复后，节点1读取日志、把这些记录同步给节点2，同步完成后两个节点就重新回到了CA状态。如果用户信息数据选了AP，情况会不太一样：分区发生后节点1和节点2都可以继续接受用户信息的修改，两边完全可能改出不一样的结果（比如用户在节点1把爱好改成”旅游、美食、跑步”，同时在节点2把爱好改成”美食、游戏”），两边各自把未同步的修改记下来；分区恢复后，系统要按某种规则合并这些冲突数据——可以是”最后修改优先”（结果取”美食、游戏”）、可以是”字数最多优先”（结果取”旅游、美食、跑步”），也可以直接把冲突暴露出来交给人工判断该采用哪一份。