MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

缓存失效策略：时间与事件驱动的对比

2023-01-095.9k 阅读

缓存失效策略概述

在后端开发中，缓存是提升系统性能和响应速度的重要手段。然而，随着数据的不断变化和更新，如果缓存中的数据不能及时更新，就可能导致应用程序读取到过期或错误的数据。因此，缓存失效策略至关重要。缓存失效策略主要分为时间驱动和事件驱动两类，它们各自有着独特的工作原理和适用场景。

时间驱动的缓存失效策略

固定过期时间（Fixed Expiration Time）

  1. 原理：为缓存中的每个数据项设置一个固定的过期时间。当数据被存入缓存时，同时指定一个时间点或从存入时刻起经过的时间段作为过期时间。一旦到达这个时间，缓存中的数据就被视为过期，下次读取时如果发现数据已过期，就会从数据源重新获取数据并更新到缓存中。
  2. 优点：实现简单，易于理解和管理。对于一些数据变化频率相对较低且有一定规律的场景，例如新闻资讯、商品静态信息等，使用固定过期时间可以有效地控制缓存的更新频率，减少对数据源的访问压力。
  3. 缺点：如果设置的过期时间过长，可能导致数据长时间得不到更新，应用程序读取到的是陈旧数据；而过期时间设置过短，则会频繁地从数据源获取数据，增加数据源的负载，同时也可能影响缓存命中率。
  4. 代码示例（以Python的Flask应用和Redis缓存为例）：
import redis
from flask import Flask

app = Flask(__name__)
cache = redis.Redis(host='localhost', port=6379, db=0)

def get_data_from_source():
    # 模拟从数据源获取数据
    return "Some data from the source"

@app.route('/data')
def get_data():
    data = cache.get('data')
    if not data:
        data = get_data_from_source()
        cache.setex('data', 3600, data)  # 设置缓存，过期时间3600秒（1小时）
    return data.decode('utf-8')

if __name__ == '__main__':
    app.run(debug=True)

滑动过期时间（Sliding Expiration Time）

  1. 原理：每次访问缓存中的数据时，只要数据未过期，就将其过期时间延长。这样，经常被访问的数据会一直保持在缓存中，而长时间未被访问的数据会逐渐过期。
  2. 优点：对于热点数据，滑动过期时间可以有效地延长其在缓存中的存活时间，提高缓存命中率，减少对数据源的访问。它能够根据数据的访问频率自动调整过期时间，适应数据访问模式的变化。
  3. 缺点：实现相对复杂，需要在每次读取缓存时额外处理过期时间的更新。同时，如果应用程序的访问模式发生较大变化，例如原本的热点数据突然不再被频繁访问，可能导致该数据在缓存中停留时间过长，占用过多缓存空间。
  4. 代码示例（同样以Python的Flask应用和Redis缓存为例）：
import redis
from flask import Flask

app = Flask(__name__)
cache = redis.Redis(host='localhost', port=6379, db=0)

def get_data_from_source():
    # 模拟从数据源获取数据
    return "Some data from the source"

@app.route('/data')
def get_data():
    data = cache.get('data')
    if data:
        cache.expire('data', 3600)  # 每次访问时延长过期时间3600秒
    else:
        data = get_data_from_source()
        cache.setex('data', 3600, data)
    return data.decode('utf-8')

if __name__ == '__main__':
    app.run(debug=True)

事件驱动的缓存失效策略

基于发布 - 订阅（Publish - Subscribe）

  1. 原理：应用程序将数据变化事件发布到消息队列或事件总线，订阅了相关事件的缓存管理器接收到事件后，根据事件信息（如数据的标识）来删除或更新相应的缓存数据。这种方式实现了数据变化与缓存更新的解耦，使得缓存更新操作可以异步进行。
  2. 优点：能够实时响应数据的变化，保证缓存中的数据与数据源的一致性。适用于数据变化频繁且对数据一致性要求较高的场景，如电商的库存管理、金融交易数据等。通过消息队列的异步处理，可以减轻系统的直接负载，提高系统的整体性能和可扩展性。
  3. 缺点：依赖于消息队列或事件总线的稳定性和性能。如果消息队列出现故障，可能导致缓存更新不及时。同时，系统架构变得更加复杂，需要额外的开发和维护工作来管理消息的发布、订阅以及缓存更新逻辑。
  4. 代码示例（以Python的Flask应用、Redis缓存和Redis的发布 - 订阅功能为例）：
import redis
from flask import Flask

app = Flask(__name__)
cache = redis.Redis(host='localhost', port=6379, db=0)
pubsub = cache.pubsub()

def get_data_from_source():
    # 模拟从数据源获取数据
    return "Some data from the source"

@app.route('/data')
def get_data():
    data = cache.get('data')
    if not data:
        data = get_data_from_source()
        cache.set('data', data)
    return data.decode('utf-8')

def data_update_handler(message):
    cache.delete('data')  # 接收到数据更新事件，删除缓存

pubsub.subscribe({'data_update': data_update_handler})
thread = pubsub.run_in_thread(sleep_time=0.01)

if __name__ == '__main__':
    app.run(debug=True)

基于数据库触发器（Database Triggers）

  1. 原理：在数据库层面设置触发器，当数据库中的数据发生插入、更新或删除操作时，触发器会自动触发相应的缓存更新逻辑。通常，数据库触发器会调用外部程序或脚本，通知缓存管理器进行缓存的删除或更新操作。
  2. 优点：与数据库操作紧密结合，能够在数据变化的第一时间感知并更新缓存，保证缓存与数据库数据的高度一致性。对于以数据库为核心数据源的应用系统，这种方式不需要在应用程序代码中大量嵌入缓存更新逻辑，减少了应用程序的耦合度。
  3. 缺点：不同数据库的触发器语法和功能有所差异，实现的可移植性较差。而且，数据库触发器的维护和调试相对复杂，对数据库管理员的技术要求较高。如果触发器中的缓存更新逻辑出现问题，可能影响数据库的正常操作。
  4. 代码示例（以MySQL数据库和Python的Flask应用为例，假设使用Redis缓存）： 首先，在MySQL中创建触发器：
DELIMITER //
CREATE TRIGGER data_update_trigger
AFTER UPDATE ON your_table
FOR EACH ROW
BEGIN
    -- 这里可以调用外部脚本通知缓存更新，例如使用系统命令调用Python脚本
    SET @command = CONCAT('python /path/to/your/cache_update_script.py ', NEW.id);
    CALL sys_exec(@command);
END //
DELIMITER ;

然后，在Python脚本cache_update_script.py中编写缓存更新逻辑：

import redis
import sys

cache = redis.Redis(host='localhost', port=6379, db=0)
data_id = sys.argv[1]
cache.delete(f'data_{data_id}')

时间驱动与事件驱动的对比分析

一致性保证

  1. 时间驱动：时间驱动的缓存失效策略在一致性保证方面相对较弱。固定过期时间可能导致在过期时间内数据与数据源不一致，滑动过期时间虽然能根据访问情况调整过期时间，但仍然不能实时反映数据的变化。例如，在电商场景中，如果商品价格发生变化，使用固定过期时间的缓存可能在过期前一直返回旧的价格，直到过期后重新获取数据才更新。
  2. 事件驱动：事件驱动的策略在一致性方面表现更优。基于发布 - 订阅和数据库触发器的方式能够在数据发生变化的瞬间就触发缓存更新，确保缓存中的数据与数据源高度一致。如在金融交易系统中，当账户余额发生变化时，通过发布 - 订阅机制可以立即通知缓存更新余额数据，避免了因缓存数据不一致导致的交易风险。

性能影响

  1. 时间驱动：固定过期时间在性能方面相对稳定，因为过期时间是预先设定的，系统可以按照这个规律进行缓存更新和数据源访问。滑动过期时间对于热点数据能提高缓存命中率，减少数据源的负载，但对于非热点数据可能会造成缓存空间的浪费。总体来说，时间驱动策略在数据变化不频繁的场景下，对系统性能的影响较小。
  2. 事件驱动：基于发布 - 订阅的事件驱动策略通过异步处理缓存更新，在一定程度上减轻了系统的直接负载，但消息队列的性能可能成为瓶颈。如果消息队列处理速度慢，可能导致缓存更新延迟。基于数据库触发器的方式虽然能实时更新缓存，但数据库触发器的执行可能会增加数据库的负担，特别是在高并发的数据库操作场景下，可能影响数据库的性能。

实现复杂度

  1. 时间驱动：时间驱动的缓存失效策略实现相对简单。无论是固定过期时间还是滑动过期时间，在代码实现上主要涉及到设置和更新过期时间的操作。例如在使用Redis缓存时，通过setex和expire等简单命令就能实现相应功能，对开发人员的技术要求相对较低。
  2. 事件驱动：事件驱动的策略实现复杂度较高。基于发布 - 订阅需要搭建和管理消息队列，编写消息发布和订阅的代码逻辑，还要处理消息的可靠性、重复消费等问题。基于数据库触发器则需要熟悉数据库的触发器语法和外部程序调用机制，同时要考虑数据库与缓存更新逻辑之间的兼容性和稳定性。

适用场景

  1. 时间驱动：适用于数据变化频率较低且对一致性要求不是特别高的场景。例如，一些静态页面的缓存、网站的统计信息缓存等。在这些场景下，使用时间驱动策略可以在保证一定性能提升的同时，降低实现成本。
  2. 事件驱动：适用于数据变化频繁且对一致性要求极高的场景。如电商的订单状态跟踪、在线游戏的实时数据更新等。在这些场景中，确保缓存数据的实时一致性至关重要，事件驱动策略能够满足这种需求，尽管实现复杂度较高，但可以避免因数据不一致带来的业务问题。

混合使用策略

在实际的后端开发中，单一的缓存失效策略可能无法满足复杂的业务需求，因此常常会采用时间驱动和事件驱动相结合的混合策略。

场景举例

以一个电商平台为例，商品的基本信息（如名称、描述等）变化相对较少，可采用时间驱动的固定过期时间策略来缓存。例如设置过期时间为一天，这样既能保证缓存有一定的时效性，又不会过于频繁地从数据库获取数据。而对于商品的库存和价格信息，由于变化频繁且对业务影响重大，采用事件驱动的基于发布 - 订阅策略。当库存或价格发生变化时，通过消息队列及时通知缓存更新。

实现方式

在代码实现上，可以在时间驱动的基础上，增加事件驱动的部分。比如在Python的Flask应用中，对于商品基本信息的缓存使用固定过期时间：

import redis
from flask import Flask

app = Flask(__name__)
cache = redis.Redis(host='localhost', port=6379, db=0)

def get_product_info_from_source(product_id):
    # 模拟从数据源获取商品基本信息
    return f"Product {product_id} basic info"

@app.route('/product/<int:product_id>')
def get_product(product_id):
    product_info = cache.get(f'product_{product_id}_basic')
    if not product_info:
        product_info = get_product_info_from_source(product_id)
        cache.setex(f'product_{product_id}_basic', 86400, product_info)  # 过期时间一天
    return product_info.decode('utf-8')

对于库存和价格信息，通过消息队列接收更新事件并更新缓存：

import redis
from flask import Flask

app = Flask(__name__)
cache = redis.Redis(host='localhost', port=6379, db=0)
pubsub = cache.pubsub()

def update_product_stock_and_price(message):
    product_id = message['data']
    cache.delete(f'product_{product_id}_stock')
    cache.delete(f'product_{product_id}_price')

pubsub.subscribe({'product_update': update_product_stock_and_price})
thread = pubsub.run_in_thread(sleep_time=0.01)

优势

混合策略结合了时间驱动和事件驱动的优点，既在数据变化不频繁的部分利用时间驱动策略实现简单、性能稳定的缓存管理，又在对一致性要求高的关键数据上通过事件驱动策略保证数据的实时一致性。这种方式能够更好地适应复杂多变的业务场景，提高系统的整体性能和稳定性。

缓存失效策略的优化与考量

缓存预热

  1. 概念：缓存预热是指在系统启动或缓存清空后，提前将一些热点数据加载到缓存中，避免在用户请求时才从数据源获取数据，从而提高系统的初始响应速度。
  2. 实现方式：可以在应用程序启动时，通过批量查询数据源的方式，将热点数据预先存入缓存。例如，在电商平台启动时，将热门商品的信息、热门搜索关键词等数据加载到缓存中。代码示例（以Python和Redis为例）：
import redis

cache = redis.Redis(host='localhost', port=6379, db=0)

def preload_cache():
    hot_product_ids = [1, 2, 3]  # 假设这些是热门商品ID
    for product_id in hot_product_ids:
        product_info = get_product_info_from_source(product_id)
        cache.set(f'product_{product_id}', product_info)

def get_product_info_from_source(product_id):
    # 模拟从数据源获取商品信息
    return f"Product {product_id} info"

if __name__ == '__main__':
    preload_cache()

缓存穿透、雪崩和击穿的应对

  1. 缓存穿透：
    • 问题描述：缓存穿透是指查询一个不存在的数据，由于缓存中没有，每次都会查询数据源，导致大量请求直接打到数据源上，可能压垮数据源。例如，恶意用户不断请求不存在的商品ID。
    • 应对策略：可以采用布隆过滤器（Bloom Filter）。布隆过滤器可以在内存中以极小的空间和时间开销判断一个元素是否存在。当查询数据时，先通过布隆过滤器判断数据是否可能存在，如果不存在则直接返回，不再查询数据源。代码示例（以Python的pybloomfiltermmap库为例）：
from pybloomfiltermmap import BloomFilter

bloom = BloomFilter(capacity=1000000, error_rate=0.001)

# 假设将已存在的商品ID添加到布隆过滤器
product_ids = [1, 2, 3, 4, 5]
for product_id in product_ids:
    bloom.add(str(product_id))

def check_product_exists(product_id):
    if str(product_id) not in bloom:
        return False
    # 否则再查询缓存或数据源
    return True
  1. 缓存雪崩：
    • 问题描述：缓存雪崩是指大量缓存数据在同一时间过期，导致大量请求同时访问数据源，造成数据源压力过大甚至崩溃。通常发生在设置了相同过期时间的缓存数据量较大，且过期时间集中到期的情况。
    • 应对策略：一是分散过期时间，在设置固定过期时间时，给每个数据项的过期时间加上一个随机的时间偏移量，使得缓存过期时间分布更加均匀。二是使用二级缓存，当一级缓存过期时，先从二级缓存获取数据，减轻数据源压力。
  2. 缓存击穿：
    • 问题描述：缓存击穿是指一个热点数据在缓存过期的瞬间，大量请求同时访问该数据，导致这些请求都直接打到数据源上。例如，一个热门商品的缓存刚好过期，此时大量用户同时请求该商品信息。
    • 应对策略：可以使用互斥锁（Mutex）。在缓存过期时，只有一个请求能够获取到互斥锁，去查询数据源并更新缓存，其他请求等待。这样避免了大量请求同时查询数据源。代码示例（以Python和Redis的redis - py库实现简单互斥锁为例）：
import redis
import time

cache = redis.Redis(host='localhost', port=6379, db=0)

def get_hot_product(product_id):
    product_info = cache.get(f'product_{product_id}')
    if not product_info:
        lock_key = f'lock_product_{product_id}'
        if cache.set(lock_key, 'locked', nx=True, ex=10):  # 获取互斥锁，10秒过期
            try:
                product_info = get_product_info_from_source(product_id)
                cache.set(f'product_{product_id}', product_info)
            finally:
                cache.delete(lock_key)  # 释放互斥锁
        else:
            time.sleep(0.1)  # 等待锁释放
            return get_hot_product(product_id)
    return product_info.decode('utf-8')

def get_product_info_from_source(product_id):
    # 模拟从数据源获取商品信息
    return f"Product {product_id} info"

缓存容量管理

  1. 缓存淘汰策略：当缓存空间不足时，需要采用缓存淘汰策略来决定删除哪些数据。常见的策略有LRU（最近最少使用）、LFU（最不经常使用）、FIFO（先进先出）等。在Redis中，可以通过配置maxmemory - policy参数来选择不同的淘汰策略。例如，设置为volatile - lru表示在设置了过期时间的键中使用LRU策略淘汰数据，allkeys - lru表示对所有键都使用LRU策略。
  2. 动态调整缓存容量：根据系统的运行情况和数据访问模式，动态调整缓存的容量。可以通过监控缓存命中率、数据源负载等指标，当缓存命中率过低或数据源负载过高时，适当增加缓存容量；反之则减少缓存容量，以优化资源利用。例如，可以使用Prometheus和Grafana等工具来监控这些指标，并通过自动化脚本或配置管理工具来调整缓存的大小。

不同缓存技术对失效策略的支持

Redis

  1. 时间驱动支持：Redis对时间驱动的缓存失效策略支持良好。通过setex命令可以方便地设置键值对并指定过期时间，实现固定过期时间策略。对于滑动过期时间，可以通过expire命令在每次访问时更新过期时间。
  2. 事件驱动支持：Redis提供了发布 - 订阅功能，通过publish和subscribe命令可以实现基于发布 - 订阅的事件驱动缓存失效。开发人员可以利用这一功能，在数据变化时发布消息，订阅该消息的客户端可以及时更新缓存。

Memcached

  1. 时间驱动支持：Memcached同样支持设置过期时间，在添加或替换数据时可以指定过期时间，实现固定过期时间策略。但Memcached没有像Redis那样方便的滑动过期时间直接操作，需要在应用层通过每次访问时重新设置过期时间来模拟滑动过期时间。
  2. 事件驱动支持：Memcached本身不直接支持发布 - 订阅机制，因此在实现事件驱动的缓存失效策略时，需要借助外部消息队列（如RabbitMQ、Kafka等）来实现。

Ehcache

  1. 时间驱动支持：Ehcache对时间驱动的缓存失效策略支持丰富。可以设置元素的过期时间（timeToLiveSeconds）和空闲时间（timeToIdleSeconds），分别对应固定过期时间和类似滑动过期时间的功能（空闲时间内无访问则过期）。
  2. 事件驱动支持：Ehcache支持事件监听机制，可以注册监听器来监听缓存元素的创建、更新和删除等事件。通过这种方式，可以在数据变化时触发相应的缓存更新逻辑，实现事件驱动的缓存失效策略。

总结与展望

缓存失效策略在后端开发的缓存设计中起着关键作用。时间驱动和事件驱动的缓存失效策略各有优劣，在实际应用中需要根据业务场景的特点，如数据变化频率、一致性要求、性能需求等，合理选择或混合使用这两种策略。同时，要注意缓存预热、应对缓存穿透、雪崩和击穿等问题，以及做好缓存容量管理。随着技术的不断发展，缓存技术也在不断演进，未来可能会出现更高效、更智能的缓存失效策略和实现方式，以满足日益复杂的后端开发需求。开发人员需要持续关注技术动态，不断优化缓存设计，提升系统的性能和稳定性。