Laravel项目并发请求场景下RediSearch吞吐量过低如何优化

根因说明 #

你遇到的吞吐量倒挂问题核心原因是：单实例Redis的命令执行逻辑默认依赖单核心算力，而你用到的FT.AGGREGATE带多步APPLY计算、地理过滤、聚合求和，属于CPU密集型操作，单请求占用CPU时间长，并发请求会在Redis命令队列排队，导致吞吐量上不去。PostgreSQL本身是多进程多线程架构，能同时调度多个核心处理并行查询，所以高并发下表现更好。

具体优化措施 #

1. Redis架构层优化 #

• 搭建分片集群：将120亿条数据按地理范围或哈希规则拆分到多个Redis实例，每个实例负责部分数据的查询，请求侧先并行查询所有分片再聚合结果，充分利用多核心算力打散单实例压力。
• 开启RediSearch多线程配置：RediSearch 2.0及以上版本支持查询多线程并行，将SEARCH_MAX_THREADS参数调整为服务器物理核心数的70%~80%，留足余量避免CPU占满，可直接降低单查询的执行耗时。

2. 查询逻辑优化 #

• 预计算冗余字段：将查询中需要实时计算的a1、a1b字段在写入Redis时直接计算好存储，查询时直接调用预存值做聚合，可降低50%以上的实时计算开销。
• 裁剪冗余步骤：当前查询中APPLY 1 as test再按@test分组的逻辑完全冗余，可以直接删除该步骤改为全局聚合，减少分组开销。
• 索引优化：为location字段单独建立地理空间专属索引，避免联合索引的过滤损耗，减少需要后续计算的数据集大小。

3. 客户端侧优化 #

• 替换Redis客户端：将Laravel默认的predis客户端更换为phpredis C扩展，连接和命令传输开销可降低30%以上。
• 配置长连接池：开启Laravel Redis长连接池，大小设置为并发量的1.2倍，避免每次请求新建TCP连接的开销。
• 批量请求合并：业务允许的前提下，将同类型的多个查询用pipeline批量发送给Redis，减少网络往返次数。

4. 服务器配置优化 #

• CPU绑定：将Redis进程绑定到专用的CPU核心，避免和NGINX、PHP-FPM进程抢占资源，减少上下文切换开销。
• 关闭持久化：当前场景下Redis属于缓存层，数据可从PostgreSQL同步，直接关闭RDB、AOF持久化，避免磁盘IO和fork进程带来的CPU损耗。

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