MySQL读书学习笔记（九）——可扩展

9.1 概述

简要地说，可扩展性表明了当需要增加资源以执行更多工作时系统能够获得划算的等同提升的能力。缺乏扩展能力的系统在达到收益递减的转折点后，将无法进一步增长。

9.1.1 定义

数学上，可扩展性是增加资源以处理负载和增加容量时系统能够获得的投资产出率。

9.2 扩展MySQL

如果将应用所有数据简单地放到单个MySQL服务器实例上，则无法很好地扩展，迟早遇到性能瓶颈。对于许多类型的应用，传统的解决方法时购买更多强悍的机器，也就是常说的“垂直扩展”或者“向上扩展”。另一个与之相反的方法是将任务分配到多台计算机上，这通常被称为“水平扩展”或“向外扩展”。大部分应用还会有很少或不需要的数据，这些数据可以被清理或归档，称为“向内扩展”。

9.2.1 规划可扩展性

只有在无法满足增加的负载时才会考虑到可扩展性，具体表现为工作负载从CPU密集型变成I/O密集型，并发查询的竞争，以及不断增大的延迟。主要原因是查询的复杂度增加或内存中驻留着一部分不再使用的数据或者索引。

9.2.2 为扩展赢得时间

准备工作：优化性能，购买性能强的硬件

9.2.3 向上扩展

意味着购买更多性能强悍的硬件，对很多应用来说这是唯一需要做的事。这种策略有很多好处。单台服务器比多台服务器更容易维护和开发，能显著节约开销。在单台服务器上恢复和备份应用同样很简单，因为无须关心一致性或者哪个数据集是权威的。当然还有一些别的原因。从复杂性的成本来说，向上扩展比向外扩展简单。

9.2.4 向外扩展

可以把向外扩展策略划分为3个部分：复制、拆分以及数据分片。

9.2.5 通过多实例扩展

不要在一台性能强悍的服务器上只运行一个服务器实例。可以让数据分片足够小，以使每台机器上都放置多个分片，每台服务器上运行多个实例，然后划分服务器硬件资源，将其分配给每个实例。

9.2.6 通过集群扩展

理想的扩展方案是单一逻辑数据库能够存储尽可能多的数据，处理尽可能多的查询，并如期望那样增长。许多人的第一想法就是建立一个“集群”或者“网络”来无缝处理这些事情，这样就无须去做太多工作，也不需要知道数据到底存在哪台服务器上。随着云计算的流行，自动扩展——根据负载或数据大小变化动态地在集群中增加/移除服务器，变得越来越有趣。

9.2.7 向内扩展

处理不断增长的数据和负载最简单的办法是对不再需要的数据进行归档和处理。这种操作可能会带来显著的成效，具体取决于工作负载和数据特性。这种做法并不用了代替其他策略，但可作为争取时间的短期策略，也可以作为处理大数据量的长期数据之一。

9.3 负载均衡

负载均衡的基本思路很简单：在一个服务器集群中尽可能地平均负载量。通常的做法是在服务器前端设置一个负载均衡器。然后负载均衡器将请求的连接路由到最空闲的可用服务器。

9.3.1 直接连接

有些人认为负载均衡就是配置在应用和MySQL服务器之间的东西。但这不是唯一的负载均衡的办法。你可以在保持应用和MySQL连接的情况下使用负载均衡。事实上，集中化的负载均衡系统只有在存在一个对等置换的服务器池时才能很好工作。

9.3.2 引入中间件

许多负载均衡方案都会使用一个中间件，作为网络通信的代理。它一边接受所有的通信请求，另一边将这些请求派发到指定服务器上，然后把这些执行结果发送回请求的机器上。中间件可以是硬件设备或是软件。

9.3.3 一主多备间的负载均衡

最常见的负载拓扑结构就是一个主库加多个备库。许多应用都假设只有一个目标机器用于所有的写操作，或者所有的数据都可以从单个服务器上获得。尽管这个架构不太具有很好的可扩展性，但可以通过一些办法通过负载均衡来获得很好的效果。