多微服务共享缓存的最佳实现方案咨询——以客户与购物车服务场景为例

嘿，这个场景在微服务架构里真的太常见了——多个服务共享缓存，读写交叉很容易踩数据不一致的坑。我来分享一些实战里跑通的最佳实践，还有针对你说的客户服务/购物车服务场景的具体处理方式：

• 明确缓存的唯一归属者：哪怕多个服务都要读缓存，也必须指定一个服务作为缓存的「唯一写入/维护者」。就像你这里的客户服务，它负责客户数据的全生命周期更新，那它就该全权维护客户相关的缓存，其他服务（比如购物车）只做读取操作，绝对不能直接修改缓存。这能从根源上避免多服务写入导致的数据冲突。
• 选择适合的写策略：
  • 「写穿（Write-Through）」：更新数据库的同时同步更新缓存，确保缓存和数据库数据强一致，非常适合你这种对数据准确性要求高的场景（购物车需要准确的客户信息）。
  • 「写回（Write-Back）」：先更新缓存，再异步同步到数据库，性能更好但有数据丢失风险，不太适合你的客户数据场景。
• 主动失效+TTL双保险：
  • 给缓存设置合理的TTL（比如30分钟到几小时，根据数据更新频率调整），就算偶尔出现数据不一致，TTL到期后也能自动拉取最新数据恢复。
  • 核心是主动失效：客户服务每次更新客户数据后，立刻删除对应的缓存键（或者直接更新缓存值，更推荐删除，避免更新时的并发冲突）。比如用户修改了收货地址，客户服务马上删掉customer:{userId}这个缓存键，购物车服务下次读取时就会自动从数据库拉最新数据再回写缓存。
• 统一缓存键命名规则：比如约定用customer:{userId}、cart:{userId}这种格式，避免不同服务用不同键名导致的缓存混乱，也方便后期排查问题。
• 兜底处理缓存击穿/雪崩：如果购物车服务是高并发场景，当缓存miss时，要加分布式锁（比如Redis的SETNX），防止同一用户ID的大量请求同时打向数据库；对于热点客户数据，可以设置永不过期，配合主动失效来保证数据新鲜度。

1. 客户服务的缓存维护逻辑 #

当客户服务执行创建/更新/删除客户数据操作时，遵循「先更数据库，再处理缓存」的流程：

def update_customer(user_id, new_customer_data):
    # 第一步：先更新数据库，确保数据持久化
    db.session.query(Customer).filter(Customer.id == user_id).update(new_customer_data)
    db.session.commit()
    
    # 第二步：主动失效对应的缓存键（推荐删除而非更新，避免并发更新冲突）
    redis_client.delete(f"customer:{user_id}")
    
    # 如果是创建新客户，写完数据库后直接写入缓存，避免第一次读缓存miss
def create_customer(new_customer_data):
    customer = Customer(**new_customer_data)
    db.session.add(customer)
    db.session.commit()
    redis_client.setex(f"customer:{customer.id}", 3600, json.dumps(customer.to_dict()))

2. 购物车服务的缓存读取逻辑 #

购物车服务需要客户信息时，遵循「先读缓存，miss则读库回写缓存」的流程，高并发场景下记得加分布式锁：

def build_cart_with_customer_info(user_id):
    cache_key = f"customer:{user_id}"
    customer_data = redis_client.get(cache_key)
    
    if not customer_data:
        # 缓存miss，加分布式锁防止同一用户的请求同时打数据库
        lock_key = f"lock:customer:{user_id}"
        with redis_client.lock(lock_key, timeout=10):
            # 加锁后再读一次缓存，防止其他请求已经写入
            customer_data = redis_client.get(cache_key)
            if not customer_data:
                # 从数据库读取最新数据
                customer = db.session.query(Customer).filter(Customer.id == user_id).first()
                if not customer:
                    raise ValueError(f"Customer {user_id} not found")
                customer_data = json.dumps(customer.to_dict())
                # 写入缓存并设置TTL
                redis_client.setex(cache_key, 3600, customer_data)
    
    # 构建包含客户信息的购物车对象
    cart_data = get_cart_by_user_id(user_id)
    cart_data["customer_info"] = json.loads(customer_data)
    return cart_data

3. 异常与一致性兜底 #

• 如果客户服务更新数据库后，删除缓存失败（比如Redis临时宕机），可以引入补偿机制：比如把缓存失效消息发到消息队列（如Kafka），专门的缓存补偿消费者去重试失效操作；或者定期跑对账任务，对比数据库和缓存的数据，同步不一致的内容。
• 极端情况下，如果购物车服务读到了过期的缓存数据，由于我们设置了TTL，最多等待TTL到期就会自动刷新，不会出现长期不一致的问题。

内容的提问来源于stack exchange，提问作者satishdikku