迁移至Amazon Keyspaces后高读量触发PerConnectionRequestRateExceeded错误排查

核心问题在于IN子句被Amazon Keyspaces拆分为大量单请求，加上连接池配置未匹配Keyspaces特性，导致单连接请求速率超限。以下是具体优化点和排查方向：

一、查询语句优化 #

1. 替换大IN子句为并行单查询/小批量查询
   Keyspaces对IN子句的拆分是同步串行执行，每个IN元素对应一次请求且共享同一连接带宽。建议将含100个元素的IN查询拆分为多个小批量请求，或直接用客户端异步并行发起单条件查询（比如Java的CompletableFuture），分散请求到不同连接，避免单连接瞬间被打满。

2. 适配查询模式调整数据模型
   针对现有两种分区方式优化：

   • 若使用transactions_by_customer_id（按customerID分区）：新增聚合表customer_transactions_by_type，预先按customer_id + type聚合存储数据，查询时直接批量获取对应分组，彻底规避IN子句。
   • 若使用transactions_by_customer_id_and_type（按customerID+type分区）：由于IN type是跨分区查询，直接在客户端并行发起每个type对应的单分区查询，替代IN子句，利用多连接分散压力。

二、连接池与Cassandra驱动配置优化 #

1. 限制单连接并发请求数
   Keyspaces单连接的请求处理速率存在限制，当前大量请求可能集中在少数连接上触发超限。调整驱动参数advanced.connection.max-requests-per-connection，控制单连接的并发请求数，强制请求分散到更多连接。

2. 优化负载均衡与排队策略

   • 切换驱动负载均衡策略为TokenAwarePolicy + RoundRobinPolicy，确保请求均匀分发到Keyspaces的所有节点，避免部分节点的连接过载。
   • 配置advanced.connection.pool.queue.size调整请求排队长度，或启用SpeculativeExecutionPolicy，当单连接请求超时后自动切换到其他连接重试，减少请求堆积。

3. 调整连接池大小至最优值
   并非连接数越多越好，过多连接会增加Keyspaces端的管理开销。测试2000-3000连接数的场景，对比请求速率与错误率，找到能支撑30万次/秒CQL请求的最优连接数。

三、监控与排查方向 #

1. 跟踪单连接请求分布
   通过CloudWatch的RequestRate指标（按连接维度拆分），查看是否存在部分连接请求速率远超其他连接的负载不均衡情况；同时监控PendingRequests指标，确认是否有请求在连接池排队。

2. 检查连接复用与回收情况
   在客户端应用添加日志，记录每个连接的请求数、响应时间，排查是否存在连接被长期占用、闲置连接未正确回收的问题。

3. 验证Keyspaces服务配额
   通过CloudWatch的ThrottledRequests指标查看是否有请求被限流，若存在则提交服务配额提升申请，确保Keyspaces能支撑30万次/秒的CQL请求量级。

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