2

我听说扩展系统的一种方法是为 Web 服务器、数据库服务器使用不同的机器，甚至为每种类型的服务器使用多个实例

我想知道这如何提高“一台服务器用于一切”模型的性能？这些服务器之间的连接没有瓶颈吗？此外，在从不同的 Web 服务器访问数据库服务器时，您将不得不关心同步。

4

2 回答 2

3

如果您的基础设施足够小，那么是的，1 台服务器（可能）是（可能）最好的做事方式，但是当您的规模开始要求您使用超过 1 台服务器时，扩展您的单个机器的大小可能会变得更多昂贵然后拥有多个更便宜的服务器。这也意味着您可以拥有更多的容错能力（如果一台服务器出现故障，其他服务器可以接管）。至于同步数据，在数据库端通常通过集群或复制来实现，在应用端可以通过memcached或保存到驱动之类的方式来实现，而web服务器本身并不需要同步. 本地网络上的网络瓶颈（就像您的服务器可能来自彼此一样）可以忽略不计。

于 2012-05-08T19:50:23.340 回答
3

拥有大量服务器似乎是一个有吸引力的解决方案。经常发生的一个问题是服务器之间的通信产生的延迟。即使使用光纤互连，它也会比它们驻留在同一台服务器上慢。当然，在单个服务器解决方案中，如果一个服务器应用程序做了很多工作，它可能会耗尽数据库应用程序所需的 CPU 资源。

另一个可能出现的问题是 SAN。SAN 的支持者会说它们与本地连接的存储一样快。SAN 的目的是降低存储成本。即使 SAN 使用与本地解决方案相同的高性能磁盘（消除成本节省），您仍然需要在 SAN 上处理较慢的连接和更多的并发用户。

传统观点认为，数据库应该是基于 SQL 的标准化数据。花一些时间权衡利弊（是的，SQL 有弊端）是值得的。

自从“远古时代”（至少在过去二十年）以来，冷漠的程序员已经用他们懒得在客户端实现的东西使服务器超载。冷漠（或无知）的建筑师允许这种做法继续下去。最终结果：几乎无用的缓慢 c/s 实现。将服务器园区增加三倍是一种绝望的“交付前一周”措施，充其量只会导致性能的边际提升。通常你会失去性能。

数据库不应该被涉及多个表的复杂请求所困扰。由客户端过滤的简单请求是要走的路。

要尝试的一件事可能是将框架/ SOAP 处理放在一台服务器上，并让它向 DB 服务器发送二进制请求，该服务器以二进制响应进行回答（试图理解 SOAP 请求是非常占用 CPU 资源的，而您不这样做'不想留给无论如何都会或多或少窒息的数据库应用程序）。这样，您将让 SOAP 仅限制环境的一部分（用户/其他框架用户的接口），其余接口将尽可能高效（二进制）。

另一件事——如果应用程序允许的话——是在数据库应用程序上放置一个缓存前端。这个缓存的目的是在不涉及数据库本身的情况下做尽可能多的重复性工作。这样，数据库就可以处理更少但（也许）更复杂的请求，而不是做所有事情。

哦，不要让客户端直接向数据库发送 SQL 语句。你会惊讶于数据库必须应对的垃圾。

于 2012-05-20T16:33:27.950 回答