不要当即检查刚做过的事情

不要当即检查刚做过的事情，也不要当即读刚写过的数据。绝对不要为了验证而当即读刚写过的数据。为了近期内的运维需求，可以把数据存储在当地或散布式的缓存中。验证事情相对于付不太能够泛起的故障来讲本钱更高。这类勾当有悖于有用扩展的需求。
绝对不要为了验证数据而当即读刚写入的数据，而要读并处置与写操纵相干的毛病。把数据存储在当地可以制止对刚刚写入的数据的其余读操纵。
木匠有句名言:“量两次，锯一次。”你能够从中学的木匠老师哪里听过这句话一他能够还缺了根手指。抛开少手指这事不说，这句名言仍是颇有原理的，正所谓实践出真知。最幸亏切割前验证丈量的精确度，由于毛病的丈量后果会招致出产挥霍，比方切出一块大小不合错误的木板。咱们当然不会那末做。然而，咱们所要强调的是怎样削减另外一种挥霍，即当即验证刚写入的数据。
在已往的几年中，咱们发现本身经常会问客户:“读并验证刚写人的数据，你以为这真的有意思吗?”这类问题出的率令咱们受惊。有时，客户的理由很充实，但没有一条是咱们认同的。通常，客户看起来就像是那种被就地捉住的知道本身做了不应做的事的孩子。那些对答复颠末反思熟虑(尽管在咱们看来是粉碎了代价)的客户宣称，他们的应用需求绝对确保数据不仅是被写入了，还要写得正确。但要记住，咱们绝大大都客户都有sas或商务平台，他们不是在运转核电站，也不是要把人类送往太空，更不是在控制几千架客机的升降或医治癌症。对付写错或者计较错数据的恐惊，一直都是消耗开发者分外时间的主因。这类恐惊在计较的早期发展阶段能够还算合理，tanden和 stratus公司别离在20世纪70年代末期和80年代早期设计容错计较机就与这类恐惊有着定的关系。这类零碎的主要用意是削减零碎的均匀故障时间(mttf)，采用的要领是“冗余一切”，即包括cpu、存储、内存、内存途径和存储途径等在内的一切设备都有冗余。这类模子必需对并行计较和存储的零碎的后果进行对比，才气验证零碎在正确运转。本书的一名作者已经为一台年代长远的 stratus小型计较机开发过应用，在他为此事情的两年中，该零碎历来没有泛起过两个处置器间的计较毛病，也没有泛起过写内存或硬盘的毛病。
此刻，这类恐惊已经比20世纪70年代末期和80年代早期少多了。事实上，对那些刚写入数据就要执行读操纵的客户，当咱们问起他们一般为多永劫间会发现一次毛病时，他们答复得都至关一致，都说历来没有发现过。问题是，除非对由于写操纵发生的毛病数据进行操纵时发生了问题，不然他们绝对不会发现毛病。当然，数据毁坏也经常发生，可是大大都情况下，只要在真实的写操纵时才气发现这类数据毁坏。与其投入两倍的事情量，从而让存储、数据库和零碎事务减半，不如看看操纵返回的毛病代码，进行适量的处置。这里弥补注明一下，数据毁坏的最好庇护措施是正确地做到高可用性，在备用数据库或复制存储设备上保留多个数据副本。最抱负的情况是终极实现多个及时站点。
当然，并不是一切的“写后当即读”的操纵都是由于过度仔细的程序员为了验证刚写入的数据而发生的。有时，也可以是终极用户要求了刚写人的数据。这里，咱们不由要问:为甚么这些客户不把常用的(包括已写入的)数据保留在当地呢?若是刚写入某些数据，并且很能够会再用到这些数据，那末最好把它保留在当地。这类情况一个常见的例子是许多商品中的注册流程。通常，在把用户数据保留为永恒注册记载以前，有一个阶段会把这些数据显现给用户。另外一个例子，是许多电子商务站点行使购物车实现的购置流程。无论哪哪一种情况，若是你在写入的数据未来还会被用到，那末最好把它们在当地保留一份。关于怎样进行缓存以及缓存哪些数据。
前面阐述的重点是要获得一个论断，即反复操纵会低落有用扩展的威力。事实上，它会形成事务本钱加倍。因而，若是你的解决计划要规避由毛病的写操纵带来的几百万美金的损失，那能够需求几万万的分外根蒂根基举措措施作保障。按照咱们的教训，即便在编程时间和根蒂根基举措措施上投资了，也无法子彻底制止这类危害。在大大都情况下，写后即读的操纵都是欠好的，由于它不仅让本钱翻倍，限定了扩展性，并且还不克不及低落危害，从而使本钱与收益不相等。毫无疑难，兴许会有需求这类操纵的处所，可是比拟泛滥手艺团队和公司验证过的最好实践来讲，这类情况少之又少。
仔细的读者能够已经发现，咱们的准则中存在抵触。需求当地存储的信息代表状况，必定需求跟服务器连结一致才有用。从宏观角度说，咱们赞成这类说法，若是必然要做个选择，那末咱们会只开发无状况的应用，以确保不会泛起写后即读的操纵。这注明，咱们的准则是通常的，是“通常云云”的，而不是特定的或“独一正确”的。绝对不要反复你的事情，绝对要维护大型的无状况应用。这两种说法有抵触吗?是的。那末抵触可以解决吗?当然要想解决这一准则抵触，就要站在很高的角度来看。咱们既想让零碎不挥霍(如写后即读读)，想让零碎是无状况的。要实现这一点，咱们决议绝对不会为了验证而读数据。咱们也赞成，有日时为了速率和扩展，咱们也但愿连结紧密亲密关系，而不去读刚写人的数据。这象征着需求维护一些状况信息，可是咱们可以把它限定在某些事务中，在这些事务中读刚写入的数据是须要的。尽管这类要拥有悖于咱们引见的准则，可是若是这类要领在有限的操纵中引1人了状况，从而低落了本钱，添加了扩展性，那末它也是可行的。
与一切准则同样，总有破例的情况。若是你存在于一个受控制的环境中，要求必需对10096的写入数据进行验证，而后加密、备份，你应该怎么做呢?咱们不确定是否存在如许的环境，可是若是它存在，就必然要知足它的要求，比方不克不及阻挠写后即读的操纵。为了削减写后即读的操纵且不阻挠用户买卖，下面列出了一个问题清单以及你能采用的步调。

管理要求/法令要求。这个动作是管理要求或者法令要求的吗?若是是，你确定本身了解得正确吗?很少会有要求明确说你要做的与用户买卖一致。即便如许说了，如许的要求也很少(能够是绝对不)合用于一切操纵的。
竞争性不同。这个动作具备竞争性不同吗?请小心答复，若是谜底是“是的”，那末这个谜底太大众化了，并且一般为毛病的。思索到你所预计的毛发病生的几率很小，你的竞争敌手不进行次检查而形成的毛病只占一切毛病的0.001%，那末即便你正确规避了这些毛病，也很难使人信赖你能战胜敌手。
异步完成。若是出于管理要求(尽管使人狐疑但仍是能够的)或竞争性不同(毫无疑难不行能)，必需写后即读，那末可以思索。
在当地写入，不中绝买卖。网站建设处置故障的要领不少，可以经由过程日记重修数据，而后再从处置队列中从头执行，最蹩脚的情况是要求用户再输入一次数据，这类情况发生的几率很小。若是故障发生在为了实现高可用性而向远程数据备份复制数据的过程当中，那末只需求从头申请谁人记载或买卖便可。在任何情况下，都不要由于要向两个数据源同步写入数据而间断用户买卖。