约束和唯一性保证

约束和唯一性保证

DB的唯一性约束：如用户名或电子邮件地址必须唯一标识一个用户，而文件存储服务中，不能有两个具有相同路径和文件名的文件。若在写数据时强制执行此约束（如若两人同时创建一个具有相同名称的用户或文件，其中一个将返回一个错误），也需线性一致性。

这种情况实际上类似于一个锁：当一个用户注册你的服务时，可以认为他们获得了所选用户名的 “锁”。该操作与原子性的比较与设置（CAS）非常相似：将用户名赋予声明它的用户，前提是用户名尚未被使用。

若想确保：

• 银行账户余额永不会为负

• 不会出售比仓库里的库存更多的物品

• 两个人不会都预定航班同一时间的同一位置

这些约束条件都要求所有节点都同意一个最新值（如账户余额，库存水平，座位占用率）。

有时也能宽松处理这些限制（如若航班超额预订，可将客户转移到不同航班并为其提供补偿）。这时可能不需要线性一致性。

但硬性唯一约束（关系型DB的主键约束）需保证线性一致性。其他类型的约束，如外键或属性约束，可不需要线性一致性。

2.2.3 跨信道的时序依赖

注意图-1细节：若 Alice 没有惊呼得分，Bob 就不知道他的查询结果陈旧。他会在几s后刷新页面，最终看到最后分数。由于系统中存在额外信道（Alice 的声音传到 Bob 耳朵），线性一致性的违背才会被注意到。

计算机系统也有类似情况。假设用户可上传照片，有后台进程调整照片大小，降低分辨率以加快下载速度（缩略图）。该系统的架构和数据流如图-5：

图像缩放器需明确指令执行大小调整，Web服务器通过MQ发送指令。 Web服务器不会将整个照片放队列，因为大多MQ都针对较短消息而设计，而一张照片空间占用可能几M。因此，先将照片写入文件存储服务，写完后，把调整指令放入MQ。

若文件存储服务线性一致，则该系统能正常工作。若不是，则存在竞争风险：MQ图-5中的步骤3、4）可能比存储服务内部的复制更快。此时，当调整模块读取图像（步骤 5)，可能看到图像旧版本或啥都没。若它处理旧版本图像，则文件存储中的全尺寸图和缩略图就产生永久不一致。

问题是 Web 服务器和缩放器之间存在两个不同信道：文件存储与MQ。没有线性一致性的最新保证，这两个信道之间存在竞争条件。这类似图-1：数据库复制通道， Alice 的嘴到 Bob 耳朵之间的真人音频信道，之间也存在竞争条件。

线性一致性也不是避免这种竞争条件的唯一方法，但最容易理解。若能控制额外信道（如MQ 案例，而不是在 Alice 和 Bob 案例），则可使用在 “读己之写” 讨论过的类似方法，不过会有额外复杂度代价。