MySQL - 扩展性 2 扩展策略：氪金氪脑任君选

若是将应用的全部数据简单地放在一台 MySQL 服务器实例上，就不用谈什么扩展性了。可是业务能稳定持续的增加，那么应用确定会碰到性能瓶颈。

对于不少类型的应用而言，购买更高性能的机器能解决一大部分性能问题，这也是咱们常说的 “垂直扩展” 或者 “向上扩展”。

另外一个与之相反的方法是将任务分配的多台机器上，这一般被称为 “水平扩展” 或者 “向外扩展”。

接下来，咱们将讨论如何联合使用向上扩展和向外扩展，以及如何使用集群方案来进行扩展。

最后，大部分应用还会有一些不多或者从不须要的数据，这些数据能够被清理或归档，咱们能够称这种方案为 “向内扩展”。

1 向上扩展

向上扩展（也叫垂直扩展）意味着购买更多性能强悍的机器。这种策略有较多优势：

• 更容易维护和开发，显著节约开销；
• 单台服务器备份和恢复较为简单，无需关心一致性；

所以，从复杂性的成原本说，大多时候，向上扩展比向外扩展更简单。

另外，不要以为向上扩展很快就走到“尽头”，要相信科技的进步速度。如今，拥有 0.5TB 内存、32 核（或者更多）CPU 以及更强悍 I/O 性能的商用服务器很容易得到。优秀的应用和数据库设计，再加上很好的性能优化技能，已经能够知足绝大多数商业应用。

不过遗憾的，虽然高性能服务器比较容易得到，可是 MySQL 并不能扩展到对应的规模。为了更好地在大型服务器上运行 MySQL，必定要尽可能选择最新的版本。即便如此，当前合理的 “收益递减点” 的机器配置大约是：

• 256G RAM
• 32 核 CPU
• PCIe flash 驱动器

若是继续提高硬件配置，MySQL 性能虽然还能有所提高，但性价比就会下降。

所以，咱们建议，若是系统确实有可能碰到可规划性的天花板，而且会致使严重的业务问题，那就不要无限制的作向上扩展的规划。对于庞大的应用，能够短时间内购买更优的服务器，但最终仍是须要向外扩展的。

2 向外扩展

向外扩展（也叫横向扩展或水平扩展）策略一般分为三个部分：复制、拆分和数据分片。

最多见的向外扩展就是读写分离。经过复制将数据分发到多个服务器上，而后将备库用于读查询。这种技术对于以读为主的应用颇有效。

另外一个比较常见的向外扩展方法是将工做负载分布到多个 “节点”。接下来咱们要了解的主要是这种扩展方法。

在此以前，咱们先明确下节点的概念。在 MySQL 架构中，一个节点就是一个功能部件。通常的，咱们会将一台服务器做为一个几点。但若是咱们考虑到节点的高可用性，那么一个节点一般多是下面的几种：

• 一个主 - 主 复制双机结构，拥有一个主动服务器和被动服务器。
• 一个主库和多个备库。
• 一个主动服务器，并使用分布式复制块设备（DRBD）做为备用服务器。
• 一个基于存储区域网络（SAN）的 “集群”。

2.1 按功能拆分

按功能拆分，或者说按职责拆分，意味着不一样的节点执行不一样的任务。

例如，若是有一个网站，各个部分无需共享数据，那么能够按照网站的功能区域进行划分。像咱们常见的门户网站，通常都是把不一样栏目放在一块儿，但实际上能够将网站新闻、论坛、寻求支持等功能放到专用的 MySQL 服务器。如图 2-1

2.2 数据分片

在目前用于扩展大型 MySQL 应用的方案中，数据分片是最通用且最成功的方法。它把数据分割成一小片，或者说一块，而后存储到不一样的节点中。

在使用分片前，要牢记一个通用原则：如非必要，尽可能不分片。

除此以前，对于分片，咱们只会对须要的数据作分片。这里 “须要的数据” 一般是那些增加很是庞大的数据。而像对于用户信息这些全局数据，通常是存储在单个节点上，一般保存在相似 redis 这样的缓存中。

对于分片，咱们一般要考虑下列问题：

1. 选择合适的分区键（partition key）。
2. 是否须要多个分区键？
3. 跨分片查询如何处理？
4. 如何分片数据、分片和节点？
5. 如何在节点上部署分片？
6. 如何生成全局惟一 ID？

2.3 经过多实例扩展

上面提到过，MySQL 不能彻底发挥现代硬件的性能。当扩展到超过 24 个 CPU 核心时，MySQL 的性能开始趋于平缓，再也不上升。当内存超过 128G 时也一样如此。对于此种状况，咱们能够经过多实例策略充分发挥硬件的性能。

多实例策略的基本思路是：

1. 数据分片足够小，可使得在每台机器上都能放置多个分片；
2. 每台服务器运行多个实例；
3. 给每一个实例划分服务器的硬件资源；

能够看出，这是一种向上扩展和向外扩展的组合方案。这种方案还能够经过将每一个 MySQL 实例绑定到特定的 CPU 核心上来优化性能。这种优化，主要有两个好处：

1. 因为 MySQL 内部的可扩展性限制，当核心数较少时，可以在每一个核心上得到更好的性能；
2. 当实例在多个核心上运行线程时，因为须要在多核心上同步共享数据，于是会有额外的开销。

而咱们把实例和 CPU 核心绑定后，能够减小 CPU 核心直接的切换和交互。要注意的，将进程绑定到具备相同物理套接字的核心上能够得到最优的效果。

3 向内扩展

对于不断增加的数据和负载，最简单的方法是对再也不须要的数据进行归档和清理。这种操做可能会带来显著的效果。这种作法并不能代替其余策略，但能够做为争取时间的短时间策略，也能够做为处理大数据量的长期计划之一。

在设计归档和清理策略时须要考虑以下几点：

1. 对应用的影响。设计良好的归档系统可以在不影响事务处理的状况下，从一个高负债的 OLTP 服务器上移除数据。
2. 要归档的行。考虑清楚哪些数据能够清理或归档。
3. 维护数据一致性。数据间存在联系时，归档任务系统要可以保证数据的逻辑一致性。
4. 避免数据丢失。归档时要保证归档数据已经成功保存，再讲源数据删除。
5. 解除归档。考虑清楚归档系统中的解除归档策略。能够经过设置一些检查点让系统检查是否有须要归档的数据。

若是不能及时的把老数据归档和清理时，咱们也能够经过如下隔离冷热数据的方式来提升性能：

1. 将表划分为几个部分。分割大表中的冷热数据，保证加载到内存中的数据中，热数据的比例；
2. MySQL 分区。使用MySQL 自带的分区的功能，能够帮助咱们把最近的数据留在内存中；
3. 基于时间的数据分区。若是应用不断有新数据尽可能，通常新数据老是比旧数据更加活跃。所以，咱们能够将新数据完整的保留在内存中，同时使用复制来保证主库失效时有一份能够的备份，而旧数据就而言放到别的地方。

总结

• 向上氪金，向外氪脑。三思然后行。
• 能不分片，就尽可能不分片。