在某个查询场景的性能测试过程中，遇到了一个问题：测试过程中报错率逐渐攀升。进一步检查后发现，在查询业务所在应用的后台日志和平台应用的后台日志中，都出现了用户登录相关的报错信息。经过排查分析，发现了问题的根源，并做出了解决方案。

在测试过程中，发现报错率逐渐增加，并且在后台日志中出现以下错误信息：

查询业务应用后台日志：

2023-08-25 19:37:49.629 xxx-web [019c40515a0854f4,019c40515a0854f4] [http-nio-9900-exec-576] ERROR [BaseService.java:249] - 调用平台权限接口失败，基础资料调用平台权限数据查询接口失败！
com.ufgov.ma.exception.MaException: 基础资料调用平台权限数据查询接口失败！

被调用的平台应用后台日志：

用户未登录或会话过期！

进行了以下排查步骤来找到问题的根源：

1. 完成9750个用户登录，并登入Redis集群，使用命令keys userlogininfo:*查询。发现每个节点平均分配了3000多个用户的tokenid。
2. 在执行业务压测时，观察到Redis缓存中的tokenid逐渐减少。
3. 查看redis集群监控，内存达到上限。
4. 检查Redis配置的缓存淘汰机制，发现设置为volatile-lru，即在设置了过期时间的键空间中，优先移除最近未使用的key。

通过以上排查过程，初步得出以下结论和分析：

• 用户登录时生成的tokenid被写入Redis缓存。
• 在业务场景压测过程中，大量的业务要素写入Redis缓存，导致内存占用逐渐增加。
• 当Redis达到内存上限时，根据缓存淘汰机制的设定，会删除最近未使用的key。
• 这就导致了用户的tokenid被误删，从而引发了报错和用户登录失效的问题。

基于以上问题分析，提出了以下解决思路：

1. 将Redis配置的缓存淘汰机制设置为volatile-ttl，即在设置了过期时间的键空间中，具有更早过期时间的key优先移除。
2. 调整tokenid的过期时间较长，同时将业务要素的过期时间调短。
3. 进行再次压测，观察性能测试结果。

按照上述解决思路进行实施：

1. 将Redis配置的缓存淘汰机制设置为volatile-ttl。

2. 调整tokenid的过期时间为较长时间，例如86400秒（24小时），以确保用户登录信息在一定时间内不会被过期清理。

   #session的超时时间默认86400秒（登录超过1天必须重新登录）
   sessionTimeOut=86400
   #userLoginInfo的超时时间默认14400秒（没有操作超过4小时需要重新登录）
   userLoginInfoTimeOut=86400

3. 同时，调整业务要素的过期时间为较短时间，以避免大量业务要素占用过多的内存资源（已设置为默认）。

4. 再次进行性能测试，观察报错率和后台日志。

经过上述优化方案的实施，得到了以下结果和结论：

结果：

• 在再次执行压测后，我们观察到测试结果的报错率为0，并且应用后台日志中不再出现用户登录失效的报错信息，问题成功解决。

结论：

• 在高并发场景下，Redis的内存资源可能会因为大量业务要素的写入而达到上限。
• 使用缓存淘汰机制时，应根据业务需求调整设置，以确保重要数据的有效性和可用性。
• 调整tokenid的过期时间和业务要素的过期时间，可以有效减少缓存清理过程中用户登录信息被误删除的情况。

通过本次经验，我们了解到在进行性能测试或高并发压力测试时，需要充分考虑缓存管理的影响，并针对具体业务场景进行优化。同时，通过正确的排查和分析，结合合理的解决思路和方案，我们能够有效地解决问题并提升系统的稳定性和性能表现。