Xamarin.Forms单点登录异常态残留及性能问题解决方案咨询

你最初的数据库存登录记录、登出删记录的方案，核心缺陷是无法覆盖异常离线场景，而客户端定时打库更新时间戳的方案确实会产生大量无意义请求，完全可以通过架构优化规避性能问题，以下是生产环境验证过的成熟实现逻辑：

• 会话存储层替换为Redis这类高性能内存KV，替代主业务库存放活跃登录态
  用户登录成功后，在Redis中写入用户唯一ID -> 当前有效会话Token/设备标识的键值对，初始给这个Key设置150秒（2分30秒）的自动过期时间。所有业务接口的鉴权逻辑本来就需要校验请求Token的合法性，只要校验通过，服务端直接在鉴权环节顺带给这个Key续期回150秒，完全不需要客户端单独发送心跳请求。
  当用户出现设备意外关机、应用被强制终止、断网等异常离线场景时，不会再有业务请求触发续期，Key到过期时间会被Redis自动删除，不会残留无效登录记录锁死账号。用户主动登出时，直接删除Redis中对应用户ID的键值对即可，和你最初的流程逻辑一致。
• 新登录请求的校验逻辑
  用户发起新登录请求时，先查Redis中是否存在该用户ID对应的有效会话Key：
  • 如果不存在，直接判定当前无有效登录，允许登录并写入新的会话映射
  • 如果存在，直接覆盖旧的会话Token映射，旧设备后续发起请求时，会因为携带的Token和Redis中存储的当前有效Token不匹配，被拦截并返回「账号已在其他设备登录」的提示，天然保证同一时间仅一个设备持有有效登录态
• 极端场景兜底
  如果担心Redis宕机丢失会话数据，可以在每次生成新会话时，异步将当前会话Token写入用户表的对应字段做持久化备份，Redis重启时优先加载最近7天的备份会话数据即可。异步写库不需要同步等待返回，对接口性能几乎无影响。

注意：不要把活跃会话的读写放在主业务库上，Redis单实例可以轻松支撑10万/秒以上的简单读写请求，鉴权顺带续期的逻辑不会产生任何额外的接口请求，完全不会出现拖慢整体应用性能的问题。如果业务对后台挂起的容忍度更高，可以适当调大Redis Key的过期时间到5-10分钟，进一步降低续期的写操作频率。

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