唯一、数字、增量标识符
我需要为我向某个 XML RPC 发出的每个请求生成唯一的、增量的数字事务 ID。 这些数字只需要在我的域中是唯一的，但将在多台计算机上生成。
我真的不想在数据库中跟踪这个数字并在每个事务上处理行锁定等。 我尝试使用微秒时间戳来破解此问题，但仅与几个线程发生冲突 - 我的应用程序需要支持数百个线程。
任何想法，将不胜感激。
编辑：如果每个交易 ID 必须大于前一个请求的 ID，该怎么办？
I need to generate unique, incremental, numeric transaction id's for each request I make to a certain XML RPC. These numbers only need to be unique across my domain, but will be generated on multiple machines.
I really don't want to have to keep track of this number in a database and deal with row locking etc on every single transaction. I tried to hack this using a microsecond timestamp, but there were collisions with just a few threads - my application needs to support hundreds of threads.
Any ideas would be appreciated.
Edit: What if each transaction id just has to be larger than the previous request's?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Google GUID 生成器，用于您要查找的任何语言，然后将其转换如果您确实需要它是数字，则为数字。 但它不是增量的。
或者让每个线程“保留”一千（或一百万，或十亿）个事务 ID 并一次分发一个，并在用完时“保留”下一组。 仍然没有真正增量。
Google for GUID generators for whatever language you are looking for, and then convert that to a number if you really need it to be numeric. It isn't incremental though.
Or have each thread "reserve" a thousand (or million, or billion) transaction IDs and hand them out one at a time, and "reserve" the next bunch when it runs out. Still not really incremental.
我支持 GUID，但如果不可能，您可以考虑使用 db4o 或 SQL Lite 在重量级数据库上？
I'm with the GUID crowd, but if that's not possible, could you consider using db4o or SQL Lite over a heavy-weight database?
如果每个客户端都可以跟踪自己的“下一个 id”，那么您可以与中央服务器通信并获取一系列 id，一次可能是 1000 个。 一旦客户端用完 id，它就必须再次与服务器通信。
这将使您的系统拥有 id 的中央来源，并且仍然避免必须与数据库对话以获取每个 id。
If each client can keep track of its own "next id", then you could talk to a sentral server and get a range of id's, perhaps a 1000 at a time. Once a client runs out of id's, it will have to talk to the server again.
This would make your system have a central source of id's, and still avoid having to talk to the database for every id.
如果您要在数百个线程中使用它，在多台机器上工作，并且需要增量 ID，则您将需要一些集中位置来存储和锁定最后生成的 ID 号。 这不一定必须在数据库中，但这将是最常见的选项。 除了提供 ID 之外什么都不做的中央服务器可以提供相同的功能，但这可能违背了分发此功能的目的。
如果它们需要增量，则任何形式的时间戳都不能保证唯一。
如果您不需要它们是增量的，则可以使用 GUID。 可能对每个系统上的时间戳 + 硬件 ID 进行某种类型的合并可以提供唯一标识符，但 ID 号部分不一定是唯一的。
您可以使用一对硬件 ID + 增量时间戳吗？ 这将使每台特定机器的 ID 递增，但不一定在整个域中是唯一的。
---- 编辑 -----
我认为使用任何形式的时间戳都不适合你，原因有两个。
首先，无论您使用什么分辨率的计时器，您永远无法保证不同机器上的 2 个线程不会尝试在完全相同的时间进行调度。 在足够高的分辨率下，这是不可能的，但不能保证。
其次，为了使这项工作顺利进行，即使您可以解决上述冲突问题，您也必须让每个系统都拥有完全相同的时钟（精确度为微秒），这是不切实际的。
If you're going to be using this from hundreds of threads, working on multiple machines, and require an incremental ID, you're going to need some centralized place to store and lock the last generated ID number. This doesn't necessarily have to be in a database, but that would be the most common option. A central server that did nothing but serve IDs could provide the same functionality, but that probably defeats the purpose of distributing this.
If they need to be incremental, any form of timestamp won't be guaranteed unique.
If you don't need them to be incremental, a GUID would work. Potentially doing some type of merge of the timestamp + a hardware ID on each system could give unique identifiers, but the ID number portion would not necessarily be unique.
Could you use a pair of Hardware IDs + incremental timestamps? This would make each specific machine's IDs incremental, but not necessarily be unique across the entire domain.
---- EDIT -----
I don't think using any form of timestamp is going to work for you, for 2 reasons.
First, you'll never be able to guarantee that 2 threads on different machines won't try to schedule at exactly the same time, no matter what resolution of timer you use. At a high enough resolution, it would be unlikely, but not guaranteed.
Second, to make this work, even if you could resolve the collision issue above, you'd have to get every system to have exactly the same clock with microsecond accuracy, which isn't really practical.
这是一个非常困难的问题，特别是如果您不想造成性能瓶颈的话。 您说 ID 需要是“增量”和“数字”——这是一种具体的业务限制，还是出于其他目的而存在的限制？
如果不需要这些，您可以使用 UUID，大多数常见平台都有相应的库。 它们允许您在很短的时间内生成许多（数百万！） ID，并且非常舒适，不会发生冲突。 维基百科上的相关文章声称：
This is a very difficult problem, particularly if you don't want to create a performance bottleneck. You say that the IDs need to be 'incremental' and 'numeric' -- is that a concrete business constraint, or one that exists for some other purpose?
If these aren't necessary you can use UUIDs, which most common platforms have libraries for. They allow you to generate many (millions!) of IDs in very short timespans and be quite comfortable with no collisions. The relevant article on wikipedia claims:
如果您从要求中删除“增量”，则可以使用 GUID。
我不明白如何在没有某种通用数据的情况下跨多个进程实现增量。
If you remove 'incremental' from your requirements, you could use a GUID.
I don't see how you can implement incremental across multiple processes without some sort of common data.
如果您的目标是 Windows 平台，您是否尝试过 Interlocked API< /a>？
If you target a Windows platform, did you try Interlocked API ?