与许多开发人员一样，我正在寻找一种方法将现有应用程序集成到SQL Azure Federations中，并且替换Identity列（我的表的主键）是一个大问题。
由于很多原因，我不想在我的主键上使用GUID（请不要打开关于GUID的辩论，这不是我的问题：我只是不想要一个GUID，句号）。< / p>
所以我需要构建一个密钥提供程序来替换标准SQL数据库的“身份”功能。我正在使用实体框架，所以我可以在插入之前轻松找到一个地方设置Id值（通过覆盖我的SaveChanges类的ObjectContext方法）。我只需要找到一个“不太复杂”的实现来获取当前的Id，这是“农场就绪”。
我已经阅读了这篇SO帖子：“ID Generation for Sharded Database (Azure Federated Database)”和“Synchronizing Multiple Nodes in Windows Azure来自MSDN杂志”，但这个解决方案对我来说听起来有点复杂。
我正在考虑为每个SQL表创建（自动）一个azure队列，其中包含一个预先加载的连续整数列表。当我想要一个Id值时，我只需要从队列中获取一条消息（该消息变为不可见并在途中被删除），这将为我提供当前可用的Id。
关于“Windows Azure队列”和“Windows Azure服务总线队列”之间的选择，由于"high" latency of Service Bus Queues，我更喜欢“Windows Azure队列”。 我不认为Azure Queues缺乏“订购保证”是一个问题。
您如何看待使用Azure队列提供Id值的想法？您是否认为有任何理由可以放弃这个想法？您是否有更好的想法，甚至是一个好的做法，在SQL Azure Federation数据库中提供整数ID？ 感谢。
编辑：
Astaykov建议SnowMaker。我终于完成了fork of SnowMaker以与Azure存储库的v2完全兼容。
编辑2
请注意 Azure SQL Federation将于2015年9月停用 ，其中包含网络和业务层，正如here所述。但是这个问题对于自定义分片解决方案仍然有效。
答案 0 :(得分：4)
虽然从未在生产中尝试过，但似乎非常合理和可靠。
<强>更新
两件事：您可以安全地引用Azure Storage Client 1.7.XX和Azure.Storage 2.X来使SnowMaker工作。或者修复它以像您一样使用Storage 2。
作为旁注，我个人认为身份并没有解决任何问题，它甚至引入了这样的（但我仍然使用它）。考虑到它给我们的力量和规模，不要认为缺乏身份是联盟的劣势。为了大事，我们必须摆脱由数字自动生成的传统思维。
不幸的是，我还没有真正的联盟项目经验，但我真的很想尝试一下。我知道有大型应用程序部署使用联合并且可以大规模扩展。
答案 1 :(得分：3)
另一个选项是RustFlakes项目。它提供了一种在分布式系统中生成唯一的顺序ID而不会相互冲突的方法。它们与GUID（128位）的大小相同，但由于它们是顺序的，因此它们不会导致您具有GUID的所有页面拆分，索引和相关问题。
答案 2 :(得分：0)
不确定这对您是否有用，因为它不是C＃，但我已经使用0.3.3版本的Nodejs Azure Storage SDK将Snowmaker移植到Nodejs。
您可以使用npm：
进行安装
npm install snowmaker