URL缩短:数据分区

Question

关于这个问题，我已经在很多地方找过了--大多数谷歌顶级搜索结果都是从单一来源复制粘贴的，而其他搜索结果则没有什么特别的帮助。不确定我是否被允许包括我的搜索链接-所以暂时克制。

URL缩短有两个方面：

1. 写:得到一个长URL，写一个短的和长的映射，返回短的URL。
2. 阅读:获取一个短URL :找到长URL，并可能重定向到它。

我看到的常见设计是：

> (Key Generation service) ----> (Application server)
>         |                              |
>         |                              |
>         |                              |
>         V                              V
>     (Key DB)                    DB with Short vs Long mapping

似乎同一应用服务器正在执行读和写活动。

现在，对于数据分区，我从几乎所有地方都得到了一个建议:将长URL散列(可能是一致的)到特定的server.This只会在写方面有所帮助。为了阅读，我们需要检查每个应用服务器:您有这个短URL的长URL吗？每个人都承认阅读对这个设计来说比写作重要得多。所以他们正在为最不重要的用例进行优化？

我是不是错过了一些很基本的东西？

Answer 1

在处理分布式系统时，由于网络分区或网络上的延迟，您必须使用接受这样一个事实:在某一时刻，节点将看到不同的数据。。一旦您接受了这一点，您就可以决定应用程序将做什么。你会抛出一个错误吗?你会尝试重建数据吗?你会去其他地方寻找数据吗?你会显示陈旧的信息吗？

我无法从您在问题中提供的信息中了解您的确切用例，因此，当我这样说时，我做了一些假设：

• 你可以复制这些文字。一旦写到服务器上，将一个长URL映射到一个短URL，您就这样做了，在该服务器上写入数据，然后将数据发送到所有其他服务器来存储它。当读取请求一个短URL时，无论您是哪一台服务器，您都已经有了数据。
• 当然，如前所述，服务器可能会看到不同的数据。前一点适用于所有接收数据并在数据库中更新数据的服务器。如果某些服务器由于某种原因而脱机，则当它们重新联机时，会丢失一些数据。如果您收到这样一台服务器上缺少的东西的读取，您可以去询问其他服务器是否有它。一旦在服务器上接收到数据，就可以存储数据，这样就不必再查找数据了。您还可能有一些周期性的作业来同步服务器之间的数据，而不需要询问数据，而不是懒洋洋地按需执行。
• 在某些时候，您仍然可能没有数据，也无法检索数据，在这种情况下，您需要决定要做什么:使用错误消息失败，告诉用户稍后返回，关闭该节点等等，这取决于您的用例。

这种方法与缓存的工作方式没有太大区别:在缓存中获取所请求的数据？发球。如果不是，从主数据源检索它，存储它，服务它。例如，您还可以查看DNS如何工作，并从那里借用一些想法，因为从短URL到长URL的映射与从URL到IP的映射并没有太大的不同。

Answer 2

一种选择是在生成的微小url中包含一个碎片id。例如，让小url的前n个字符表示碎片id。然后，当读取请求传入时，负载均衡器将前n个字符解析出来，并使用它们将请求重定向到正确的应用服务器(S)。这里明显的缺点是它会使你的小url长度增加n个字符。

另外，为了说明为什么您可能希望使用分区，即使数据适合在一台机器上(就像在本例中那样)。一个原因可能是查询吞吐量。在分区上，查询将针对较小的数据量运行，从而使它们更快。另一个原因可能是想要在不同的(也许更便宜)上存储旧的(可能是较少被访问的数据)。存储。我发现这篇文章在推理这些事情时非常有用：https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning