项目实战 （10）---后台搜索Cache优化

目录背景技术实现策略视频预处理阶段的cache技术视频搜索阶段的cache技术技术实现预处理阶段cache策略实现逻辑代码运行结果问题及注意点搜索阶段cache策略实现系统配置层面逻辑低版本GPUCPU本项目的配置高版本描述go ahead 策略cache 加载策略本项目配置应用层搜索参数的配置配置项本项目的实际配置背景但目前为止，视频搜索系统已经可以正常使用和运转。并且他是基于多策略搜索算法的，能够在很大程度上保证搜索的时效性和稳定性。但作为商用视频搜索系统，还差点东西，Cache最为优化的一个重中之重，其作用不言而喻。在大型垂直系搜索系统中，cache起着举足轻重的作用。原因很简单，因为搜索的视频或者视频描述，在很大程度上具备一定的重复性。利用已知的分析结果，如果在新来的search尽可能的让推送可以复用，但是又要考虑系统本身的存储负荷。在系统存储资源有限的情况下，不可能无止境的store cache。需要一个平衡点，既涉及到cache提高效率，又不能在某些环境下急剧增大系统存储负荷。但不得不承认，如果能善用缓存，将大大提高整个视频搜索系统的搜索效率。今天聚焦在后台搜索cache的优化上，并一步一步优化落地。技术实现策略实际上，cache 分为两个层面。一个层面是视频预处理阶段的缓存处理。另一个就是搜索阶段的cache 处理。视频预处理阶段的cache技术要设计一个cache 比较容易，数组，或是 map 都能实现其核心。但是有许多细节要考虑。首先需要考虑的是如何在cache的有效性与存储空间上折中。最简单易行的方式可能就是带有 timeout 的map或者数组方式。当timeout 到了，直接释放对应视频的存储空间。如果timeout没有到，作为 cache使用。这个方向应该是没问题，但如果你完全自己实现这个过程，你会发现有许多坑，一个是各种场景下的正确性，另一个就是效率。我们采用 redis 并结合 键空间通知来实现这一过程。另一个最主要的问题就是如何保证当视频正在分析时，此时发现cache timeout 时间到了，想要删除，如何确保删除前，正在进行 search 分析的 video 作为一个事务已经分析完成后，再删除。也就是删除与分析逻辑的同步问题。视频搜索阶段的cache技术搜索阶段的cache技术，其实本质上vector db 外围来做已经不太合适，原因细想下，也比较简单，在视频搜索中，搜索的内容是以 向量化 内容为主，说直白点就是高维数组。这种高维数组的cache实际上如果要一一匹配是比较困难的，且存在场景不同，可能需要匹配的侧重点不一样的情况。从实现层面来说，一般 vector db 都考虑了这点，都会有自己的cache，或者落盘策略。所以我们更需要关注的是各种 vector db 的设置参数是否合理，query 的参数是否合理，以满足搜索阶段的cache。技术实现预处理阶段cache策略实现逻辑前面说了，采用redis来实现。落地就是直接将 video 上传后，path 放在 redis set中。并设置过期时间，当过期时间到了，自动删除对应的video 文件。当新的search 达到后，看下是否存在cache，如果能命中，则直接返回 video cache 预处理返回结果。如果你不理解整体的实现步骤，你需要看下本专栏前面的系列文章。代码redis_client = redis.Redis(host='localhost', port=6379, db=0) EXPIRED_TIME = 10 # 设置过期时间为 10 秒 def add_video_to_cache(video_path, expire_seconds=EXPIRED_TIME): #video_id = str(uuid.uuid4()) redis_client.set(video_path, video_path, ex=expire_seconds) # 直接使用video_id作为键，并设置过期时间 def handle_expired_video_key(message): video_id = message['data'].decode() # 使用__作为分隔符分割字符串 video_parts = video_id.split('__') video_path = video_parts[1] print("Expired video: ", video_pa