（3）go web开发之 基于雪花算法生成用户ID与自增id，uuid对比

• 摘自一篇文章开头：
• 讲的很清晰，可以看看概念和对比https://blog.youkuaiyun.com/qq_40950903/article/details/108589837
  
• B站讲解 B树，B+树的视频，还有mysql索引
  • https://www.bilibili.com/video/BV1qE411273M?spm_id_from=333.999
  • https://www.bilibili.com/video/BV1e5411T77z?spm_id_from=333.999.0.0
  • https://www.bilibili.com/video/BV1qb4y1Q7db?p=1

一： 为啥不用自增id作为用户的id？

• 有两方面的考虑：
  • （1）首先： id长度不一，且太具有顺序性！数据安全性差！ 轻易就可以知道自己是该站点第几个注册的用户。并且如果是注册的新用户，还可以知道当前站点已经有多少个注册用户！ 这是不太好的，信息安全问题。
  • （2）其次: 数据量庞大，进行分库分表的时候， 不同库中的用户id可能发生重复。假设第一个库已经有 1亿个用户，那为了保证不重复，第二个机器，或者表，只能从大于 一亿的 位置开始。 且，必须要大于1亿很多，因为第一台机器还会继续增长，可能导致增长过程中重复！

二：为啥不使用uuid？

• 啥是 uuid？来自百度百科的截图。 （我之前写登录时，图形验证码的保存，也用到过 uuid，当做key存储进redis）
  • 目前最广泛应用的UUID，是微软公司的全局唯一标识符（GUID），而其他重要的应用，则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等
  • uuid 是一长串用 - 分隔的 字符， 图中介绍描述uuid 有 128长， 32字节表示。并且是无序的！这点很关键。 我在B站上看到讲解 B+树和mysql 索引的文章，其中讲到 页结构，和插入数据的过程
    
  • 默认插入数据会以主键作为索引，建立聚簇索引。 在磁盘中将数据读取是按照页（逻辑单位）进行的。 每一页的大小默认是 16KB。因为作为主键的话，内部插入默认排序。 uuid是无序的，导致每次的插入结果不一定，增加时间开销。 如果是自增id，每次都是在后面进行插入了。
  • 每一次UUID数据的插入都会对主键的b+树进行很大的修改，这一点很不好，插入完全无序，不但会导致一些中间节点产生分裂，也会白白创造出很多不饱和的节点，这样大大降低了数据库插入的性能。
    • 顺序的插入，总数能不断达到饱和节点，每个节点存储足够多的关键字。 随意插入还需要判断往哪插入，插入的当前页，可能会造成分裂，改变B+树结构。
    • 插入效率低。

三：雪花算法（snowflake）

• 雪花算法是Twitter开源的由64位整数组成的分布式ID，性能较高，并且在单机上递增。
  

  • 全长64位。
  • 第一部分，是1bit：