目前,当用户更改头像时,我正在执行以下操作来存储和使头像无效:
头像按用户 ID 存储,自动拆分为每个 1000 个文件夹(为了帮助文件系统并避免每个目录中有数百万个文件)
我用于检索用户头像的函数采用他们的用户 ID/性别/版本号 - 如果版本号大于 0,则将参数
?ver=$ver
附加到 URL,以便其他用户重新下载任何缓存的头像。如果版本号为 0,则 url 根据他们的“性别”返回默认头像
性别和头像版本存储在我的用户数据表中,每次用户更改他/她的头像时版本都会增加。
这工作得很好,并且最大限度地减少了数据库查找,因为在任何给定的点上,我已经拥有了根据用户 ID/性别/版本生成相关和当前头像所需的用户数据。无需再次查询或执行任何联接即可获取用户当前的头像。
但是,现在我添加了一个活动提要,我遇到了问题。
鉴于活动提要的性质,我们通常将故事数据存储为 JSON(使用 Redis 扇出并使用 MySQL 作为持久层等......等等......)
在任何给定的活动中,我们一直在存储用户的用户 ID、性别、版本号,以避免在检索信息时必须执行 JOIN。当然,这意味着如果用户头像被更改,那么任何旧活动都可能显示旧头像。
我正在寻找一种解决此问题的方法,该方法理想情况下不涉及在查询我们的活动提要时添加 JOIN。
到目前为止,我能想出的唯一解决方案是在查询活动提要时根据 time() 附加一个参数,以确保下载任何新的头像。但这当然意味着对于提要,用户浏览器中不会缓存任何头像。
另一种选择是对提要进行排队更新,并使用新的头像版本检查并修改每个相关的提要,但这似乎很荒谬。
我唯一的另一个想法是在登录时获取所有朋友的头像版本号,并在会话期间将它们存储在一个大数组中,然后简单地将它们附加到各种头像 URL 中。意味着有一个查找而不是多个查找。但是当然....这不涉及您不是朋友/关注的用户对活动的评论。但是话又说回来,最新的头像对你不关注的人真的很重要吗?也许不是。
对我来说,每个解决方案似乎都有其不足之处。
我还有其他选择吗?我是否应该回到关于头像 url 存储的绘图板(尽管我真的看不到另一种历史存储这些 URL 并让它们在提要中自动更新的方式)。
任何帮助将不胜感激