如何以编程方式生成类似 Heroku 的子域名？

Question

我们都见过一些有趣的子域，当您使用简单的“heroku create”将应用程序部署到 Heroku 时，您会自动分配这些子域。

一些示例：blazing-mist-4652、electric-night-4641、morning-frost-5543、radiant-river-7322 等等。

看起来它们都遵循形容词-名词-4 位数字的模式（大部分）。他们是否只是简单地输入一些形容词和名词的字典，然后在您推送应用程序时从中随机选择组合？是否有一个 Ruby gem 可以实现这一点，也许提供一本可以按词性搜索的字典，或者这是需要手动完成的事情？

Answer 1

Heroku API 团队的工程师：我们采用最简单的方法来生成应用程序名称，这基本上就是您所建议的：将形容词和名词数组保留在内存中，从每个元素中随机选择一个元素，并将其与来自的随机数组合1000 到 9999。

这不是我写过的最令人兴奋的代码，但有趣的是看看我们必须做什么才能扩展这个：

• 起初我们正在选择一个名称，试图INSERT 然后挽救唯一性约束错误以选择不同的名称。当我们有大量名称（以及使用它们的不太大的应用程序集）时，这种方法效果很好，但在一定规模上，我们开始注意到名称生成过程中出现了很多冲突。

  为了使其更具弹性，我们决定选择几个名称并通过单个查询检查哪些名称仍然可用。显然，由于竞争条件，我们仍然需要检查错误并重试，但表中的应用程序如此之多，这显然更有效。

  挂钩，以便在我们的名称池不足时收到警报（例如：如果 1/3 的随机名称被占用，则发送警报）。

• 第一次遇到冲突问题时，我们只是从 2 位数字增加到 4 位数字，从根本上增加了名称池的大小。有了 61 个形容词和 74 个名词，这使我们的名称从 ~400k 增加到 ~40mi (61 * 74 * 8999)。

• 但是当我们运行 200 万个应用程序时，我们再次开始收到冲突警报，并且速度比预期高得多：大约一半的名称发生冲突，考虑到我们的池大小和运行的应用程序数量，这毫无意义.

  正如您可能已经猜到的，罪魁祸首是 rand 是一个非常糟糕的伪随机数生成器。使用 SecureRandom 选择随机元素和数字反而从根本上降低了碰撞量，使其符合我们最初的预期。

由于需要进行大量工作来扩展这种方法，我们首先要问是否有更好的方法来生成名称。讨论的一些想法是：

• 使名称生成成为应用程序 ID 的函数。这会快得多，并且完全避免冲突问题，但缺点是，它会浪费大量已删除应用程序的名称（该死的，作为不同集成测试的一部分，我们很快就创建和删除了很多应用程序） .

• 使名称生成具有确定性的另一个选项是在数据库中拥有可用名称池。这将使您可以轻松地执行诸如仅在删除应用程序 2 周后重用名称之类的操作。

很高兴看到下次碰撞警报触发时我们会做什么！

希望这可以帮助任何从事友好名称生成工作的人。

Answer 2

我创建了一个 gem 来执行此操作： RandomUsername

类似的 gem 是 Bazaar 和 Faker。

Answer 3

有几种可能性。

您可以生成随机字符串。

如果你想使用真正的单词，你需要一本字典。然后，您可以创建一个生成单词和数字排列的结果。

另一种不错的选择是 Ruote 采用的方法。 Ruote 依赖 rufus-mnemo 为每个进程生成唯一的名称。 rufus-mnemo 提供了将整数转换为更容易记住的“单词”的方法，反之亦然。

您可以为记录生成唯一的 ID，然后将其转换为单词。

Answer 4

感谢@m1foley，

我正在使用你的 gem https://github.com/polleverywhere/random_username

---

生成随机数名称：

num_size = 2 # you can change this value to change number size
temp_num = (Array.new(num_size) { rand(10).to_s }).join
app_url = RandomUsername.adjective + '-' + RandomUsername.noun + '-' + temp_num

---

解释：

1. 首先生成两位数字
2. ，然后生成形容词
3. ，然后生成名词，
4. 最后用破折号（-）连接：形容词 + 名词 + temp_num

---

一些生成的名称：

# caring-plateau-07
# teal-summer-32
# vivid-snowflake-25
# outrageous-summer-95