复制延迟案例(2)-读己之写

许多应用让用户提交一些数据，然后查看提交的内容。如客户DB中的记录或某主题的评论。提交新数据必须发送到主节点，但当用户读数据时，可能从【从节点】读取。这对读密集和偶尔写入的负载很合适。

但异步复制则有问题，如图-3：若用户在写后马上查看数据，则新数据可能尚未到达副本。对用户而言，看起来好像是刚提交的数据丢了，用户会不高兴。

此时，需“写后读一致性（read-after-write consistency）”，也称读写一致性（read-your-writes consistency）。该机制保证：若用户重新加载页面，他们总能看到自己最近提交的更新。但对其他用户没有任何保证，这些用户的更新可能会在稍后才能刷新看到。

主从复制实现 写后读一致性

若用户访问：

• 可能会被修改的内容，读主

• 否则，读从

这要求实际查询前，就得考虑内容是否可能会被修改。如社交网络上的用户个人资料信息通常只能由用户本人编辑，而其他人无法编辑。简单规则：从主节点读取用户自己的档案，在从节点读取其他用户的档案。

若应用大部分内容都可能被用户编辑，则上面方案就没啥用，因为大部分内容都读主节点，导致丧失读操作的扩展性。就得考虑其他标准来决定是否读主。如跟踪最近更新时间，若更新后1min 内，则总是读主节点。并监控从节点的复制延迟程度，避免对任意比主节点滞后超过一分钟的从节点发出查询。

客户端还可记住最近更新时的时间戳，并附带在读请求中，据此，系统可确保对该用户提供读服务时，都应该至少包含了该时间戳的更新。若当前从节点不够新，可读另一个从节点或一直等待从节点直到收到最近的更新。时间戳可以是逻辑时间戳（指示写入顺序的日志序列号）或实际系统时钟。

若副本分布在多IDC（如考虑与用户的地理接近及高可用性），会更复杂。必须先把请求路由到主节点所在IDC（该IDC可能离用户很远）。

若同一用户从多个设备请求服务，如桌面浏览器和移动APP，就更复杂了。这时，可能就需提供跨设备的写后读一致性，即若用户在某设备输入一些信息，然后在另一个设备查看，则应该看到刚输入的信息。此时，还需考虑：

• 记住用户上次更新时间戳的方法实现更困难，因为一台设备上运行的程序不知道另一台设备上发生啥。元数据需要一个中心存储，做到全局共享
• 若副本分布在多IDC，无法保证来自不同设备的连接会路由到同一IDC。如用户台式计算机使用家庭宽带连接，而移动设备使用蜂窝数据网络，则设备的网络路线可能完全不同。若方案要求必须读主，则首先要确保来自不同设备的请求路由到同一IDC。