假以时日，我相信你会找到罪犯的。在此期间，有一个评论，我认为值得推广回答：

• 您正在多个位置生成伪随机UUID。如果没有发现其他错误，请考虑在一个位置生成所有伪随机UUID，或者生成真正的随机UUID *

创建一个UUID服务器。它只是一个生成UUID块的过程。每个块可能包含10，000个（或任何合适的）UUID。在该过程验证每个块不包含重复项之后，该过程将该块写入磁盘。
创建另一个进程来分发UUID块。也许它只是一个web服务，当它收到请求时返回一个未使用的块。交易服务器请求一个区块，然后在创建交易时使用这些UUID。当服务器使用了分配给它的大部分UUID时，它会请求另一个块。

我不会浪费时间去想UUID.randomUUID()是如何每天生成一些重复的UUID的。这种情况发生的几率微乎其微。（如果底层的RNG状态是重复的，那么生成一系列的重复是可能的，但情况似乎并非如此。）
相反，应该寻找一个服务器存储的UUID可能会攻击另一个服务器存储的UUID的地方。为什么50台服务器中只有2台发生这种情况？这与尚未共享的环境和系统的详细信息有关。

如上所述，合法碰撞的机会是不可能的小。更有可能的是，如果值曾经以不正确的方式在对象之间传输。
对于像Java这样的按引用传递的语言，请考虑以下场景

saveObject1.setUUID(initObj.getUUID())
initObj.setUUID(UUID.randomUUID());
saveObject2.setUUID(initObj.getUUID())

在这种情况下，saveObject1和saveObject2将具有相同的值，因为它们都指向相同的对象引用（initObj的UUID引用）。
像这样的问题似乎比实际的UUID更可能是冲突，特别是如果你可以重现它。当然，如果它不是一直发生，那可能是更复杂的事情，比如一个罕见的竞态条件，其中initObj没有及时重新初始化，导致saveObject1和2共享相同的对象引用。

数据库列长度可能会限制您遇到重复的UUID