为什么要这样升华呢？因为这段话里，我们很明显的埋下了两颗雷，一个是全局递增，一个是独一无二。也就是说这个亮点方案保证不了这两点，可能会被面试官追问这两个点。
问题：这个方案能够保证主键递增吗？
这个保证不了，但是能够做到大体上是递增的。可以设想，同一时刻如果有两个用户来创建订单，其中用户ID为2345的先创建，用户ID为1234的后创建，很显然用户1234会产生一个比用户2345更小的订单ID；又或者同一时刻一个买家创建了两个订单，但是第三段是随机数，第一次100，第二次99，显然第一次产生的ID更大。
但是这并不妨碍我们认为，随着时间推移，后一时刻产生的ID肯定比前一时刻产生的ID要大。这样一来，虽然性能比不上完全严格递增的主键好，但是比完全随机的主键好。
这个方案不能保证ID唯一，但是这并不是一个很大的问题。
可以想到，不能保证独一无二是因为在第三段里使用了随机数，既然是随机数，就可能随机到同样的数字。但是，产生冲突ID的可能性是很低的。它要求同一时刻同一个用户创建了两个订单，然后订单ID的随机数部分随机到了同一个数字。
产生一样ID的概率不是没有，而是极低，他还要求同一个用户在同一时刻创建了两个订单，然后订单ID的随机数部分一模一样，这是一个很低的概率。
在下单场景下，正常的用户都是一个个订单慢慢下，如果同一时刻同时创建两个订单，对于用户来说，是一件不可能的事情。而如果有攻击者下单，那就更加无所谓，失败就失败了。而即使真的由用户因为共享账号之类的问题同一时刻下两个订单，那么随机到同一个数的概率也是十万分之一。（这里的十万分之一，是假设产生的随机数的范围是0到十万）
解决方案也很简单，就是在插入数据的时候，如果返回了主键冲突，就重新产生一个，再次尝试就可以了。
还想继续刷亮点的话，可以假装不经意地说：
实际上，还有一种非常偶发性的因素也可能会引起 ID 冲突，也就是时钟回拨，不过相比正统雪花算法，时钟回拨问题在这个方案里面不太严重，毕竟还有一个随机数的部分。
时钟回拨现象指的是系统时钟被调整到之前的时间，这通常发生在服务器或系统时间同步时。在分布式系统中，如果使用基于时间戳生成的主键策略（如雪花算法），时钟回拨可能会导致ID冲突。
