生成 int32 和 int32 的唯一主 ID int64 大小
我正在使用 Java 和分布式 noSQL DB（Cassandra）开发社交网络应用程序。 我需要分别为应用程序上的新用户和帖子生成 id，大小分别为 32 位和 64 位。
由于构建在分布式平台之上，我们的问题生成 ids/key 变得更加复杂。尽管已经出现了像 Zookeeper/ 或 twitter 的雪花这样的解决方案，它们一直在尝试缓解这种痛苦，但这些解决方案似乎并不简单易用。
从顶层的角度审视这些解决方案后，我觉得选择最简单、最成熟的解决方案。 在我看来，像 flickr 票务服务器那样使用 MySQL 数据库是第一选择，因为它似乎是最简单的解决方案。
http://code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
我知道这会在分布式系统周围创建 SPOF。但我仍然相信这将是我早期最简单的解决方案（当我在资本和人力方面的资源较少时）。当我的应用程序增长时，我相信切换并不困难，因为它们不需要传输大量数据。因此，对于我的应用程序的初始状态，我想 MySQL 可以以最好、最简单的方式为我服务来生成 Id。
做出此选择的主要因素：-
1. Easier Implementation
2. Easy switching anytime in the future
3. Mature
4. MySQL may be required for our other needs as well, already
我正在考虑最初使用单个 MySQL 服务器，然后切换到两台服务器（如 flickr 的解决方案）以消除 SPOF。
可以有人指出当我考虑切换到像 Zookeeper 或 Snowflake 这样的替代解决方案时可能会出现什么问题？或者当前提议的方法可能有哪些缺点？
非常感谢您的宝贵时间！
I am developing a social web application using Java and a distributed noSQL DB(Cassandra).
I need to generate ids for new users and posts on the application in the sizes of 32bits and 64 bits respectively.
Because of building on top of a distributed platform, our problem of generating ids/keys has become somewhat more complicated. Although there have come solutions like Zookeeper/ or twitter's snowflake which have helpfully been trying to alleviate this pain, but these solutions do not seem to simple to just use.
After looking at these solutions from a top level view, I feel going with the most simple solution and most mature. Using MySQL database like the way flickr's ticket servers, comes to my mind as the first preference as it seems to be the most easiest solution.
http://code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
I know that will create SPOF around a distributed system.. but still I believe this would be the most easiest solution for my early days(when I have less resources in terms of capital and manpower). When my application grows I believe switching would be no difficult as they is no heavy data to be transferred. So for the infancy state of my application I guess MySQL can serve me in the best and simplest manner to generate Ids.
Major factors for this choice:-
1. Easier Implementation
2. Easy switching anytime in the future
3. Mature
4. MySQL may be required for our other needs as well, already
I am thinking of using a single MySQL server initially and later switch to like two servers as flickr's solution inorder to remove SPOF.
Can somebody point out what issues may arise later when I consider switching to an alternate solution like zookeeper or snowflake? Or what may be the downsides of proposed current approach?
Thanks a lot for your time!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，最简单的解决方案是使用分布式 dbms 提供的标识符。这样可以避免使用
另一个操作系统
另一个 dbms
而且您可能需要顺序性比您想要要少得多。
它将产生多个单点故障。除了磁盘之外，每个服务器硬件很可能都存在单点故障。 （你要在那里安装多少个电源？有多少个磁盘控制器？有多少个网卡？）也存在大量的软件单点故障。
No, the easiest solution is to use the identifiers that your distributed dbms provides. That way avoids
another operating system
another dbms
And you probably need sequentiality a lot less than you want it.
It will create multiple single points of failure. Odds are good that each piece of server hardware, except possibly the disks, are single points of failure. (How many power supplies are you going to put in there? How many disk controllers? How many NICs?) There are a legion of software single points of failure, too.