分布式处理的不同场景

Question

我有一个Web应用程序 - 一个简单的Web应用程序归档文件 - 具有多个用于不同存储类型的存储适配器，即。 MongoDB和CouchDB。通过使用此应用程序，我可以使用我编写的Web服务将数据存储/查询到这些数据库。目前，每个应用程序只能有一个数据库实例，不能有多个阻止我进行并行处理的数据库实例。

---

我想要的是在多台机器上运行我的应用程序。除此之外，我想编写一个UI，使客户端能够在不知道数据库类型/地址的情况下存储/查询数据。

我有两个不同的场景，并想问你哪一个是更好的方法来做到这一点以及为什么。

---

1）假设我有三台运行三个数据库的服务器 - couchdb。我可以将我的应用程序上传到这些服务器，然后借助我的UI或应用程序上方的图层，我可以定义服务器地图，以便我可以存储和查询数据。

如上所述，数据库和应用程序位于同一服务器中，因此它们是远程的。

---

2）假设有三台服务器仍在远程运行，但在这种情况下我的应用程序是本地的。我启用它接受几个数据库实例。

---

我实际上更喜欢第一个，因为在这种情况下我不需要扩展我的应用程序，但我想听听你对它的看法。如果你能为那种分布式场景提供一些资源，我将很高兴 - 我根本没有这方面的经验。

Answer 1

请查看描述Instagram architecture的文章。了解3名工程师每天如何处理15-25百万用户，以及每天1.5亿张照片，这非常有趣。

我还建议interesting博客，它描述了流行网络资源的不同可扩展性解决方案：

• Facebook: An Example Canonical Architecture for Scaling Billions of Messages
• Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter

有很多信息。

但最常见的事情是：

• 尽可能保持一切尽可能轻松
• use well-known, mature technologies, which have good support of the community
• 单独扩展应用程序的每个部分

即使您可能会找到对这些内容的解释，但我还是希望根据您的要求专注于最后一个。

如果要使应用程序可以横向扩展，则需要将每个群集视为单独的逻辑模块，而不管群集中涉及的实际服务器数量。 F.E.对于您的Web应用程序，您可以设置该应用程序的多个实例，并在它们之前设置负载均衡器。因此，用户可以访问单个入口点（例如http://mysite.com），同时实际的实例可能是任意的。

如果您需要在彼此之间协作实例，则需要避免内存存储，但需要使用“密钥值”存储（例如Redis）以及消息代理，例如{{3 }}，ActiveMQ或云版RabbitMQ等。

数据存储您还需要考虑作为单一入口点，例如分片集群（例如，MongoDB支持现成的Iron.IO，大多数NoSQL解决方案也有它 - auto-sharding，CouchDB）。 所以基本上你调用一些shard-controller，根据特定的shard-key重定向到相应的实例。但请注意，通常分片可能是非常重要的事情，因此在大多数情况下，当您处理RDBMS时，您需要使用垂直可伸缩性。

考虑到上述所有内容，我建议你使用这样的结构：

理想情况下，理想情况下所有服务器必须在物理上彼此靠近（例如，在同一数据中心）。但是，如果您要将您的应用程序用作全球范围，那么您需要根据较少的延迟对实例进行分片。这是关于服务器配置的非常有趣的讲座（即使它是关于MongoDb的，我相信一些方法也可能对你的情况有所帮助）：HBase

但是如果不需要将所有服务器用于分布式“map / reduce”计算，并且为了获得结果，您只需要一个特定服务器的实例，在这种情况下我相信场景＃1 是非常适合并且更适合您的需求（如果您在实例之前设置了负载均衡器）。