我们究竟如何为**跨所有分片运行**的应用程序提供无缝的自动化密钥生成方法
http://www.dbshards.com/articles/database-sharding-whitepapers/< /a>:
自动增量密钥管理。典型的自增功能 由数据库管理系统提供生成一个顺序键 插入数据库的每个新行。这对于单身来说很好 数据库应用程序，但使用数据库分片时，键必须是 以协调的方式管理所有分片。要求 这里是提供一种无缝的、自动化的密钥生成方法 应用程序，一个跨所有分片运行的应用程序，确保 密钥在整个系统中是唯一的。
我无法理解我们究竟如何为跨所有分片操作的应用程序提供无缝的自动化密钥生成方法。
我听说过使用 GUID，但是 由于 GUID 不能保证在不同机器上是唯一的，我不知道它如何可靠地工作
http://www.dbshards.com/articles/database-sharding-whitepapers/:
Auto-increment key management. Typical auto-increment functionality
provided by database management systems generate a sequential key for
each new row inserted into the database. This is fine for a single
database application, but when using Database Sharding, keys must be
managed across all shards in a coordinated fashion. The requirement
here is to provide a seamless, automated method of key generation to
the application, one that operates across all shards, ensuring that
keys are unique across the entire system.
I cannot understand how exactly could we provide a seamless automated method of key generation to the application that operates across all shards.
I have heard of using GUID, but since GUID isn't guaranteed to be unique across different machines, I do not see how that is going to work reliably
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于 MySQL，您可以使用服务器变量 auto_increment_increment和<一个href="http://dev.mysql.com/doc/refman/5.0/en/replication-options-master.html#sysvar_auto_increment_offset" rel="nofollow">auto_increment_offset 让不同的服务器生成不同的 ID避免碰撞。正确配置服务器完全取决于您，这样您就不会得到重复的值。
For MySQL you can use the server variables auto_increment_increment and auto_increment_offset to have different servers generate different Ids to avoid collisions. It is entirely up to you to configure your properly servers so that you don't end up with duplicate values.
我在开发的分布式数据库系统中遇到了这个问题，当我改用 GUID 作为主要唯一标识符时，所有问题都消失了。我强烈推荐他们。您不仅可以确定标识符在单个键定义数据域中是唯一的，而且还可以拥有引用多个域的通用表。
我还学会了不要依赖业务数据来获得数据库中真正的唯一键，客户认为这些键是唯一的，但当他们想要更改它们时总是会发生事件，并且很多时候会出现未定义的情况。
I struggled with this for a distributed database system I developed, all problems went away when I switch to using GUIDs as primary unique identifiers. I highly recommend them. Not only do you fine identifiers are unique within a single key definition data domain, but you will fine that you can have universal tables that reference multiple domains.
I have also learn not to rely on business data for a true unique key in the database, customers think these keys are unique but there are always incidents when they want to change them and many times have an undefined situation.