内容简介：这里是Z哥的个人公众号每周五早8点 按时送达当然了，也会时不时加个餐～
这里是Z哥的个人公众号
每周五早8点 按时送达
当然了，也会时不时加个餐～
我的第「78」篇原创敬上
今天来加个餐，紧急纠正一个错误。先和大家说一声抱歉：D
昨晚睡觉前，惯例打开「订阅号助手」回复一些留言。有一位小伙伴提了一个问题，问题来源于《分布式系统关注点》专题的第17篇《先写DB还是「缓存」？》中。
下面就是提出问题的这位小伙伴，@L。这次非常感谢他。
文章的原文是这样的：
-------------原文开始 -------------
先DB再缓存
数据库操作成功，缓存操作的失败的情况该怎么解？（ 主要在用到redis，memcached这种进程外缓存的时候，由于网络因素，失败的可能性大增 ）
办法也是有的，在操作数据库的时候带一个事务，如果缓存操作失败则事务回滚。大致的代码意思如下：
begin trans
var isDbSuccess = write db;
if(isDbSuccess){
var isCacheSuccess = write cache;
if(isCacheSuccess){
return success;
}
else{
rollback db;
return fail;
}
}
else{
return fail;
}
catch(Exception ex){
rollback db;
}
end trans
如此一来就万无一失了吗？并不是。除了由于事务的引入，增加了数据库的压力之外，在极端场景下可能会出现rollback db失败的情况。是不是很头疼？
解决这个问题的方式就是 write cache的时候做delete操作，而不是set操作 。如此一来，用多一次cache miss的代价来换rollback db失败的问题。
就像图上所示，哪怕rollback失败了，通过一次cache miss重新从db中载入旧值。
-------------原文结束-------------
如果没看出来问题或者已经遗忘的小伙伴可以去原文地址看下： 分布式系统关注点——先写DB还是「缓存」？
也不知道当时咋了，脑子昏了。其实 这里的「rollback db失败」表述应该换成「commit db失败」 。
而且顺带图也画错了……
正确逻辑图应该是这样。
虽然数据库操作有XA规范的保证，但是由于需要进行二次确认，而确认又需要经过网络，所以在网络不稳定的情况下，的确会出现commit失败的情况。
这个时候delete的好处就出来了。
假如真的commit失败了，最多就是从db里再捞一份旧数据出来。
而 如果使用set的话，缓存中就会存在脏数据了，必须得再多做一次set，将旧数据set回去。并且，这个操作还有可能出现失败。
好了，这次要说的就那么多，周五早上8点再见吧：D
推荐阅读：
-
8个月打磨，一份送给 程序员 的「分布式系统」合集
原创不易，如果你觉得这篇文章还不错，就「 在看 」或者「 分享 」一下吧。鼓励我的创作 ：）
如果有希望我写一下什么主题的话，欢迎在后台给我留言哦～
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「 阅读原文 」
以上所述就是小编给大家介绍的《纠正一个错误，分布式系统关注点第17篇》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
程序员2010精华本
程序员杂志社 / 电子工业 / 2011-1 / 49.00元
《程序员(2010精华本)》主要内容：《程序员》创刊10年来，每年末编辑部精心打造的“合订本”已经形成一个品牌，得到广大读者的认可和喜爱。今年，《程序员》杂志内容再次进行了优化整合，除了每期推出的一个大型专题策划，各版块也纷纷以专题、策划的形式，将每月的重点进行了整合，让内容非常具有凝聚力，如专题篇、人物篇、实践篇等。另外杂志的版式、色彩方面也有了很大的飞跃，给读者带来耳目一新的阅读体验。一起来看看 《程序员2010精华本》 这本书的介绍吧!
