偶然一天在w3cschool上看到的，总结了沈剑老师在公众号上的架构师之路文章。在这里写点笔记
背景：如果dns只解析一个公网ip，那网站的所有入口就只有一台机器，而一台机器里面，nginx的负载是有极限的。所以需要dns层做负载均衡，通过DNS解析出不同的公司IP，实现负载均衡。
缺点：1.没有探活机制，2.生效时间长
怎么找到不合理的反向依赖？
变动方是我，改动是各个业务方。
比如你提供了一个公共的jar包出去给业务方，这个jar包是有可能频繁变动的，此时你的这个jar包每一次升级，都需要重新打包。解决方式，将jar包升级为服务。
这里原文章我看了是觉得有漏洞的。这里补了一下我的理解。
先更新数据库，再删除缓存 ==> 更新缓存失败，出现不一致 (这种我觉得业务上应该用的是最多的，得看业务能不能容忍短暂的缓存不一致情况出现)
先更新数据库，再更新缓存 ==> 更新数据库后，更新缓存前，有并发的更新导致变更值被覆盖。
先删缓存，再更新数据库，再删缓存 ==> 基本上能解决大部分场景的问题，但是如果删缓存失败，会影响业务，并且，如果在第一次删缓存的时候，有并发的请求进来读数据，这时候旧数据就又加载进缓存里面了，相当于白做。
如果真的要非常严格保证数据库和缓存一致，那就在读：读不到缓存，要查库时，加分布式锁。写：加分布式锁。然后先删缓存，再修改数据库数据，最后再删缓存。