一、存在问题

在StoryEcho这个文字冒险游戏系统中，用户可以创建多个角色存档，每个角色又可以开启多个不同周目的故事会话。每个故事会话都包含大量的状态数据：对话历史、角色属性、背包物品、任务进度、NPC关系、战斗状态等等。随着用户不断推进各个角色的剧情，这些数据会持续累积，导致每个会话的内存占用越来越大。同时，用户可能在不同角色和不同存档之间切换游玩，如果不对会话数量进行有效管理，所有历史会话都会一直驻留在内存中，服务器的内存很快就会耗尽。

二、面临的核心挑战

1.会话数量不可控

用户可以创建多个角色，每个角色又可以进行多周目游戏，每个周目都会产生独立的故事会话。如果用户长期使用这个系统，创建了十几个角色，每个角色又推进了多个存档，会话数量同样会累积到相当可观的规模。如果没有淘汰机制，这些历史会话会一直驻留在内存中，最终导致内存耗尽、服务响应变慢甚至崩溃。

2.会话的活跃度差异极大

用户可能同时推进多个故事线，在不同的角色和存档之间切换游玩。比如今天主要玩“迷雾森林”的A角色，明天切换到“赛博朋克”的B角色，上周玩过的C角色可能已经通关但会话还留在内存里。系统需要能够区分用户当前正在活跃游玩的会话、暂时搁置但后续还会继续的会话，以及已经彻底完成不再需要的会话，优先保留那些用户正在积极互动的会话。

3.会话之间存在依赖关系

一个角色会话可能被该角色的多个不同周目存档所引用。如果系统简单地按照会话大小或闲置时间来决定淘汰顺序，可能会淘汰掉一个被多个存档依赖的核心角色会话，导致用户切换到这些存档时都需要重新从数据库加载，严重影响游戏体验。系统必须识别这种依赖关系，让被广泛依赖的关键会话获得更高的保留优先级。

4.传统淘汰算法的不适用性

标准的LRU只考虑最近使用时间，无法区分用户是暂时离开还是彻底放弃；LFU只考虑访问频率，会导致用户过去玩得最多的角色永远不被淘汰，而新创建的角色却容易被挤出；FIFO过于简单，完全忽略了会话的价值差异和依赖关系。这些传统算法都无法很好地适应单用户多存档这种“冷热数据交替、存在依赖链”的复杂场景。

三、设计目标

基于以上挑战，这个缓存淘汰机制需要实现几个核心目标：能够根据会话所属话题的用户活跃度来调整优先级，让热门玩家的会话获得保护；能够识别会话之间的依赖关系，避免淘汰被广泛依赖的关键数据；能够综合考虑时间、频率、依赖、话题等多维度因素，做出更智能的淘汰决策；同时还要支持TTL过期清理和手动淘汰，提供灵活的缓存管理能力。

四、解决方案的引入

正是在这样的背景下，我们设计了话题感知缓存淘汰机制。它不再使用单一的淘汰维度，而是构建了一个综合评分模型，将话题活跃度、依赖重要性、访问频率三者结合，并辅以时效奖励，使得淘汰决策更加合理和智能。这个机制确保了系统在高并发场景下依然能够稳定运行，热点会话得到保护，僵尸会话被及时清理，关键依赖数据不被误删。

4.1话题活跃度TP

指的是根据缓存条目所属话题的访问频率来评估其价值。如果一个话题下的条目被频繁访问，该话题的活跃度分数就会上升，从而使其下的所有条目获得更高的保留优先级。具体来说，每个话题都有一个活跃度分数，初始值为0.5。每次访问该话题下的缓存条目时，分数会按照公式：

新分数=旧分数×0.95+1

进行更新，然后归一化到0到1之间。如果某个话题长时间没有被访问，它的分数会自然衰减。系统使用这种带衰减的指数移动平均来更新话题活跃度，确保了热门内容能够被保留，而冷门内容则逐渐被淘汰。

4.2依赖重要性TSI

依赖重要性TSI指的是一个缓存条目被其他条目所依赖的程度。系统维护了一个依赖图，当条目A依赖于条目B时，条目B就被标记为被依赖。一个条目被越多其他条目依赖，其TSI分数就越高，因为淘汰它可能会导致多个依赖它的条目失效。比如多个活跃的故事会话可能依赖同一个角色会话，那么该角色会话就不应该被轻易淘汰。TSI的具体计算公式是：

min(1.0, 被依赖数量 ÷ 10) + 0.1

这个基础分0.1确保即使没有被依赖的条目也有一个保底分数，而每多一个依赖者，分数就会相应增加，直到最多1.0封顶。

4.3访问频率衰减

访问频率衰减则是根据条目的空闲时间来计算其时效价值。条目每空闲一小时，其分数就会按照反比例函数衰减，同时新创建的条目会获得一个时效性奖励分数，让它们在初期有一定的保护期。这确保了长期未被使用的条目会被逐步降权，而新鲜的数据则有一定的生存空间。

4.4最终公式

最终的淘汰决策通过综合评分公式 ：

TP × (TSI + α) × 频率分数 + 时效奖励`

来统一计算，其中α是一个基础偏移常数。系统会定期扫描所有缓存条目，计算每个条目的综合评分，然后淘汰评分最低的条目，直到缓存大小恢复到限制范围内。此外，系统还支持基于TTL的过期淘汰和手动淘汰，形成了一个完整的缓存生命周期管理机制。这种多维度的评分策略相比传统的LRU或LFU算法更加智能，能够适应复杂的话题和依赖关系场景。

五、代码实现

5.1数据结构设计

`CacheEntry`数据类封装了每个缓存条目的完整元信息，包括值、所属话题、依赖列表、创建时间、最后访问时间和访问次数。通过`age_seconds`和`idle_seconds`属性可以实时计算条目的存活时长和空闲时长。缓存主体使用字典存储所有条目，同时维护三个辅助结构：`_topic_popularity`字典追踪每个话题的整体活跃度分数，`_dependency_graph`记录依赖关系图（key被哪些其他key依赖），`_reverse_deps`记录反向依赖（key依赖哪些其他key）。这种双向依赖图设计使得当某个条目被淘汰时，可以正确清理所有相关的依赖引用。

@dataclass
class CacheEntry:
    """缓存条目"""
    key: str
    value: Any
    topic: Optional[str] = None
    dependencies: List[str] = field(default_factory=list)
    created_at: float = field(default_factory=time.time)
    last_accessed: float = field(default_factory=time.time)
    access_count: int = 0
    
    @property
    def age_seconds(self) -> float:
        return time.time() - self.created_at
    
    @property
    def idle_seconds(self) -> float:
        return time.time() - self.last_accessed

5.2淘汰策略的核心算法

体现在`_compute_score`方法中。综合评分由三个维度构成：TP（话题活跃度）反映该条目所属话题的整体热度，TSI（依赖重要性）衡量有多少其他条目依赖当前条目，访问频率衰减则根据空闲时间计算衰减曲线。公式为 `score = TP × TSI × 频率衰减 + 年龄奖励`。年龄奖励是新条目保护机制，在24小时内给予额外分数。这种设计确保了高频话题的核心依赖条目难以被淘汰，而孤立且长期未访问的条目会优先被清理。

def _compute_score(self, key: str, entry: CacheEntry) -> float:
        """
        计算条目价值评分
        综合评分 = TP × (TSI + α) × 访问频率衰减
        """
        # TP: 话题活跃度 (0 ~ 1)
        tp_score = self._topic_popularity.get(entry.topic or "", 0.5)
        
        # TSI: 依赖重要性 - 被多少个其他条目依赖
        depends_on_me = len(self._dependency_graph.get(key, set()))
        tsi_score = min(1.0, depends_on_me / 10.0) + 0.1  # 基础分0.1
        
        # 访问频率衰减 (越久未访问，分数越低)
        idle_hours = entry.idle_seconds / 3600
        freq_score = 1.0 / (1.0 + idle_hours)  # 1小时后0.5，2小时后0.33
        
        # 时间衰减：新条目有奖励
        age_hours = entry.age_seconds / 3600
        age_bonus = 0.1 * (1.0 - min(1.0, age_hours / 24))  # 24小时内逐渐衰减
        
        score = tp_score * (tsi_score) * freq_score + age_bonus
        
        return max(0.01, score)

5.3生命周期管理

通过定期清理和条件淘汰相结合。初始化时会启动一个后台定时器，每隔`cleanup_interval`秒执行`_periodic_cleanup`方法，批量删除超过TTL的过期条目。

def _periodic_cleanup(self):
        """定期清理过期条目"""
        if not self._running:
            return
        
        # 清理过期的
        expired = [
            key for key, entry in self._cache.items()
            if time.time() - entry.created_at > self.ttl_seconds
        ]
        for key in expired:
            self._evict(key, reason="ttl")
            self._stats["ttl_evictions"] += 1
        
        # 如果仍然超过大小限制，淘汰低价值
        while len(self._cache) > self.max_size:
            self._evict_least_valuable()
        
        # 重新启动定时器
        if self._running:
            self._cleanup_timer = threading.Timer(self.cleanup_interval, self._periodic_cleanup)
            self._cleanup_timer.daemon = True
            self._cleanup_timer.start()

在`put`操作时，如果缓存已满，会循环调用`_evict_least_valuable`逐出评分最低的条目直到有空间。每次`get`操作会更新访问时间和访问计数，并触发话题活跃度的衰减更新——每次访问会使话题分数按`topic_decay_factor`衰减后再加1，实现了热度随时间自然冷却的效果。

5.4依赖关系维护

当存入带依赖列表的条目时，系统会建立双向索引：被依赖的条目记录哪些key正在依赖它，当前条目记录它依赖哪些key。这样在淘汰某条目时，可以同时清理依赖图中指向它的所有引用，避免悬挂引用。淘汰回调机制允许外部注册监听器，在条目被淘汰时执行自定义逻辑，比如记录日志或触发资源回收。

六、总结

该话题感知缓存淘汰机制通过综合评分模型（话题活跃度TP、依赖重要性TSI、访问频率衰减）解决了StoryEcho游戏系统中多会话管理的内存压力问题。代码实现了双向依赖图维护、定期TTL清理和淘汰回调机制，相比传统LRU/LFU能更好地区分热点会话与僵尸会话，并保护被多存档依赖的核心数据。主要不足在于评分公式中的固定参数（如除数10、年龄奖励系数0.1）需要针对实际场景调优。