排行榜思维导图

这是一篇关于排行榜的思维导图，介绍了数据获取、数据存储、奖励发放三个板块，希望梳理的内容对你有所帮助！

排行榜

• 数据获取
  • 启服加载数据
    • 排行榜数据
      • 通过kbe的redis接口分排行榜id和间距, 分批获取排行信息
    • 玩家数据
      • 通过http请求, 从serverless批量获取玩家的昵称头像等信息, 每次一个sql语句查询最多50个玩家的信息, 返回json值通过http传输
  • 玩家获取整体排行榜信息
    • 在启服加载完排行榜和玩家数据后, 将整体数据进行打包, 并每隔5分钟, 重新拉取排行数据进行打包, 玩家获取排行信息都是从打好包的数据中获取
  • 玩家获取自己的排行信息
    • 获取排行信息的同时, 将玩家的排行保存到内存中
• 数据存储
  • 向redis上报玩家分数
    • 通过kbe与redis的连接进行数据的更新替换
    • 将玩家的分数, 时间, 等级等排序要素进行拼接
    • 利用redis的zset实现玩家分数的自动排序
• 奖励发放
  • 将排行信息保存到内存中
  • 玩家重登时判断是否需要发放奖励
  • 保存发放奖励状态
  • 优点: 1.分散到各个玩家实体, 不再集中压力到排行榜实例 2. 减少定时器的消耗 缺点: 1. 排行数据需要保存一段时间, 且需要启服加载排行数据 2. 如果玩家长时间不登录, 等排行数据清除则不会发放奖励 3. 玩家发放奖励记录不集中, 如果玩家出现问题, 不方便定位邮件日志
• rank实例通过定时器分帧发送邮件
  • 优点: 1. 集中分段处理, 日志和奖励比较方便查看 2.排行数据不需要保存, 定时器触发完就可以清除数据 缺点: 1. 分帧处理的峰值不好把控, 为保压力不会太大, 每次奖励需要拆分的比较小 2. 定时器的清除 3. 需要记录发送邮件的进度并将进度存库, 避免发送奖励期间服务器关闭, 启服时需要加载邮件发送进度(防错处理, 略显赘余,但必须要有)