可用性定义的精确化：合理响应不等于正确响应

可用性（Availability）的定义同样经历了精确化的过程。第一版是”每个请求都能得到成功或者失败的响应”（Every request gets a response on success/failure），第二版改为”非故障节点在合理时间内返回合理响应（不是错误或超时）”（A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout)）。第一处差异是”every request”变成了”a non-failing node”——第一版没说清楚可用性的主语，实际上只有非故障节点才谈得上要满足可用性要求，如果节点本身已经故障了，发给它的请求本来就不一定能得到响应，笼统说”每个请求”是不严谨的。第二处差异更关键：第一版用”success/failure”来定义响应，这个标准太宽泛了——超时算失败、报错算失败、异常算失败、结果不正确也能算失败，几乎任何情况都能被归到”成功或失败”里，等于没有真正约束住什么才叫满足可用性；而第二版换成了两个”reasonable”——合理的响应、合理的时间，并且明确排除了错误和超时。这里有个容易被忽略但极其重要的细节：第二版说的是”合理”（reasonable）而不是”正确”（correct）——比如一个系统本该返回100，实际却返回了90，这依然可以是一个”合理”的响应（不是错误、不是超时、是个正常返回的数值），但它并不是一个”正确”的响应。这个区分正是理解CAP权衡的关键：可用性只保证”给出响应，且这个响应形式上说得通”，并不保证这个响应内容一定是当下最新、最准确的数据——这也是为什么可用性和一致性可以是两件独立的事，牺牲一致性换可用性时，系统依然能给出”合理但不是最新”的响应，而不是直接报错。