也谈数据库与缓存一致性

最近有跟一些面试官谈到数据库与缓存一致性的问题，感觉每个人好像看法都不同，所以这里写一些自己的看法，不一定完全正确，但是有助于思考。另外吐槽下当前八股成风的氛围，中国这么多年来，很多技术被外国卡脖子不是没有原因的，雪崩之下，没有一片雪花是无辜的，内卷之下，每个技术人员都是始作俑者。废话不多说，上菜…不是，上干货。

说到数据库与缓存一致性，目前我所知道的两种比较适合作为面试答案的方法分别是：延迟双删 和 binlog同步，但是！一般的业务场景，真的没必要用这两种方式。

原因是

1、延迟双删策略需要开发人员预估一个合适的延迟时间，这个延迟时间要根据业务来定，但是一旦加上，必然会对系统的性能与吞吐量造成影响，有方案说第二次删除可以异步处理，那么如何保证这个异步能够成功，势必引入更复杂的机制（参考：https://www.cnblogs.com/rjzheng/p/9041659.html）。如果复杂到这种程度，与其从技术上寻求突破点，不如考虑下业务上是否有妥协的可能，比如《大型网站技术架构》中提到的12306的例子，分时段售票的业务妥协，比死扣技术解决方案效果更明显，毕竟在那种业务场景下，阿里的技术也扛不住。

2、binlog同步的方案，除了上面那篇文章中最后提到的canal，笔者在美团还用过databus，不过当时不是用来保证缓存一致性的。这种方案的延迟应该可以保证在毫秒级别，已经算是比较有效的方案了，但是一般这种是要借助MQ的，同第一点，这就引入了新的复杂性，而且这种方案也确实太重了，权衡一下收益，真的是有必要的么？

至于我的观点是

1、对于数据库与缓存一致性这个老生常谈的问题，目前的所有方案都只能是最终一致，区别只是时间长短而已，所以理论上，所有的方案，都可以找到数据不一致的场景，在这个问题上没有银弹，只能选择适合自己业务的方案，在时效性和复杂度之间找平衡（所以我极度讨厌别人上来就问xxx问题应该怎么解决，脱离业务场景谈方案都是耍流氓）。

2、一般的业务场景，既然选择了缓存，就必然要接受一定的不一致性，因为操作数据库和操作缓存毕竟不是一个原子操作，也许，当有一天技术上能够保证两个操作原子性的时候，才有真正意义上的数据库与缓存的强一致。

所以，最简单的方案（但不一定是最适用），设置一个业务可接受的缓存过期时间，采用操作数据库-删缓存的方案，如果考虑主从同步的问题，可以设置查询强制走主库，应该足够应付大部分业务场景了，如果真的不能满足，应该考虑的是要不要调整业务模型，而不是弄一个很复杂的技术方案，因为系统复杂了，出问题的概率就会变大。

写在最后，技术的价值是解决问题，是工具与手段，但解决问题的方法不一定只靠技术，更不是说系统设计复杂了技术就好，何况优秀的架构，从来不是设计出来的，而是演化出来的。

与标题无关：最近的处境比较尴尬，虽然觉得跳到坑里了，不过回不到内卷的互联网圈也许也不是坏事，以前更多考虑的是逃避环境，现在可以试试挑战环境了。