MySQL深入浅出负载均衡

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

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

负载均衡有五个常见目的：

1. 可扩展性。负载均衡对某些扩展很有帮助，比如读写分离时从备库读数据。
2. 高效性。负载均衡因为能够控制请求被路由到何处，因此有助于更有效的使用资源。
3. 可用性。灵活的负载均衡方案能够大幅提高服务的可用性。
4. 透明性。客户端无需知道是否存在负载均衡器，也不需要关系在负载均衡器的背后有多少机器。呈现给客户端看到的就是一个透明的服务器。
5. 一致性。如果应用是有状态的（数据库事务、网站会话等），那么负载均衡器就可以将相关的查询指向同一个服务器，以防止状态丢失。

而对于负载均衡的实现，一般有两种方式：直接连接和引入中间件。

相关教程：mysql视频教程

1 直接连接

有些人认为负载均衡就是配置在应用和 MySQL 服务器直接东西，但实际上这并不是唯一的负载均衡方法。接下来我们就讨论一下常见的应用直连的方法，及其相关注意事项。

1.1 复制的读写分离

此种方式下，容易出现一个最大的问题：脏数据。一个典型的例子是，当用户评论了一篇博文，然后重新加载页面，却没有看到新增的评论。

当然，我们也不能因为脏数据的问题，就将读写分离弃之不用。实际上，对于很多应用，可能对脏数据的容忍度比较高，此时就可以大胆的引入此种方式。

那么对于脏数据的容忍度比较低的应用，如何进行读写分离呢？接下来，我们对读写分离再进一步区分，相信你总能找到适合自己的一款策略。

1) 基于查询分离

如果应用只有少数数据不能容忍脏数据，我们可以将所有不能容忍脏数据的读和写都分配到 master 上。其它的读查询分配的 slave 上。该策略很容易实现，但如果容忍脏数据的查询比较少，很可能会出现不能有效使用备库的情况。

2) 基于脏数据分离

这是对基于查询分离策略的小改进。需要做一些额外的工作，比如让应用检查复制延迟，以确定备库数据是否最新。许多报表类应用都可以使用这个策略：只需要晚上加载的数据复制到备库接口，并不关心是不是完全跟上了主库。

3) 基于会话分离

这个策略比脏数据分离策略更深入 一些。它是判断用户是否修改了数据，用户不需要看到其他用户的最新数据，只需要看到自己的更新。

具体可以在会话层设置一个标记位，表明用户是否做了更新，用户一旦做了更新，就将该用户的查询在一段时间内指向主库。

这种策略在简单和有效性之间做了很好的妥协，是一种较为推荐的策略。

当然，如果你的想法够多，可以把基于会话的分离策略和复制延迟监控策略结合起来。如果用户在 10 秒前更新了数据，而所有备库延迟在 5 秒内，就可以大胆的从备库中读取数据。要注意的是，记得为整个会话选择同个备库，否则一旦多个备库的延迟不一致，就会给用户造成困扰。

4) 基于全局版本 / 会话分离

通过记录主库日志坐标和备库已复制的坐标对比，确认备库是否更新数据。当应用指向写操作时，在提交事务后，执行一次 SHOW MASTER STATUS 操作，然后将主库日志坐标存储在缓存中，作为被修改对象或者会话的版本号。当应用连接到备库时，执行 SHOW SLAVE STATUS，并将备库上的坐标和缓存中的版本号对比。如果备库比主库记录点更新，就表明备库已更新对应数据，可放心的使用。

实际上，很多读写分离策略都需要监控复制延迟来决定读查询的分配。不过要注意的是，SHOW SLAVE STATUS 得到的 Seconds_behind_master 列的值并不能精确的表示延迟。我们可以使用 Percona Toolkit 中的 pt-heartbeat 工具更好的监控延迟。

LobeHub

LobeChat brings you the best user experience of ChatGPT, OLLaMA, Gemini, Claude

下载

1.2 修改 DNS 名

对于一些比较简单的应用，可以为不同目的创建 DNS。最简单的方法是只读服务器拥有一个 DNS 名(read.mysql-db.com),给负责写操作的服务器起另外一个 DNS 名(write.mysql-db.com)。如果备库能够跟得上主库，就把只读 DNS 名指向到备库，否则，就指向到主库。

这种策略非常容易实现，但有个很大的问题是：无法完全控制 DNS。

• 修改 DNS 并不是立刻生效的，也不是原子性的。将 DNS 的变化传递到整个网络或者网络间传播都需要比较长的时间。
• DNS 数据会在各个地方缓存下，它的过期时间是建议性质，而非强制的。
• 可能需要应用或服务器重启才能使修改后的 DNS 完全生效。

这种策略较为危险，即使可以通过修改 /etc/hosts 文件来避免 DNS 无法完全控制的问题，但仍不失理想策略。

1.3 转移 IP 地址

通过在服务器间转移虚拟地址，来实现负载均衡。是不是感觉和修改 DNS 很像？但实际上完全是两码事。转移 IP 地址允许 DNS 名保持不变，我们可以通过 ARP 命令(不了解 ARP，看这里)强制使 IP 地址的更改快速而且原子性的通知到局域网络上。

一个比较方便的技术是为每个物理服务器分配一个固定的 IP 地址。该 IP 地址固定在服务器上，不再改变。然后可以为每个逻辑上的 “服务”(可以理解为容器)使用一个虚拟 IP 地址。

这样，IP 就能够很方便的在服务器间转移，无需重新配置应用，实现也更加容易。

2 引入中间件

上面的策略都是假定应用是和 MySQL 服务器之间连接的，但是许多负载均衡都会引入一个中间件，作为网络通信的代理。它一边接受所有的通信，另一边将这些请求分发的指定服务器上，并将执行结果发送回请求机器。图 2 展示了此种架构。

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 有哪些变化，也许这些新变化会给你带来惊喜。

总结

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

• 为扩展性量化指标。

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