MySQL深入浅出负载平衡
如图 1，显示了一个大型网站负载平衡设定。其中一个负责 HTTP 流量，另一个用于 MySQL 拜访。
2.1 负载平衡器
此刻有很多负载平衡硬件和软件，但很少有专门为 MySQL 办事器设计的。Web 办事器平常更需要负载平衡，因而很多多用法的负载平衡设施都会支撑 HTTP，而对其他用法则只要一些很少的根本特性。
MySQL 连贯只是正常的 TCP/IP 连贯，所以可以在 MySQL 上运用多用法负载平衡器。但因为短少 MySQL 专有的特性，因而会多一些限定：
- 分发要求是可能没法做到非常不错的负载平衡。
- 对 MySQL 会话支撑不够，可能不晓得怎样把所有从单个 HTTP 会话发送的连贯要求 “牢固” 到一个 MySQL 办事器上。
- 连贯池和长连贯可能会阻碍负载平衡器分发连贯要求。
- 不克不及非常不错的对 MySQL 办事器做安康和负载检查。
2.2 负载平衡算法
有许多算法用来决议哪个办事器承受下一个连贯。每个厂商都有各自不一样的算法，有下列常用办法：
- 随机分配。从可用的办事器池中随机选中一个办事器来处置要求。
- 轮询。以轮回次序发送要求到办事器，例如：A、B、C、A、B、C。
- 哈希。通过连贯的源 IP 地址进行哈希，将其映照到池中的统一个办事器上。
- 最快相应。将连贯分配给能够最快处置要求的办事器上。
- 最少连贯数。将连贯分配给具有最少活泼连贯的办事器上。
- 权重。依据机器的机能等前提，给不一样机器配置不一样的权重，以便让高机能的机器能处置更多的连贯。
上述各种办法没有最佳，只要最适合的，这取决于概括的工作负载。
别的，我们只描述了即时处置的算法。但有时候运用排队算法可能会更有效。例如，一个算法可能只保护给定的数据库办事器并发数目，统一时刻只允许不超过 N 个活泼事务。要是有太多的活泼事务，就将新的要求放到一个队列里，然后让可用办事器列表来处置。
2.3 一主多备间的负载平衡
最常见的复制构造就是一个主库加多个备库。这种架构的扩展性较差，但我们可以通过一些办法联合负载平衡来获得更好的结果。
- 功能分区。关于厂家的功能包含报表、剖析、数据仓库以及全文索引，配置一个或一组备库来扩展单个功能的容量。
- 保障备库跟上主库。备库存在的题目就是脏数据。关于此，我们可以运用函数 MASTER_POS_WAIT() 阻塞主库的操纵，直到备库遇上了设定的主库同步点。别的，我们还可以运用复制心跳来检查推迟状况。
我们不克不及也不该该在利用的开端就就想着把架构做成阿里那样的架构。最佳的方式是实现利用目前所明白需要的，并为可能的迅速增长做好预先计划。
别的，为可扩展性拟定一个数字指标是很成心义的，就像我们为机能拟定了一个精准指标，知足 10K 或 100K 并发同样。这样可以通过相干理论以免诸如序列化或交互操纵的开销题目带入到我们的利用中。
在 MySQL 扩展战略方面，典型的的利用在增长到非常巨大时，平常先从单个办事器转移到向外扩展的具有备库的架构，再到数据分片或按功能分区。这里要注意的是，我们不倡导诸如 “尽早分片，尽量分片” 的倡议。现实上，分片很复杂，并且老本很高，最主要的是许多利用可能基本不需要。与其花大老本去分片，还不如先去看看新的硬件和新版本的 MySQL 是什么变化，或许这些新变化会给你带来欣喜。
总结
- 直接连贯重 "别离"，平衡器和算法有局限。
为扩展性量化目标。
最后，但愿本文对你有所帮忙。
以上就是MySQL深入浅出负载平衡的细致内容，更多请关注 百分百源码网 其它相干文章！
