Question

以前我使用找到的here类将userID转换为一些随机字符串。

来自他的博客：

运行：

alphaID(9007199254740989);

将返回'PpQXn7COf'和：

alphaID('PpQXn7COf', true);

将返回'9007199254740989'

所以想法是用户可以做www.mysite.com/user/PpQXn7COf并将其转换为普通整数，所以我可以在mysql中做到

"Select * from Users where userID=".alphaID('PpQXn7COf', true)

现在我刚刚开始与Cassandra合作，我正在寻找替代品。

我想像www.mysite.com/user/PpQXn7COf这样的网址不像www.mysite.com/user/username1
“PpQXn7COf”uuid必须尽可能短。

在这里解释的Twissandra示例中：http://www.rackspace.com/cloud/blog/2010/05/12/cassandra-by-example/

他们创造了一些很长的uuid（我猜它是如此之长，因为它几乎100％肯定它是随机的）。

在mysql中，我只有一个自动增加的userID列，所以当我使用alphaID（）函数时，我总是得到一个非常短的随机字符串。

任何人都知道如何尽可能地解决这个问题？

修改

它用于社交媒体网站，因此必须具有持久性。这也是为什么我不想在网址中使用用户名/真实姓名的原因，如果用户需要，用户无法保持谷歌不被发现。

我只是一个简单的想法，但我不知道它的可扩展性

<?php
//createUUID() makes +- 14 char string with A-Z a-z 1-0 based on micro/milli/nanoseconds
while(get_count(createUUID()) > 0){//uuid  is unique
  //insert username pass, uuid etc into cassandra
  if($result == "1"){
      header('Location: http://www.mysite.com/usercenter');
  }else{
      echo "error";
  }
}
?>

当这个大小让我们说twitter / facebook：

会在可接受的时间内执行吗？
它是否仍会足够快地生成唯一的uuid，所以如果10000个用户/秒正在注册它不会混乱？

Answer 1

自动增量不适用于强大的分布式系统。如果系统中的每个节点都可用，则只能分配唯一的ID，以确保它是唯一的。

您当然可以创建自己的unique-id生成器，但必须确保它会在您的基础架构中的任何位置生成唯一ID。

例如，每个节点可以只有一个文件（具有合适的锁定等）只是递增，但您还需要确保它们不会发生冲突 - 例如，通过在生成中包含服务器ID算法

这可能在操作上非常重要 - 您的操作工程师需要确保基础架构中的所有服务器都已正确配置并设置了自己的ID生成器，以便它们不会生成相同的ID。但是，这是可能的。

UUID是合理的选择，因为它们肯定是唯一的。

UUID是128位;如果我们每个字符存储6位（即base64）则需要22个字符，这是一个相当长的URI。如果您希望缩短它，则需要以不同的方式生成唯一ID。

另外，这完全取决于您实际需要ID的“独特性”。如果您的ID可以在几个月后安全地重复使用，那么您可以在＆lt; 60位（取决于基础架构中的服务器数量，以及生成它们的频率）。

我们使用

服务器ID
时间（粒度= 2秒），但几个月后换行
每服务器计数器（频繁包装但不在2秒内）

将所有的东西粘在一起。这产生了一个＆lt; 64位长，但保证在它需要的时间长度内是唯一的（在我们的情况下只有几个月）

如果出现以下情况，我们的算法会出现故障并生成重复ID：

我们其中一个节点上的系统时钟倒退计数器包裹的时间相同。
我们的运营工程师犯了一个错误，并为两台服务器分配了相同的服务器ID。
最终，大约9个月后。

从Mysql迁移到Cassandra

1 个答案: