本文共 1456 字，大约阅读时间需要 4 分钟。

记得那时候，我们一起编写代码，午昼的咖啡杯汽汽蒸蒸。Tomcat一天也装不下多少请求，系统里只有我们两个，闲下来就能聊天。这当也没办法。

我就是大名鼎鼎的MySQL。那时的通信更像邻居间的联络，每次都走一趟网络。

三年后的某天，缓存终于来了。这起先是不过是一个简单的Map，存了一些(key, value)。张大胖写的这个Map，线程安全的，有过期时间。我们都看不起它，只觉得简陋，甚至觉得它没资格成为一个独立的组件。这实在是太可憎了。

更旺师的是，这个简陋的Map竟和Tomcat共享同一个JVM进程。听Tomcat嘲笑它：“你这回事从进程内调用快如闪电，与我比起来你那慢悠悠的SQL查询不者？”

但我心里清楚，缓存的本质从一开始就藏在内部。我为避免频繁访问硬盘，正是运用了程序的局部性原理。这有什么高深吗？

没过多久，系统架构发生了变化。张大胖架起了nginx，为应对高并发，他部署了许多Tomcat和进程内的缓存。我们成了这般样：多台机器，同一个Redis。用户的请求由nginx分发，去往各个Tomcat，各自扒一块缓存。

我看到了机会。一个请求在JVM1中处理完毕，MySQL更新完了数据库，JVM1的缓存也随之变动。但JVM2、JVM3那边的事！数据不一致往往让用户频繁抱怨。

对缓存进行了各种改良，张大胖如何通知各个JVM的变化？这很难说。网络传输的延迟总有其不可避免性。当JVM1即将通知JVM2和JVM3，用户的请.AudioRequest就被发出去了。这种情况下，数据不一致依然存在。

更棘手的是定时更新的缓存。数据和数据库的时间窗口几乎无法缩短。除非数据变化极为缓慢，否则这在大并发下几乎成为了死循环。

后来，我们开始使用Redis。把缓存从进程内搬到了进程外。它独占一套服务器，让几个Tomcat可以共享使用。这比之前的进程内缓存好用了许多。

原先我对Redis质疑：“你这得依靠网络访问，与我何其不同？”它却说：“我们一样，都是内存访问，只是网络因素增加了延迟。”

这番话说实话，别无可奈。同时，Redis并未放弃原有的缓存特性，在内存中存储数据，访问超级快速。这优势很明显。

但问题依然存在。那次突如其来的高并发访问很快给我们交上象棋。压力测试后，我们发现Oracle的数据与Redis的数据不一致。

参之至臻的 metodology，传统的双写方式在高并发下难以取用。就算解决这个难题，还有另外一个大问题：多个线程同时修改同一个数据。因此，我们决定停止关注细节，专注于解决方案。

“直接在MySQL修改数据后，不再更新缓存。”这或许是更简便的方法。我向Redis提出：“当你需要进行改动时，不要立即同步更新你这里的数据。一旦确定，只要访问数据库就能得到最新信息。”这逻辑听起来不错。

但我心里总觉得这可能不是终点。在必须同时修改数据库和缓存的情况下，如何避免数据不一致？这我的思维能否真的解决这个难题？时间拨指向未来，我们得面对实践的结果。

最终，我们开始采用所谓的“缓存侧移模式”。当进行数据修改时，不再更新缓存。原本的Tomcat就无需等待缓存更新，而是断开的情况下直接从数据库查询。这种方法虽然看起来简单，但是在并发场景下，可能会导致资源浪费。但很快，我们发现信息源是否可靠更为重要。最后只能将焦点放在数据最权威的来源——数据库上。

经过这些波折，我明白了缓存在系统中的重要性。它许多时候沦为数据存储的附属角色，却要承担着节省资源和提高性能的奠基作用。这或许就是它存在的价值。