我有一个高端架构，每秒接收很多请求（实际上，它每毫秒可以接收很多请求）。该体系结构的设计使得某些控件依赖于分配给每个请求的某个唯一 ID。
要创建这样的 UID，我们使用 DB2 序列。现在我已经明白这种方法是有缺陷的，因为使用数据库的成本很高，但这样做是有意义的，因为这个值也将用于记录数据库上的信息。
我的团队刚刚发现每笔交易的经过时间增加了近 1000%，我们假设这是由于顺序而发生的。现在我想知道，使用序列会序列化对我的应用程序的访问吗？既然他们必须保证增量按应有的方式工作，他们就必须这样做，对吗？
那么，使用序列时有更好的策略吗？请假设除了依赖数据库之外，我没有其他方法可以获取唯一 ID。
【问题讨论】：
标签： parallel-processing database
使用序列必然会序列化您的应用程序。但是，这些东西经过优化以产生最小的影响。当然，我们总是可以通过以无益的方式声明事情来搞砸自己的事情。那么，这个序列是如何定义的呢？它有一个大的缓存吗？您是否指定无订单？
话虽如此......
从你的问题中跳出来的不是粗体字，而是它前面的句子：
“我的团队刚刚发现增加了 几乎 1000% 在经过的时间 每笔交易，我们是 假设发生是因为 序列。”
我们都知道 ASSUME 做什么（在这种情况下不知道，因为我什么都不假设）。最近是否有影响此序列的变化？如果不是，为什么你们都认为它是导致业绩突然 1000% 下滑的原因？与其假设（即猜测），不如收集一些证据。那个时间正在某个地方，你需要发现在哪里。如果您的代码中存在竞争条件，或者您正在消耗 CPU 等待锁定，或者您的互连不良导致写入 SAN 的速度变慢等等，那么调整您的序列是没有意义的。
您是否打开了任何日志记录或跟踪，或者您可以打开？您能否在另一个环境（例如开发或系统测试）中重现这种减速？这可能是顺序的罪魁祸首。至少，您可以自信地处理重新设计的任务，知道您正在解决真正的问题。
【讨论】：
获取可能相关的 ID 的一种可能方法是使用 UUID/GUID。虽然我不知道生成这些值的要求有多高，但它绝对不会受到您担心的序列化问题的影响。
【讨论】：