如果您的应用程序遇到负载问题，请抽香槟！您的Web应用程序必须相当成功才能到达此阶段。您已经达到您的应用程序可以处理的用户数量，事情开始变慢并出现错误。网络请求开始超时，数据库查询需要一段时间才能执行，页面加载缓慢。恭喜！您的应用已准备好扩展！但是是时候放下香槟了……您需要应对这些成长的烦恼，直到用户离开您的应用程序，否则竞争对手会抄袭您的想法。缩放成本在对数据库进行垂直、水平和由内而外*分区之前，请牢记一个重要原则。您不应实施过早的优化或尝试在实际需要时扩展您的应用程序。实施扩展解决方案会带来以下复杂性：添加新功能需要更长的时间系统变得更加复杂，涉及更多的部分和变量代码可能更难测试查找和修复错误变得更加困难应用程序处于满载状态。保持系统简单，除非有必要，否则不要引入扩展复杂性。由内而外的数据库分片并不是真正的解决方案。关键是有各种各样的扩展解决方案，除非你需要，否则不要实施它们！使用指标查找瓶颈每个应用程序/系统都是不同的，要决定实施哪种扩展解决方案，您必须首先确定瓶颈在哪里。是时候检查您的资源监控系统了，或者如果您还没有创建一个。无论您使用何种堆栈，都有一些工具可用于监控您的资源。如果您在任何领先的IaaS（基础设施即服务）供应商（如AWS、MicrosoftAzure和GCP）上运行，都有出色的应用程序性能管理工具可供选择。这些工具通过图形和其他数据可视化来说明资源性能。使用这些图表查找峰值或平顶。这些通常意味着资源不堪重负或已满，无法处理新操作。如果您显然没有任何容量，但您的应用程序很慢，请尝试将日志分散到常用操作中。检查日志以查找需要很长时间才能通过网络加载的资源，可能是其他服务器（例如第三方API）或您的数据库服务器引入了延迟。您应该将数据库托管在另一台服务器上，如果是这种情况，那么您还应该检查该机器的资源监控。通过考虑用户如何使用您的应用程序，并从逻辑上考虑开始显示的错误或裂缝，确定瓶颈在哪里很简单。就Twitter而言，这个特定平台主要用于阅读和撰写推文。如果Twitter的监控服务表明与这些操作相关的数据库负担过重，那么他们的团队开始优化平台的这个区域是有意义的。在本文中，我们将深入研究数据库扩展解决方案，这通常是第一个失败点。如果您不熟悉系统设计，请阅读这篇介绍该主题的短文。我建议在实施扩展解决方案之前了解系统设计。>APM工具从鸟瞰图扩展应用程序现在我们已经很清楚问题/瓶颈是什么/我们可以从哪里开始实施解决方案来修复它们。请记住，简单是关键，我们希望始终避免引入不必要的复杂性。扩展解决方案的高级目标是使堆栈能够减少应用程序最常请求的工作，或者在多个资源之间有效地分配不可减少的工作负载。扩展技术执行此操作的方式通常转化为以下一项或多项：重用应用程序已查找的数据消除客户端对应用程序已有数据的请求存储常见操作的结果以减少对请求的重复计数-避免复杂的操作响应周期许多缩放技术归结为某种形式的缓存。过去，内存价格昂贵且稀缺。现在将它添加到服务器很便宜。内存访问数据的速度比磁盘或网络快很多个数量级。在一个用户有太多选择而我们却很少受到关注的时代，速度和性能对于您的应用程序的生存至关重要。数据库扩展解决方案1.缓存数据库查询缓存数据库查询是您可以为处理数据库负载所做的最简单的改进之一。通常，应用程序将包含少量查询，这些查询构成了大部分请求。无需每次都通过网络来回传输此数据，只需将其缓存在Web服务器的内存中即可。第一个请求将从数据库中获取数据并将结果缓存在服务器上，后续请求将从缓存中读取。这提高了性能，因为数据在网络上花费的时间更少并且更接近客户端。由于分配给缓存系统的繁重工作负载，它还会导致更多数据库服务器资源可用。除了提高可用性之外，如果数据库变得不可用，缓存仍然可以为应用程序提供持续的服务，使系统对故障更具弹性。有许多工具可用于分析数据库查询日志，因此您可以查看哪些查询花费的时间最长以及哪些查询运行最频繁。显然，缓存数据会很快变得“陈旧”或过时。您将必须选择要缓存的数据以及保留多长时间。例如，在线报纸每24小时都会有一个新的日报，而不是每次用户访问该站点时都从数据库中请求数据，数据可以缓存在Web服务器上24小时并直接从服务器提供数据。.产品或业务需求将决定什么可以缓存，什么不能缓存。2.数据库索引数据库索引是一种提高数据库表数据检索操作速度的技术。索引用于快速定位数据，而不必在每次访问表时都搜索表中的每一行。通常，数据库索引的数据结构是二叉搜索树。这允许将访问数据的时间复杂度从线性时间O(n)降低到对数时间Olog(n)。根据表中的行数，这可以为大量使用索引列的查询节省时间。例如，如果您有10,000个用户，并且您的应用程序的配置文件页面按用户名查找用户，则未索引的查询将检查用户表中的每一行，直到它找到与传递给查询配置文件的用户名匹配的项。这可能需要多达10,000次行检查O(n)。通过在“用户名”列上创建索引，数据库可以以对数时间复杂度(Olog(n))获取该行。在这种情况下，检查的最大行数将是14，而不是10,000！高效的索引通过提高效率来减少数据库的负载，这也可以显着提高性能，从而带来更好的用户体验。创建索引确实会添加另一组数据存储在数据库中，因此在决定对哪些字段建立索引时必须使用良好的判断力。即使使用现有存储，索引也是非常值得的，特别是在内存便宜且性能是生存不可或缺的现代开发中。本节简要提及时间复杂度和数据结构，但并未详尽解释。如果您有兴趣学习或希望了解时间复杂度和数据结构，那么上面链接的文章非常棒！3.SessionStorage许多应用程序通过将sessionID存储在cookie中，然后存储每个session的key/value对的实际数据存储在数据库表中来处理session。这可能会导致对数据库的大量读取和写入。如果会话数据使您的数据库不堪重负，最好重新考虑存储数据的方式和位置。将会话数据移动到内存缓存工具（如redis或memcached）可能是一个不错的选择。由于内存比大多数数据库使用的永久磁盘存储更快，这将从数据库卸载会话数据并提高访问速度。但是，由于内存是易失性的，如果缓存系统离线，则存在丢失所有会话数据的风险。您还可以考虑更改会话实现以将会话信息存储在cookie本身中，这会将您维护会话状态的方法从服务器转移到客户端。JWT是这种模式最流行的实现。这会从数据库中卸载所有会话数据并消除对服务器端会话的依赖，尽管这会带来一系列挑战。4.Slave-Master复制如果数据库在缓存常见查询、创建高效索引和处理会话存储后仍因读取而承受过大负载，那么复制可能是下一个最佳选择。使用主从复制，你只有一个数据库可以写入。它被克隆到您读取的多个（根据需要）从属设备中，每个从属设备位于不同的机器上（见下图）。这从主数据库卸载读取负载并将其分布在多个服务器上。该模型还提高了写入操作的性能，因为master专用于写入操作，而读取速度可以显着提高并减少延迟，因为slaves分布在不同的区域。由于每个从机都在另一台机器上，对主机的写入需要传播到从机，这会导致数据不一致。如果您需要立即读取写入数据库的数据，例如您正在更新配置文件并希望立即渲染它，您可以选择从主数据库读取。从主复制是一种非常强大的扩展解决方案，但它具有相当大的复杂性。在用尽更简单的解决方案并确保在应用程序内进行有效优化后，实施此解决方案是明智的。5.数据库分片到目前为止，这些扩展解决方案中的大多数都侧重于通过管理对数据库的读取来减少负载。数据库分片是一种水平扩展解决方案，它通过管理对数据库的读取和写入来管理负载。这是一种架构模式，涉及将主数据库拆分（分区）为多个数据库（分片）的过程，这样可以更快、更易于管理。数据库分片技术有两种类型：垂直分片和水平分片（见下图）。使用水平分区时，将表取出并放在不同的机器上，每个机器具有相同的列但不同的行。垂直分区更复杂，涉及将表拆分到多台机器上。一个表被拆分并放入一个新的不同表中。一个垂直分区中的数据独立于所有其他分区中的数据，并且每个表都包含不同的行和列。>Horizo??ntalSharding>VerticalSharding两种分片技术都有助于水平扩展，也称为“向外扩展”，它允许您在系统中添加更多机器以分配/分散负载。水平扩展通常与垂直扩展（也称为“向上扩展”）形成对比，后者涉及升级现有服务器的硬件。扩展数据库相对简单，尽管任何非分布式数据库在计算能力和存储方面都有其局限性，因此可以自由扩展使您的系统更加灵活。分片数据库架构还可以显着提高应用程序查询的速度并提供增强的故障恢复能力。在非分片数据库上提交查询时，可能必须搜索表中的每一行，这可能非常慢。或者，通过将一个表拆分为多个表，查询必须遍历更少的记录才能返回结果。因为每个表都在单独的服务器上，所以减轻了服务器不可用的影响。对于分片数据库，与非分片数据库相比，中断的影响可能只会影响单个分片，在非分片数据库中，中断可能会导致整个应用程序不可用。具有分片的数据库体系结构提供了一些很大的好处，但是，它的实施和维护起来既复杂又昂贵。在用尽其他扩展解决方案后一定要考虑此选项，因为无效实施的后果可能很严重。结论恭喜，您的应用程序现在有了一个解决方案，可以成功处理数据库负载并随着应用程序的成功而扩展！虽然没有足够的时间来庆祝……有效扩展的服务器是一个高性能和可靠的应用程序的组成部分。
