weixin_39610468
weixin_39610468
2020-12-09 04:04

前端唯一标识那些事儿

在做聊天模块的时候,最初的消息唯一标识是msgId,在业务量小的情况下是可以满足需求的,毫秒级的唯一冲突是很难出现的。但是当用户量上升之后,时间戳的这种方案显然不行。因此需要引入一种新的前端生成唯一标识的方案。

除了时间戳之外,我在公司的其他前端项目中,发现一些其他的前端唯一性标识实现,因此在这里做一个记录。

  • 时间戳 唯一性差(目前应用于聊天消息唯一标识)
  • random string 唯一性较强(目前应用于OSS存储文件唯一识别名)
  • uuid 唯一性极强(待引入的唯一性更强的方案)
    • RFC4122是什么
    • node-uuid
      • node-uuid是什么
      • uuid的v1,v3,v4,v5分别是什么意思?
      • 已有项目uuid应用分析
      • node-uuid项目实践
  • 总结与思考

该提问来源于开源项目:FrankKai/FrankKai.github.io

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

3条回答

  • weixin_39610468 weixin_39610468 4月前

    时间戳

    应用于聊天模块的msgId,就是采用了时间戳的形式。

    js
    this.message.msgId = `${+new Date()}`; // "1568689340401"
    

    虽然说唯一性较差,但是截至目前还没有出现因为唯一性差导致重大问题。

    点赞 评论 复制链接分享
  • weixin_39610468 weixin_39610468 4月前

    random string

    js
    function randomString(length) {
      const chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_=-';
      let result = '';
      for (let i = length; i > 0; --i) {
        result += chars[Math.floor(Math.random() * chars.length)];
      }
      return result;
    }
    

    假如length输入的是64,那么这个随机数算法会在0~9,a~z,A~Z,-=_中生成一个64的64次方的分之一的随机字符串,64的64次方式3.940200619639448e+115,亿级也就1.0e+10,这个数字已经庞大到令人发指,唯一性其实已经很强了。

    唯一性会随着length长度的下降而下降,在文件名过长的情况下调整文件名长度时需要特别注意。

    点赞 评论 复制链接分享
  • weixin_39610468 weixin_39610468 4月前

    总结与思考

    • 时间戳唯一性虽然差但是可能刚好满足特定的业务场景,不见得是差的技术方案
    • 自定义的random string唯一识别实现,其实也能满足唯一性的要求
    • uuid有多个版本,包括时间戳(v1),随机数(v4),命名空间(v3,v5)
    • 永远没有最佳的技术方案,只要最适合业务场景的技术方案
    点赞 评论 复制链接分享