MySQL深入浅出负载均衡

如图 1，显示了一个大型网站负载均衡设置。其中一个负责 HTTP 流量，另一个用于 MySQL 访问。

2.1 负载均衡器

现在有许多负载均衡硬件和软件，但很少有专门为 MySQL 服务器设计的。Web 服务器通常更需要负载均衡，因此许多多用途的负载均衡设备都会支持 HTTP，而对其他用途则只有一些很少的基本特性。

MySQL 连接只是正常的 TCP/IP 连接，所以可以在 MySQL 上使用多用途负载均衡器。但由于缺少 MySQL 专有的特性，因此会多一些限制：

• 分发请求是可能无法做到很好的负载均衡。
• 对 MySQL 会话支持不足，可能不知道如何把所有从单个 HTTP 会话发送的连接请求 “固定” 到一个 MySQL 服务器上。
• 连接池和长连接可能会阻碍负载均衡器分发连接请求。
• 不能很好的对 MySQL 服务器做健康和负载检查。

2.2 负载均衡算法

有很多算法用来决定哪个服务器接受下一个连接。每个厂商都有各自不同的算法，有以下常用方法：

1. 随机分配。从可用的服务器池中随机选择一个服务器来处理请求。
2. 轮询。以循环顺序发送请求到服务器，例如：A、B、C、A、B、C。
3. 哈希。通过连接的源 IP 地址进行哈希，将其映射到池中的同一个服务器上。
4. 最快响应。将连接分配给能够最快处理请求的服务器上。
5. 最少连接数。将连接分配给拥有最少活跃连接的服务器上。
6. 权重。根据机器的性能等条件，给不同机器配置不同的权重，以便让高性能的机器能处理更多的连接。

上述各种方法没有最好，只有最适合的，这取决于具体的工作负载。

另外，我们只描述了即时处理的算法。但有时候使用排队算法可能会更有效。例如，一个算法可能只维护给定的数据库服务器并发数量，同一时刻只允许不超过 N 个活跃事务。如果有太多的活跃事务，就将新的请求放到一个队列里，然后让可用服务器列表来处理。

2.3 一主多备间的负载均衡

最常见的复制结构就是一个主库加多个备库。这种架构的扩展性较差，但我们可以通过一些方法结合负载均衡来获得更好的效果。

• 功能分区。对于厂家的功能包括报表、分析、数据仓库以及全文索引，配置一个或一组备库来扩展单个功能的容量。
• 保证备库跟上主库。备库存在的问题就是脏数据。对于此，我们可以使用函数 MASTER_POS_WAIT() 阻塞主库的操作，直到备库赶上了设置的主库同步点。另外，我们还可以使用复制心跳来检查延迟情况。

我们不能也不应该在应用的开始就就想着把架构做成阿里那样的架构。最好的方式是实现应用当前所明确需要的，并为可能的快速增长做好预先规划。

另外，为可扩展性制定一个数字目标是很有意义的，就像我们为性能制定了一个精确目标，满足 10K 或 100K 并发一样。这样可以通过相关理论避免诸如序列化或交互操作的开销问题带入到我们的应用中。

在 MySQL 扩展策略方面，典型的的应用在增长到非常庞大时，通常先从单个服务器转移到向外扩展的拥有备库的架构，再到数据分片或按功能分区。这里要注意的是，我们不提倡诸如 “尽早分片，尽量分片” 的建议。实际上，分片很复杂，而且成本很高，最主要的是很多应用可能根本不需要。与其花大成本去分片，还不如先去看看新的硬件和新版本的 MySQL 有哪些变化，也许这些新变化会给你带来惊喜。

总结

• 直接连接重 "分离"，均衡器和算法有局限。

• 为扩展性量化指标。

最后，希望本文对你有所帮助。

以上就是MySQL深入浅出负载均衡的详细内容，更多请关注 第一PHP社区 其它相关文章！