生物科技公司珠海贝斯昂科获近亿元天使轮融资
06-18
要求：设计一个类似 Pastebin 的 Web 服务，用户可以在其中存储纯文本。该服务的用户将输入一段文本并获得一个随机生成的 URL 来访问它。
类似服务：pastebin.com、pastebin.co、hopapp.com 难度级别：简单 1. 什么是 Pastebin？ Pastebin 等服务使用户能够通过网络（通常是互联网）存储纯文本或图像，并生成唯一的 URL 来访问上传的数据。此类服务还用于通过网络快速共享数据，因为用户只需传递 URL 即可供其他用户查看。
2. 系统要求和目标 我们的 Pastebin 服务应满足以下要求： 功能要求： 1. 用户应该能够上传或“粘贴”他们的数据并获得唯一的 URL 来访问它。 2. 用户只能上传文字。
3.数据和链接将在特定时间间隔后自动过期；用户还应该能够指定过期时间。 4. 用户可以选择粘贴的自定义别名。
非功能要求： 1、系统可靠性高，上传数据不丢失。 2.系统应该是高可用的。
这是必需的，因为如果我们的服务出现故障，用户将无法访问他们的粘贴。 3. 用户应该能够以最小的延迟实时访问他们的粘贴。
4. 粘贴??链接不应是可猜测的（不可预测的）。扩展需求： 1、分析，比如访问paste的次数？ 2.其他服务也应该能够通过REST API访问我们的服务。
3. 一些设计注意事项 Pastebin 具有一些与 URL 缩短服务相同的要求，但我们应该牢记一些额外的设计注意事项。用户一次可以粘贴的文本量的限制是多少？我们可能会将用户的粘贴大小限制为不超过 10MB，以防止滥用服务。
我们应该对自定义 URL 施加大小限制吗？由于我们的服务支持自定义 URL，因此用户可以选择他们喜欢的任何 URL，但提供自定义 URL 不是强制性的。但是，对自定义 URL 施加大小限制是合理的（并且通常是可取的），以便我们拥有一致的 URL 数据库。
补充一点：目前博客网站往往有一个功能叫做自定义域名，而这个自定义域名可以支持我们访问博客内容，同时我们也可以通过博客自己的地址IP来访问。 4.容量估计和限制我们的服务将被大量阅读；读取请求将多于新粘贴。
我们可以假设读写比为5:1。流量估计：Pastebin 服务预计不会有类似于 Twitter 或 Facebook 的流量，假设每天有 100 万个新粘贴添加到我们的系统中。
这让我们每天有 10,000 次阅读。每秒新粘贴数：1M /（24 小时 * 秒）~= 12 粘贴/秒每秒新粘贴读取数：5M /（24 小时 * 秒）~= 58 读取/秒存储估算：用户可上传至 10MB 数据；通常像 Pastebin 这样的服务用于共享源代码、配置或日志。
这样的文本不是很大，所以我们假设每个粘贴平均包含 10KB。按照这个速度，我们每天将存储 10GB 的数据。
1M * 10KB => 10 GB/天 如果我们想将这些数据存储十年，则需要 36TB 的总存储容量。每天有数以万计的贴纸，10年后我们将拥有36亿张贴纸。
我们需要生成并存储密钥来唯一标识这些粘贴。如果我们使用base64编码（[A-Z,A-Z,0-9,,,-]），我们将需要六个字母的字符串： 64^6 ~= 687亿个唯一字符串 如果存储一个字符需要一个字节，那么存储的总大小3.6B 密钥所需的空间为： 3.6B * 6 => 22 GB 与 36TB 相比，22GB 可以忽略不计。
为了保持一些可用空间，我们将采用 70% 容量模型（意味着我们任何时候都不想使用超过总存储容量的 70%），这将使我们的存储需求增加到 51.4TB。带宽估计：对于写入请求，我们预计每秒有 12 个新粘贴，从而每秒传入 KB。
12 * 10KB => KB/s 对于读取请求，我们预计每秒有 58 个请求。因此，（到用户的）总数据输出将为 0.6 MB/s。
58 * 10KB => 0.6 MB/s 虽然总的传入和传出量并不大，但我们在设计服务时应该记住这些数字。内存估算：我们可以缓存一些经常访问的hotpaste。
根据80-20法则，即20%的热贴产生80%的流量。我们希望缓存这 20% 的粘贴。
由于我们每天有 10,000 个读取请求，要缓存 20% 的请求，我们需要： 0.2 * 5M * 10KB ~= 10 GB 5. 系统 API 我们可以使用 SOAP 或 RESTAPI 来公开服务的功能。以下可能是创建/检索/删除粘贴的 API 的定义： addPaste(api_dev_key,aste_data,custom_url=None,user_name=None,paste_name=None,expire_date=None) 参数： api_dev_key (string): api 开发者机密注册的帐户密钥。
除此之外，这将用于根据分配的配额来限制用户。 Paste_data（字符串）：粘贴的文本数据。
custom_url（字符串）：可选的自定义 url。 user_name（字符串）：用于生成 URL 的可选用户名。
粘贴名称（字符串）：粘贴的可选名称。 过期日期（字符串）：粘贴的可选到期日期。
返回：（字符串）成功插入将返回可访问粘贴的 URL，否则将返回错误代码。同样，我们可以检索和删除粘贴 API： getPaste(api_dev_key, api_paste_key) 其中“api_paste_key”是表示要检索的粘贴的粘贴密钥的字符串。
该API将返回粘贴的文本数据。如果删除成功，deletePaste(api_dev_key, api_paste_key) 返回“true”，否则返回“false”。
6. 数据库设计 关于我们存储的数据性质的一些观察： 1. 我们需要存储数十亿条记录。 2.我们存储的每个元数据对象都很小（小于字节）。
3. 我们存储的每个粘贴对象可以是中等大小（可以是几MB）。 4. 记录之间没有任何关系，除非我们想存储哪个用户创建了哪些粘贴。
5. 我们的服务质量非常高。数据库架构：我们需要两个表，一个用于存储有关粘贴的信息，另一个用于存储用户数据。
这里，“URlHash”是相当于TinyURL的URL，“ContentKey”是存储粘贴内容的对象键。 7. 高层设计 在高层，我们需要一个应用程序层来服务所有的读写请求。
应用层将与存储层通信以存储和检索数据。我们可以将存储层与存储与每个粘贴、用户等相关的元数据的数据库和将粘贴内容存储在某些对象存储（如 Amazon S3）中的另一个数据库分开。
这种数据划分还允许我们单独扩展它。 8. 组件设计 A. 应用程序层 我们的应用程序层将处理所有传入和传出的请求。
应用服务器将与后端数据存储组件通信来满足请求。如何处理写请求？收到写入请求后，我们的应用程序服务器将生成一个六字母的随机字符串，该字符串将用作粘贴的密钥（如果用户未提供自定义密钥）。
然后应用服务器会将粘贴的内容和生成的密钥存储在数据库中。插入成功后，服务器可以将密钥返回给用户。
这里可能出现的问题是由于重复的键导致插入失败。因为我们正在生成随机密钥，所以新生成的密钥可能与现有密钥匹配。
在这种情况下，我们应该重新生成一个新密钥并重试。我们应该不断重试，直到没有看到由于重复键而导致的失败。
如果用户提供的自定义密钥已存在于我们的数据库中，我们应该向用户返回错误。上述问题的另一个解决方案是运行独立的密钥生成服务 (KGS)，该服务预先生成随机的六字母字符串并将其存储在数据库中（我们称之为密钥数据库）。
每当我们想要存储新的粘贴时，我们只需获取一个已经生成的密钥并使用它即可。这种方法将使事情变得非常简单和快速，因为我们不会担心重复或冲突。
KGS 将确保插入密钥数据库的所有密钥都是唯一的。 KGS可以使用两张表来存储密钥，一张用于未使用过的密钥，另一个用于所有已使用过的密钥。
只要KGS向应用服务器提供一些密钥，它就可以将这些密钥移动到已使用的密钥表中。 KG总是可以在内存中保留一些密钥，以便服务器在需要时可以快速提供它们。
一旦 KGS 在内存中加载了一些密钥，它就可以将它们移动到已使用的密钥表中，这样我们就可以确保每个服务器都获得唯一的密钥。如果 KGS 在使用内存中加载的所有密钥之前就死掉了，我们将浪费这些密钥。
我们可以忽略这些键，因为我们有很多键。 KGS 不是单点故障吗？是的。
为了解决这个问题，我们可以拥有 KGS 的备份副本，以便在主服务器宕机时接管生成和提供密钥的工作。每个应用服务器是否可以在密钥数据库中缓存一些密钥？是的，这肯定会加快速度。
尽管在这种情况下，如果应用程序服务器在使用所有密钥之前死亡，我们最终将丢失这些密钥。这是可以接受的，因为我们有 68B 唯一的六字母密钥，这比我们需要的多得多。
它如何处理粘贴读取请求？收到读取粘贴请求后，应用服务层将联系数据存储。数据存储将搜索密钥，如果找到，则返回粘贴的内容。
否则，将返回错误代码。B 数据存储层 我们可以将数据存储层分为两层： 1. 元数据数据库：我们可以使用关系数据库（例如 MySQL）或分布式键值存储（例如 Dynamo 或 Cassandra）。
2.对象存储：我们可以将内容存储在对象存储中，例如亚马逊的S3。每当我们想要达到内容存储的最大容量时，我们都可以通过添加更多服务器来轻松增加容量。
9 清除或数据库清除请参考URL短链接设计。 10、数据分区和复制请参考URL短链接设计。
11缓存和负载均衡器请参考URL短链接设计。 12安全和权限请参考URL短链接设计。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-17
06-08
06-06
06-17
06-18
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用