你有没有过这样的经历？在某个热门景点抢门票，页面显示还有几张，点进去却提示已售罄。刷新几次，数字还在变来变去，搞得人心烦意乱。这背后其实就涉及到一个技术难题——缓存机制与数据库一致性。
为什么要有缓存？
像景区预约、火车票查询这类系统，每秒都有成千上万的人访问。如果每次请求都直接查数据库，服务器早就扛不住了。于是，系统会把热门数据先“复制”一份放到内存里，这个临时存放地就是缓存。读取速度快，压力小，用户体验也更流畅。
比如你打开某出行App查看杭州西湖的开放时间，这个信息不会每次都去数据库翻一遍，而是从缓存中快速取出。可问题来了：万一管理员刚刚修改了开放时间，缓存里的还是旧数据，怎么办？
缓存和数据库不一致，麻烦就来了
设想一个场景：你朋友抢到了某博物馆的最后两个名额，他也看到了，你也看到了。但你们同时下单，结果系统只允许一个人成功。这种“看到有，实际没有”的情况，往往是缓存没及时更新导致的。
技术上讲，这就是缓存与数据库之间的数据不一致。理想状态是：数据库一改，缓存立刻同步。但现实中网络有延迟，操作有顺序，稍不注意就会出岔子。
常见的应对方法
一种做法是“先更新数据库，再删缓存”。比如景区关闭时间调整后，系统先改数据库，然后主动把缓存里的旧信息删掉。下次有人查，就会重新从数据库拿最新数据，填进缓存。
但这中间有个时间窗口：数据库已经改了，缓存还没删或已删但还没重建，这时候请求进来，可能读到的是旧缓存，或者穿透到数据库造成压力。
为减少这个问题，有些系统采用“双写策略”：改数据库的同时也改缓存。听起来靠谱，可一旦其中一个失败，两边又对不上了。
加个“保险”：延迟双删
更稳妥的做法是在删除缓存后，等一会儿，再删一次。比如第一次删完缓存，过几百毫秒再删一遍。这样能覆盖大部分因并发导致的脏数据残留。
还有一种思路是给缓存设个短有效期。比如门票余量只缓存1秒，过期自动失效。虽然频繁访问数据库，但保证了数据不会太旧。
代码示例：简单的缓存更新逻辑
// 伪代码示例：更新数据库并清除缓存
function updateTicketCount(museumId, newCount) {
// 1. 更新数据库
db.update('museums', { id: museumId, ticket_count: newCount });
// 2. 删除缓存中的对应条目
cache.delete('museum_tickets_' + museumId);
// 3. 可选：延迟一段时间再次删除（延迟双删）
setTimeout(() => {
cache.delete('museum_tickets_' + museumId);
}, 500);
}这些机制听起来复杂，目的只有一个：让你看到的信息尽量准确。尤其是在节假日高峰期，系统能在速度和准确之间找到平衡，靠的就是这些细节设计。
下次你在App上顺利抢到票，别忘了背后有一整套缓存机制在默默工作，努力让每个人看到的数据尽可能一致。