在工作中关于雪花算法的一些思考

关于雪花算法的一些思考

大家好。最近思考到一些主键的生成策略。由于当前公司普遍采用一种与业务上固定标识的id相拼接的字符串，主键的索引优势没有很大程度的利用起来，所以参考了一些主键的生成策略。

1、主键自增

在初入公司的时候，尝试使用过，因为使用自增id作为主键，并且业务中并没有使用外键约束与其绑定。这样虽然能够很大程度上进行解耦，但是在关联查询的时候比较麻烦。

实例

报警分类信息

报警信息

考虑到耦合等因素，将报警分类信息与报警信息分离。

这样做的一个好处就是处理报警时，能够直接查找到相关的信息。但是与之带来的问题就是保存了大量的重复性数据，极大的浪费了存储空间，并且在后续进行关联查找的时候，只能根据对应的字段从报警分类中查找。无法利用主键的便利

2、UUID

uuid是通过使用java.util提供的内部工具，随机生成一个32个长度的字符串。如果在数据量比较大的情况下，还是会偶尔出现id重复的问题。但是uuid最大的弊端在于主键通过字符串保存，数据库查询时，效率较低。

3、固定标识+时间戳+随机数

在没有使用雪花算法之前，这种也是普遍id的存储方法。由于数据源产生分布在1000多个子程序上。这些程序上传数据的时间以及频率都是未知的。为了更好的查询以及确定唯一性。所以使用了固定标识来与时间戳来确定是哪一个子程序回传的，考虑并发性，如果在毫秒级上传多条，所以还拼接了2位随机数来保证id唯一性。但是这种存储无异加大了存储的压力。

4、业务上互相标识的字符串 + “|” 相互拼接

这种在公司业务中也常常应用到。最重要的优点之一就是插入时确保了数据唯一。日常操作起来也是很方便的，但是缺点是使用字符串来保存，不利于建立主键索引。

5、雪花算法

分布式下的普遍id自增算法。

Twitter的Snowflake 算法

分布式系统中，有一些需要使用全局唯一ID的场景，有些时候我们希望能使用一种简单一些的ID，并且希望ID能够按照时间有序生成。

① 第1位代表正负 默认为0 代表正数

② 剩下41位代表毫秒级的时间戳。大概可以使用69年

③ 剩下10位工作id中，其中前5位代表数据中心id，也就是集群，剩下5位代表节点id

④剩下12位代表毫秒内的技术。也就是1个集群中的一个节点1毫秒内最多可以生成4096个id

如果使用雪花算法生成的id。会生成一个19位长度。此时存储会极大的降低数据库存储的压力，并且能够极大的提升数据库索引查询的效率。（如果向数据库中插入id不规则，每一次都会导致索引的重排列，降低数据库的性能）