Lichess评分过滤器行为优化分析

背景介绍

Lichess作为一款开源的在线国际象棋平台，其匹配系统设计直接影响用户体验。近期有用户反馈了一个关于评分过滤器行为的问题，值得深入探讨其技术实现和优化方案。

问题描述

在Lichess平台中，当用户创建游戏时设置评分范围过滤器（如±500分），系统会基于用户创建游戏时的初始评分来寻找对手。然而，当用户连续进行多局游戏后，即使用户的实时评分已经发生变化，"新对手"功能仍然基于初始评分范围进行匹配，而不是根据当前最新评分。

举例说明：

1. 用户A初始评分为1500，设置评分范围±500
2. 系统会匹配1000-2000分的对手
3. 用户A连续获胜，评分升至1600
4. 点击"新对手"后，系统仍按1500±500的范围匹配（1000-2000）
5. 而用户期望的是按1600±500（1100-2100）匹配

技术分析

从技术实现角度看，这个问题涉及以下几个关键点：

1. 会话状态管理：游戏创建时的评分范围是否被持久化在会话中
2. 实时评分获取：系统是否在每次匹配时获取用户最新评分
3. 匹配算法逻辑：匹配服务是使用缓存数据还是实时查询

当前实现可能是将会话创建时的评分范围固定存储，而没有在每次匹配时重新计算。这种设计虽然减少了数据库查询压力，但牺牲了匹配的实时性。

优化方案

针对这个问题，可以考虑以下几种优化方案：

1. 动态评分范围计算：

   • 每次点击"新对手"时，实时查询用户当前评分
   • 基于最新评分重新计算匹配范围
   • 优点：完全符合用户预期
   • 缺点：增加数据库查询压力

2. 客户端缓存更新：

   • 在游戏结束时，客户端接收评分变更通知
   • 自动更新本地存储的评分基准
   • 下次匹配时使用更新后的基准
   • 优点：减少服务端压力
   • 缺点：实现复杂度较高

3. 混合模式：

   • 服务端缓存用户评分，设置短期有效期
   • 在有效期内使用缓存，过期后重新查询
   • 平衡性能与实时性的折中方案

实现建议

从用户体验和系统稳定性综合考虑，推荐采用第一种方案（动态评分范围计算），具体实现可考虑：

1. 在匹配服务中添加实时评分查询
2. 对高频用户实施限流措施
3. 使用Redis等缓存层减轻数据库压力
4. 添加监控指标，观察系统负载变化

用户体验影响

这一优化将显著改善以下场景的用户体验：

1. 连胜/连败玩家：评分快速变化的玩家能保持合理的对手匹配
2. 特定目标训练：想专门与高分对手练习的玩家无需频繁重建游戏
3. 评级保护：避免因评分变化而意外匹配到过高或过低水平的对手

总结

Lichess作为开源国际象棋平台，其匹配系统的精确性和实时性对用户体验至关重要。优化评分过滤器的动态行为，使其基于用户当前评分而非初始评分进行匹配，将提升平台的竞技公平性和用户满意度。这一改进虽然会增加少量系统开销，但带来的用户体验提升是值得的。