不要立刻检讨刚做过的工作，也不要立刻读刚写过的数据。绝对不要为了验证而立刻读刚写过的数据。为了近期内的运维须要，可以把数据存储在当地或散布式的缓存中。验证工作相对于不太可能涌现的故障来说成本更高。这种运动有悖于有用扩大的需求。

绝对不要为了验证数据而立刻读刚写入的数据，而要读并处置与写操作相干的毛病。把数据存储在当地可以避免对方才写入的数据的其他读操作。

木工有句名言:“量两次，锯一次。”你可能从中学的木匠先生那边听过这句话一他可能还缺了根手指。抛开少手指这事不说，这句名言照样很有事理的，正所谓实践出真知。最好在切割前验证测量的精确度，因为毛病的测量成果会导致临盆糟蹋，例如切出一块年夜小纰谬的木板。我们当然不会那么做。然而，我们所要强调的是如何削减另一种糟蹋，即立刻验证刚写入的数据。

在曩昔的几年中，我们发明本身经常会问客户:“读并验证刚写人的数据，你以为这真的有意义吗?”这种问题出的率令我们受惊。有时，客户的来由很充足，但没有一条是我们认同的。平日，客户看起来就像是那种被就地抓住的知道本身做了不应做的事的孩子。那些对答复经由沉思熟虑(固然在我们看来是损坏了价值)的客户声称，他们的运用须要绝对确保数据不只是被写入了，还要写得准确。但要记住，我们绝年夜多半客户都有SaS或商务平台，他们不是在运行核电站，也不是要把人类送往太空，更不是在掌握几千架客机的升降或治疗癌症。对于写错或者盘算错数据的恐怖，一向都是消耗开辟者额外时光的主因。这种恐怖在盘算的早期成长阶段可能还算合理，Tanden和Stratus公司分离在20世纪70年月末期和80年月初期设计容错盘算机就与这种恐怖有着定的关系。这种体系的重要意图是削减体系的平均故障时光(MTTF)，采取的办法是“冗余一切”，即包含CPU、存储、内存、内存路径和存储路径等在内的所有装备都有冗余。这种模子必需对并行盘算和存储的体系的成果进行比较，能力验证体系在准确运行。本书的一位作者曾经为一台年月长远的Stratus小型盘算机开辟过运用，在他为此工作的两年中，该体系从来没有涌现过两个处置器间的盘算毛病，也没有涌现过写内存或硬盘的毛病。

如今，这种恐怖已经比20世纪70年月末期和80年月初期少多了。事实上，对那些刚写入数据就要履行读操作的客户，当我们问起他们平日是多长时光会发明一次毛病时，他们答复得都相当一致，都说从来没有发明过。问题是，除非对因为写操作发生的毛病数据进行操作时产生了问题，不然他们绝对不会发明毛病。当然，数据破坏也经常产生，然则年夜多半情形下，只有在真正的写操作时能力发明这种数据破坏。与其投入两倍的工作量，从而让存储、数据库和体系事务减半，不如看看操作返回的毛病代码，进行恰当的处置。这里弥补解释一下，数据破坏的最佳掩护办法是准确地做到高可用性，在备用数据库或复制存储装备上保留多个数据副本。最幻想的情形是最终实现多个及时站点。

当然，并非所有的“写后立刻读”的操作都是因为过火细心的法式员为了验证刚写入的数据而发生的。有时，也可能是最终用户要求了刚写人的数据。这里，我们不禁要问:为什么这些客户不把常用的(包含已写入的)数据保留在当地呢?假如刚写入某些数据，并且很可能会再用到这些数据，那么最好把它保留在当地。这种情形一个常见的例子是很多产物中的注册流程。平日，在把用户数据保留为永远注册记载之前，有一个阶段会把这些数据出现给用户。另一个例子，是很多电子商务站点应用购物车实现的购置流程。无论哪哪种情形，假如你在写入的数据未来还会被用到，那么最好把它们在当地保存一份。关于若何进行缓存以及缓存哪些数据。

前面阐述的重点是要获得一个结论，即反复操作会下降有用扩大的才能。事实上，它会造成事务成本加倍。是以，假如你的解决计划要规避由毛病的写操作带来的几百万美金的丧失，那可能须要几万万的额外基本举措措施作保障。依据我们的经验，即使在编程时光和基本举措措施上投资了，也没方法完整避免这种风险。在年夜多半情形下，写后即读的操作都是欠好的，因为它不只让成本翻倍，限制了扩大性，并且还不克不及下降风险，从而使成本与收益不相当。毫无疑问，也许会有须要这种操作的处所，然则比拟浩瀚技巧团队和公司验证过的最佳实践来说，这种情形少之又少。

仔细的读者可能已经发明，我们的原则中存在冲突。须要当地存储的信息代表状况，确定须要跟办事器坚持一致才有效。从宏不雅角度说，我们赞成这种说法，假如必定要做个选择，那么我们会只开辟无状况的运用，以确保不会涌现写后即读的操作。这解释，我们的原则是惯例的，是“平日如斯”的，而不是特定的或“独一准确”的。绝对不要反复你的工作，绝对要保护年夜型的无状况运用。这两种说法有冲突吗?是的。那么冲突可以解决吗?当然要想解决这一原则冲突，就要站在很高的角度来看。我们既想让体系不糟蹋资本(如写后即读读)，想让体系是无状况的。要实现这一点，我们决议绝对不会为了验证而读数据。我们也赞成，有日时为了速度和扩大，我们也愿望坚持亲密关系，而不去读刚写人的数据。这意味着须要保护一些状况信息，然则我们可以把它限制在某些事务中，在这些事务中读刚写入的数据是需要的。固然这种办法有悖于我们介绍的原则，然则假如这种办法在有限的操作中引1人了状况，从而下降了成本，增长了扩大性，那么它也是可行的。

与所有原则一样，总有破例的情形。假如你存在于一个受掌握的情况中，请求必需对10096的写入数据进行验证，然后加密、备份，你应当怎么做呢?我们不肯定是否存在如许的情况，然则假如它存在，就必定要知足它的请求，例如不克不及阻拦写后即读的操作。为了削减写后即读的操作且不阻拦用户生意业务，下面列出了一个问题清单以及你能采取的步调。

治理请求/司法请求。这个动作是治理请求或者司法请求的吗?假如是，你肯定本身懂得得准确吗?很少会有请求明白说你要做的与用户生意业务一致。即使如许说了，如许的请求也很少(可能是绝对不)实用于所有操作的。

竞争性差异。这个动作具有竞争性差异吗?请当心答复，假如谜底是“是的”，那么这个谜底太一般化了，并且平日是毛病的。斟酌到你所估计的毛病产生的概率很小，你的竞争敌手不进行次检讨而造成的毛病只占所有毛病的0.001%，那么即使你准确规避了这些毛病，也很难令人信任你能克服敌手。

异步完成。假如出于治理请求(固然令人疑惑但仍是可能的)或竞争性差异(毫无疑问弗成能)，必需写后即读，那么可以斟酌。

在当地写入，不中止生意业务。网站制造处置故障的办法许多，可以经由过程日记重建数据，然后再从处置队列中从新履行，最糟糕的情形是请求用户再输入一次数据，这种情形产生的概率很小。假如故障产生在为了实现高可用性而向长途数据备份复制数据的进程中，那么只须要从新申请谁人记载或生意业务即可。在任何情形下，都不要因为要向两个数据源同步写入数据而中止用户生意业务。