生成主键：通过从 Id 库存中提取，保存在 Web 应用程序的应用层
我正在使用分布式 NoSQL DB 构建一个 Web 应用程序。但是，为了为新实体生成 Id，我使用 MySQL 作为 Flickr 的票证服务器
我刚刚想到了将 Id 的库存保留在应用程序层的想法，以便可以快速地轻松地为新实体分配 id ，无需从数据库中逐一获取它们。相反，我可以从数据库中提取一些 Id，比如大约 1000 个，并使用它们直到堆栈达到剩余 Id 的一定限制，此时我将从数据库中提取更多 Id 来再次填充堆栈。
感谢您对此的想法和想法。
I am building a web application using a distrbuted NoSQL DB. However, for generating Ids for the new entities, I am using MySQL as Flickr's ticket server
I just stuck across an idea of keeping the stock of Ids at the application layer, so that newer entities may be easily allotted ids in a fast manner, without the need for fetching from DB, one by one, for each of them. Instead I can just pull a stock of Ids from the DB say around 1000, and use them uptil stack reaches a certain limit of remaining Ids, when I'll pull more of Ids from DB to fill the stack again.
Your ideas and thoughts upon this appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个好主意，除非您需要 id 是连续的，并且某些 id 从未被使用也没关系。
例如，当 SAP ERP 没有订购要求并且可能有“漏洞”时，SAP ERP 会对所谓的“编号范围”执行此操作（可配置）。每个应用程序服务器将请求一组密钥而不是一个密钥，并从该缓存中提供它们。它会在必要时重新填充其缓存。这节省了相当多的往返次数和数据库锁定。
如果应用程序服务器出现故障（或系统停止），则缓存中存在但尚未分发的任何 id 都会丢失（即永远不会被使用）。如果您只需要一个唯一的 ID，有时这很好。如果序列中不能有漏洞（在某些国家/地区，业务文档编号（例如发票编号）会发生这种情况），那就完全不行了。
That's a good idea unless you need your ids to be sequential, and that it is ok that some ids are never used.
e.g. the SAP ERP does this (configurably) for what it calls "number ranges" when they have no ordering requirement and can have "holes". Each application server will request a set of keys rather than just one, and serve them out of this cache. It refills its cache whenever necessary. This saves quite some round trips and locking on the DB.
If an app server goes down (or the system is stopped), whatever ids that were present in the cache but not yet handed out are lost (i.e. will never be used). This is sometimes fine if all you need is a unique id. Not fine at all if you can't have holes in the sequences (which happens for business document numbers (like invoice numbers for example) in some countries).
虽然这可行，但您可能会增加不必要的复杂性。
通用唯一 ID 正是针对这种情况而设计的。 之前的答案包含一个纯 PHP UUIDv4 生成器，如果您不想使用UUID PECL 扩展。
UUID 的主要缺点是它们丑陋，尽管它们可以以其他长得离谱的形式表示。
While this will work, you're probably adding unnecessary complexity.
Universally Unique IDs are designed for exactly this case. A previous answer here on SO contains a pure-PHP UUIDv4 generator, if you don't feel like using the UUID PECL extension.
The major downside of UUIDs is that they're ugly, though they can be represented in other forms that are merely freakishly long.