UUID为什么不用在分布式系统

UUID标准说明

         UUID的标准形式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID。

• UUID Version 1：基于时间的UUID

             基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址，这个版本的UUID可以保证在全球范围的唯一性。

• UUID Version 2：DCE安全的UUID

             DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。

• UUID Version 3：基于名字的UUID（MD5）

            基于名字的UUID通过计算名字和名字空间的MD5散列值得到。

• UUID Version 4：随机UUID。

            根据随机数，或者伪随机数生成UUID。

• UUID Version 5：基于名字的UUID（SHA1）

            和Version 3的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法。

【优点】

• 非常简单，本地生成，代码方便，API调用方便。
• 性能非高。生成的id性能非常好，没有网络消耗，基本不会有性能问题。
• 全球唯一。在数据库迁移、系统数据合并、或者数据库变更的情况下，可以 从容应对。（单机多进程会造成重复）

【缺点】

• 存储成本高。UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。如果是海量数据库，就需要考虑存储量的问题。
• 信息不安全。基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
• 不适用作为主键。ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用。UUID往往是使用字符串存储，查询的效率比较低。
• UUID是无序的。不是单调递增的，而现阶段主流的数据库主键索引都是选用的B+树索引，对于无序长度过长的主键插入效率比较低。
• 传输数据量大。
• 不可读。

需要更换雪花算法ID