摘要：Redis，这个备受欢迎的内存数据库，对其查询引擎进行了重大升级，以支持日益增长的检索增强生成 (RAG) 应用需求，尤其是在向量数据库重要性日益凸显的背景下。

Boot+Cloud项目学习：

Redis，这个备受欢迎的内存数据库，对其查询引擎进行了重大升级，以支持日益增长的检索增强生成 (RAG) 应用需求，尤其是在向量数据库重要性日益凸显的背景下。

此次升级的核心在于引入了多线程查询执行，在保持低延迟（平均查询延迟低于 10 毫秒）的同时，显著提升了查询吞吐量。通过允许多个查询并发访问索引，Redis 实现了垂直扩展，有效提升了 Redis 操作和查询的吞吐量，尤其是在数据量达到数亿文档级别时，避免了复杂查询成为性能瓶颈。

传统的 Redis 单线程架构在处理长时间运行的查询，特别是使用倒排索引进行数据搜索时，容易造成拥塞，降低整体吞吐量。搜索操作本身并非 O(1) 复杂度，通常需要结合多个 O(log(n)) 复杂度的索引扫描来满足多个查询条件，其中 n 是索引映射的数据点数量。

Redis 的多线程架构有效解决了这一挑战。新的架构允许多个查询在独立的线程上并发执行，同时保持主线程对其他 Redis 操作的响应能力。

具体来说，查询执行分为三个步骤：

主线程准备查询上下文（规划），并将其放入共享队列。

多个工作线程从队列中取出任务，并并发执行查询管道。 这使得多个查询可以并行处理，大大提高了吞吐量。

查询完成后，结果返回给主线程。 主线程负责整合结果并返回给客户端。

这或许是一个对你有用的开源项目，mall项目是一套基于 SpringBoot3 + Vue 的电商系统（Github标星60K），后端支持多模块和 2024最新微服务架构 ，采用Docker和K8S部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能！

这种设计既提升了复杂查询（例如向量相似性搜索）的吞吐量，又保证了 Redis 核心操作的高性能。Redis 指出，高效扩展搜索需要结合水平扩展（分布式数据负载）和垂直扩展（多线程索引访问），以应对不断增长的数据量和查询需求。

为了验证新查询引擎的性能，Redis 进行了广泛的基准测试，并与三类向量数据库提供商进行了比较：

结果显示，Redis 在速度和可扩展性方面优于纯向量数据库，并在整体性能上显著超过了通用数据库和托管 Redis CSP。基准测试使用了多个数据集 (gist-960-euclidean, glove-100-angular, deep-image-96-angular, dbpedia-openai-1M-angular) 和行业标准工具 (例如 Qdrant 的 vector-db-benchmark)，涵盖了数据摄取（使用 HNSW 算法和 ANN 搜索）和 k-NN 搜索等工作负载，确保了测试的全面性和可靠性。

Redis 的此次升级正值向量数据库市场蓬勃发展之际。然而，市场上向量数据库选项日益饱和，正如 Reddit 首席工程师 Doug Turnbull 指出的，选择过多反而让用户无所适从。真正的挑战在于构建完整的检索解决方案，而不仅仅是获取向量。Vectera 的 Ofer Mendelevitch 和 RisingWave Labs 创始人吴英骏也表达了类似的观点，强调向量数据库只是 AI 应用技术栈的一部分，并且更倾向于在现有数据库上增强向量引擎。Redis 的做法与这一理念相符，通过增强现有基础设施为开发者提供更集成高效的解决方案。

新 Redis 查询引擎的查询吞吐量提升了 16 倍，尤其适用于对实时性要求很高的 RAG 应用，例如需要快速检索向量数据库的聊天机器人。Gmail 创始人 Paul Buchheit 提出的 “100 毫秒规则” 强调了用户体验的重要性。在 RAG 架构中，网络往返、LLM 处理、应用操作和向量数据库查询等多个环节会导致延迟，平均端到端响应时间远超 100 毫秒。Redis 的改进有助于开发者构建更接近 “100 毫秒规则” 的实时生成式 AI 应用，提供更流畅的用户体验。

英文原文地址： 。

整套 视频教程 的内容还是非常完善的，涵盖Spring Cloud核心组件、微服务项目实战、Kubernetes容器化部署等内容，你也可以点击链接 mall-swarm视频教程 了解更多内容。

来源：走进科技生活