水平缩放===>数千小黄人将为您一起完成工作。

垂直缩放===>一个大块头将为您完成所有工作。

让我们从增加资源的扩展需求开始，这样您的系统现在可以处理比以前更多的请求。

当你意识到你的系统越来越慢，无法处理当前的请求数量时，你需要调整系统。

这为您提供了两个选项。要么增加当前使用的服务器中的资源，即增加RAM、CPU、GPU和其他资源的数量。这就是所谓的垂直缩放。

垂直缩放通常代价高昂。它不会使系统具有容错性，即，如果您正在扩展使用单个服务器运行的应用程序，如果该服务器停机，您的系统将停机。在垂直缩放中，线程数量也保持不变。当过程发生时，垂直缩放可能需要系统暂时停止。增加服务器上的资源需要重新启动并关闭系统。

这个问题的另一个解决方案是增加系统中的服务器数量。该解决方案在科技行业中得到了广泛应用。这将最终降低每台服务器的每秒请求速率。如果您需要扩展系统，只需添加另一台服务器即可。您不需要重新启动系统。每个系统中的线程数减少，从而导致高吞吐量。为了将请求平均地分离到每个应用程序服务器，您需要添加负载平衡器，它将充当web服务器的反向代理。整个系统可以称为单个集群。您的系统可能包含大量请求，这些请求需要更多的集群。

希望您了解将缩放引入系统的整个概念。

水平缩放意味着通过向资源池中添加更多机器来进行缩放，而垂直缩放意味着可以通过向现有机器添加更多功率（CPU、RAM）来进行缩放。

记住这一点的一个简单方法是将机器放在服务器机架上，我们在水平方向上添加更多机器，在垂直方向上向机器添加更多资源。

在数据库世界中，水平缩放通常基于数据的分区，即每个节点仅包含部分数据，在垂直缩放中，数据驻留在单个节点上，通过多核进行缩放，即在该机器的CPU和RAM资源之间分散负载。

通过水平扩展，通过将更多机器添加到现有池中，通常更容易动态扩展。垂直扩展通常限于单个机器的容量，超出该容量的扩展通常会导致停机，并有上限。

水平缩放的好例子有Cassandra、MongoDB、Google Cloud Spaner。。垂直缩放的一个很好的例子是MySQL-Amazon RDS（MySQL的云版本）。通过从小型机器切换到大型机器，它提供了一种简单的垂直缩放方式。此过程通常涉及停机时间。

内存数据网格（如GigaSpaces XAP、Coherence等）通常针对水平和垂直缩放进行优化，因为它们不绑定到磁盘。通过分区实现水平扩展，通过多核支持实现垂直扩展。

你可以在我之前的文章中阅读更多关于这个主题的内容：横向扩展与横向扩展以及NOSQL替代方案背后的共同原则

是的，水平缩放意味着添加更多的机器，但这也意味着集群中的机器是相等的。MySQL可以通过使用副本在读取数据方面进行横向扩展，但一旦它达到服务器内存/磁盘的容量，就必须开始在服务器之间分割数据。这变得越来越复杂。由于复制速度通常太慢，无法跟上数据更改速度，因此在副本之间保持数据一致性通常是一个问题。

Couchbase也是一个很棒的NoSQL Horizontal Scaling数据库，用于许多商业高可用性应用程序和游戏，可以说是该类别中性能最高的数据库。它跨集群自动分区数据，添加节点很简单，而且您可以使用商品硬件、更便宜的虚拟机实例（例如，AWS使用大型而不是高内存、高磁盘机器）。它基于Membase（Memcached）构建，但增加了持久性。此外，在Couchbase的情况下，每个节点都可以执行读取和写入，并且在集群中都是平等的，只有故障切换复制（而不是像mySQL那样跨所有服务器进行完整数据集复制）。

性能方面，您可以看到一个优秀的Cisco基准：http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

这里有一篇关于Couchbase架构的博客文章：http://horicky.blogspot.com/2012/07/couchbase-architecture.html

你有一家公司，只有一名员工，但你当时有一个新项目，你雇佣了新的应聘者——这是横向扩展。其中，新候选是新机器，项目是对api的新流量/调用。

作为一个项目，IIT/NIT负责处理所有对api/流量的请求。如果任何时候对你的api有更多的请求，那就解雇他，换成一个高智商的NIT/IIT家伙——这是垂直缩放。

还有一个没有提到的额外架构——基于SQL的数据库服务，它支持水平扩展，而不需要手动分片的复杂性。这些服务在后台进行分片，因此它们使您能够运行传统的SQL数据库，并像使用MongoDB或CouchDB等NoSQL引擎一样进行扩展。我熟悉的两个服务是EnterpriseDB for PostgreSQL和Xeround for MySQL。我看到了Xeround的一篇深入文章，它解释了为什么SQL数据库的扩展很困难，以及它们如何以不同的方式进行扩展——用一点盐来看待这一点，因为这是一篇供应商文章。还可以查看维基百科的云数据库条目，其中对SQL与NoSQL以及服务与自托管进行了很好的解释，列出了每种组合的供应商和扩展选项