我们应该接触过或听说过数据库的性能瓶颈。对于单机应用来说，提高数据库性能最快的方法就是氪金——买更高性能的数据库服务器，只要钱到位，性能不是问题。但是当系统性能提升到一定程度后，你会发现原来3000元的成本，性能提升了50%，现在只需要3万元，性能提升不到10%。也就是说，我们花了钱却没有得到同等的性能提升。这时候，我们就不得不考虑数据库的可扩展性了。要讨论MySQL的可扩展性，有必要明确一下可扩展性的定义。在此之前，让我们先抛开MySQL，关注可扩展性。只有了解什么是可扩展性，才能更有针对性地提高数据库的可扩展性。1什么是可伸缩性我们经常将“可伸缩性”、“高可用性”和“性能”作为同义词使用，但实际上它们是有很大区别的。简单来说，性能就是响应时间，可用性就是宕机时间，而可扩展性显示了当需要添加资源以执行更多工作时，系统能够实现同等性能提升的能力。换句话说，可扩展性意味着我们可以花费尽可能多的相同资源来提高同等性能。一个缺乏扩展能力的系统在达到收益递减的临界点后将无法进一步增长。容量是一个与可伸缩性相关的概念。系统容量表示在一定时间内可以完成的工作量。容量和可扩展性不依赖于性能。用高速公路上的汽车来类比：性能就是汽车的速度。通行能力是车道乘以每小时最大安全速度。可扩展性是指在不减慢交通流量的情况下可以添加更多汽车和车道的程度。在上面的类比中，可扩展性取决于多个条件：变道是否设计良好，路上有多少汽车抛锚或发生事故，汽车以不同的速度行驶，变道是否频繁。但总的来说，这与汽车发动机的功率大小无关。这并不是说性能不重要，而是说性能不是很好的系统可以扩展。在高层次上，可扩展性是通过添加资源来增加容量的能力。对于容量，我们可以简单的认为是处理负载的能力，从不同的角度考虑负载对于我们优化扩展性是很有帮助的。应用程序可以积累的数据量是最常见的可伸缩性挑战，尤其是对于当今的Internet应用程序，因为数据永远不会被删除。用户数量首先，即使每个用户只有少量数据，但在用户数量积累到一定程度后，数据量就会开始不成比例地增长，而且速度比用户数量的增长还要快。第二，更多的用户意味着更多的交易要处理，交易的数量可能与用户的数量不成正比。最后，大量的用户也意味着更复杂的查询。用户活动并非所有用户活动都是相同的，用户活动也不总是恒定的。如果用户突然活跃起来，比如github免费开放私有仓库给小团队，相应的负载可能会大幅增加。需要注意的是，用户活跃度不仅仅指页面浏览量（PV）。即使是相同的PV，如果网站的一个查询工作量大的功能变得更受欢迎，可能会带来更多的工作量。相关数据集的大小如果用户之间存在关系，应用程序可能需要对整组相关用户进行查询和计算，这比处理单个用户和用户数据要复杂得多。说了这么多，只是为了让我们更好的理解scalability，让我们用下图更清楚的表达scalability。假设有一个只有一台服务器的系统，可以测出它的最大容量，如图1：假设我们现在增加一台服务器，系统容量翻倍，如图2：图2是线性扩展.我们将服务器数量增加了一倍，容量也增加了一倍。然而，理想是美好的，现实却是骨感的。大多数系统不是线性缩放，而是按图3所示进行缩放：大多数系统仅按比线性缩放稍低的缩放因子缩放。结果，大多数系统最终都会达到最大吞吐量的临界点，超出该点增加投资实际上可能会降低系统的吞吐量。至此，大家对可伸缩性应该有了比较清晰的概念。在此基础上，让我们更进一步：Amdahl扩展和USL扩展。简而言之，USL所说的是离线扩展中的偏差可以通过两个因素建模：一部分工作不能同时执行，另一部分工作需要交互。继续对第一个因素进行建模之后，就有了著名的（听说过这个著名的？）阿姆达尔定律（Amdahl）。第一个因素最终导致吞吐量趋于平稳。如果有些任务不能并行化，不管你分而治之，任务至少需要串行部分的时间。这句话很重要，我们用一个栗子来简单解释一下：假设每个人都做过韭菜炒鸡蛋，我们在做这道菜的时候，有几个必要的步骤：切韭菜需要时间t1；打蛋液需要t2时间煎出；炸它需要t3时间；以上3个步骤，切韭菜的时候可以让女朋友给你打蛋液，也就是说1和2可以并行。但是我们可以同时切碎和煎炸吗？还是一边打蛋一边煎？显示不工作。因此，步骤3和1、2是连续的。这时我们会发现，做韭菜煎蛋这个任务需要的时间t为：t=MAX(t1,t2)+t3；对于第二个因素，需要交互的工作，交互意味着内部节点间或进程间通信。这种通信的成本取决于通信通道的数量，而通道的数量会按照系统中worker数量的二次方增长，所以最终的开销会比收益增长得更快，这就是原因对于可伸缩性回归。从这个和阿姆达尔定律，推导出USL。图4说明了到目前为止讨论的三个概念：线性缩放、Amdahl缩放和USL缩放。大多数真实系统看起来更像USL曲线。至此，关于可伸缩性的概念描述就告一段落了。接下来我们言归正传，看看MySQL的扩展性是如何规划的。2规划可扩展性什么时候需要扩展？，这是一个值得牢记的问题。当我们提到系统的可扩展性时，一般只有两种情况：我们刚刚开始规划一个应用程序；当前应用无法满足增加的负载；在以上两种情况中，我们遇到的大多应该是后者。具体表现为：CPU密集型变成I/O密集型；并发查询竞争；增加延迟；如果它是一个可扩展的应用程序，您可以简单地添加更多服务器来分担负载。但是如果扩展性比较差，你会发现——只有提高扩展性才是唯一的出路。只有一种方法，所以让我们去996吧！踏上提高可扩展性的道路，接下来的问题是，如何提高可扩展性？这里最难的部分是估计应用程序承载了多少负载？该值不必非常精确，但必须在某个数量级内。什么？你问为什么在一定范围内？不知道敌人的火力。是用高射炮打蚊子，还是用大刀打机枪？此外，为了帮助我们更好地规划可扩展性，我们最好思考以下问题：应用程序的核心功能完成了多少？许多可伸缩性方案会使某些功能的实现变得更加复杂。在核心功能完成之前，问问自己，你真的要走提高扩展性的道路吗？换句话说，你准备好迎接996了吗？3为拓展争取时间程序员理想的开发环境应该是：先规划，有足够的可以一起战斗的同伴，有花不完的预算，等等。但现实是：老板：喂，小九，我们的系统要多久才能提升性能？三天应该差不多，最多不超过一周。上次提高性能，小刘一天就搞定了。小九：。..通常情况下，提高系统的可扩展性可能比重构更难。所以，当你对系统还不完全熟悉，或者对可扩展性还很模糊的时候，不要跟老板说你要提高系统的可扩展性。当老板提出绩效提升的要求时，你要千方百计满足他对绩效提升的要求。同时，还要多思考如何提高系统的可扩展性，为以后的可扩展性改进争取时间。首先可以通过以下工作提高系统性能：优化性能。很多时候，一个简单的改变就能带来显着的性能提升。示例包括为表构建适当的索引，或从MyISAM切换到InnoDB。更进一步，可以通过慢日志来分析。购买更强大的硬件。在应用初期，升级或增加服务器可以显着提升系统性能，而且可以很快完成。就像如果我们把服务器从1台增加到3台，性能可能会提升100%，但是当我们的服务器已经达到100台，再从100台增加到300台时，复杂度和成本可能已经让你愿意踏上提高系统可扩展性的途径。总结可伸缩性是当需要添加资源以执行更多工作时，系统实现同等性能提升的能力。在不准确评估应用程序负载的情况下进行扩展是一种流氓行为。
