内容简介：这里是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篇》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 分布式系统关注点：弹性架构
- 分布式系统关注点：初识高可用
- 分布式系统关注点：“无状态” 详解
- 分布式系统关注点——“无状态”详解
- 分布式系统关注点：“共识” 的兄弟 “事务”
- 分布式系统关注点：如何去实施负载均衡？
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Spark技术内幕
张安站 / 机械工业出版社 / 2015-9-1
Spark是不断壮大的大数据分析解决方案家族中备受关注的新增成员。它不仅为分布式数据集的处理提供一个有效框架，而且以高效的方式处理分布式数据集。它支持实时处理、流处理和批处理，提供了AllinOne的统一解决方案，使得Spark极具竞争力。 本书以源码为基础，深入分析Spark内核的设计理念和架构实现，系统讲解各个核心模块的实现，为性能调优、二次开发和系统运维提供理论支持；本文最后以项目实战......一起来看看 《Spark技术内幕》 这本书的介绍吧!
