caching - 唯一 ID 的缓存解决方案

Question

我们想要构建一个唯一 ID 的分布式缓存，用于在应用程序中识别每个事务。UNIQUE ID 是使用 java 代码中的一些自定义逻辑（比如 DATE +一些随机数）生成的。

该应用程序在 8 个应用程序服务器中运行（负载平衡）。一旦应用程序使用了 UNIQUE ID，就需要使用先前使用的值更新缓存。所以缓存对象更新应该在多线程环境中完成。

在每个应用程序服务器中保留本地缓存是否更好（每个节点特定的唯一 ID 生成序列）。但这并不能保证应用程序中的事务 ID 顺序。

我们一直在寻找 hazlecast、geode、ignite 等选项来构建分布式缓存（点对点缓存）。但是当在多线程环境中进行缓存更新时，哪一个会更好。

哪种缓存解决方案/模型最适合这个问题。

标签： cachingunique-id

Answer 1

不需要缓存

您的问题不需要缓存解决方案。

您可以生成通用唯一标识符，而无需在系统之间进行协调。

UUID

一个合适的解决方案已经被发明、标准化、实施和广泛采用：UUID

版本 1 UUID 代表空间和时间点，将当前时刻与机器的MAC 地址一起添加，并添加一个任意数字，该数字在主机时钟重置时递增，在 UUID 生成器重新启动时递增。

所有这些数据都以 128 位的值表示，并指定了哪些位代表哪些数据。用于向人类显示文本的规范格式使用由连字符分隔的十六进制字符。

例子：

1154cf8a-6f7b-11ea-bc55-0242ac130003

您要求：

自定义逻辑（比如 DATE +一些随机数）

如上所述，某些版本的 UUID 仅包含日期时间加上任意数字以及其他信息。听起来您的团队正在不明智地重新发明轮子。

UUID 在 IT 行业中被广泛使用。您将在电子邮件标题中找到它们以识别每条消息。您会发现它们是交易 ID。您会发现它们是对象 ID。

UUID 生成器实现几乎内置于所有操作系统（macOS、Linux、BSD、Windows 等）中。库是公开的，例如OSSP uuid。Postgres 等功能更强大的数据库支持 UUID 作为本机数据类型，以实现高效存储和易用性。一些软件平台（例如 Java）包括 UUID 的数据类型和生成器实现。

UUID 的目的是各种软件系统可以自己动态地生成 UUID 值，不需要中央机构，不需要分布式缓存，也不需要与其他系统协调。