我有一个高端架构，每秒接收很多请求（事实上，它可以每毫秒接收很多请求）。该体系结构的设计使得某些控件依赖于为每个请求分配的某个唯一标识。使用数据库序列的策略？
要创建这样的UID，我们使用DB2序列。现在我已经明白这种方法是有缺陷的，因为使用数据库代价昂贵，但这样做是有道理的，因为这个值也将用于记录数据库的信息。
我们的团队刚刚发现，每次交易的流逝时间增加了近1000％，我们认为这是因为顺序而发生的。现在我想知道，使用序列将序列化访问我的应用程序？由于他们必须保证增量以他们应该的方式工作，他们必须，对吧？
那么，使用序列时有更好的策略吗？请假定除了依赖数据库之外，我没有其他方式获得唯一的ID。
使用序列必然会序列化您的应用程序。但是，这些事情被优化以具有最小化影响。当然，我们总是可以通过无用的方式宣布事情来弥补自己。那么，这个序列是如何定义的？它有一个大的CACHE？你有没有指定NO ORDER？
说到这....
，从你的问题跃起出来的东西是不是在大胆的词组，它是句之前：
“我的团队刚刚发现 每次交易的经过时间几乎增加 ，我们假设发生 因为 序列。“
我们都知道ASSUME是怎么做的（在这种情况下不是这样，因为我什么也不假）。最近的变化是否影响到这个序列？如果没有，为什么你们都认为这是导致业绩突然下降1000％的原因？不要假设（即猜测）或许收集一些证据会更好。那个时候正在某个地方，你需要发现哪里。如果在代码的某处存在竞争条件，或者正在刻录CPU等待锁定，或者存在互连不良（正在减慢写入SAN等）等情况，则调整序列毫无意义。
是否有任何记录或跟踪已打开，或者您可以打开？您能否在其他环境中重现这种放缓，例如开发或系统测试？这可能是序列的责任。至少可以让你知道自己正在解决真正的问题，从而有信心地完成重新设计任务。
获取可能相关ID的一种可能方法是使用UUID/GUID。虽然我不知道如何产生这些价值，但绝对不会遇到您担心的序列化问题。
有一个团队专门对应用程序进行性能分析。我们从数据库分析和环境分析中收集了一些数据。但是，我们无法确定是否引入了导致巨大影响的序列，因为分析工具有所限制。不过，我会尽量确保时间增加是由于序列造成的。关于序列参数，应该在这样的并行应用程序中调整哪些参数？ – 2010-04-14 18:33:46