如图 1，显现了一个大型网站负载平衡设置。个中一个担任 HTTP 流量，另一个用于 MySQL 接见。
负载平衡有五个罕见目的：
- 可扩大性。负载平衡对某些扩大很有协助，比方读写星散时从备库读数据。
- 高效性。负载平衡由于能够掌握要求被路由到那边，因而有助于更有用的运用资本。
- 可用性。天真的负载平衡计划能够大幅进步效劳的可用性。
- 通明性。客户端无需晓得是不是存在负载平衡器，也不须要关联在负载平衡器的背地有若干机械。显现给客户端看到的就是一个通明的效劳器。
- 一致性。假如运用是有状况的（数据库事件、网站会话等），那末负载平衡器就能够将相干的查询指向统一个效劳器，以防备状况丧失。
而关于负载平衡的完成，平常有两种体式格局：直接衔接和引入中间件。
相干教程：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 东西更好的监控耽误。
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 负载平衡算法
有很多算法用来决议哪一个效劳器接收下一个衔接。每一个厂商都有各自差别的算法，有以下经常使用要领：
- 随机分派。从可用的效劳器池中随机挑选一个效劳器来处置惩罚要求。
- 轮询。以轮回递次发送要求到效劳器，比方：A、B、C、A、B、C。
- 哈希。经由过程衔接的源 IP 地点举行哈希，将其映射到池中的统一个效劳器上。
- 最快相应。将衔接分派给能够最快处置惩罚要求的效劳器上。
- 起码衔接数。将衔接分派给具有起码活泼衔接的效劳器上。
- 权重。依据机械的机能等前提，给差别机械设置差别的权重，以便让高机能的机械能处置惩罚更多的衔接。
上述种种要领没有最好，只要最合适的，这取决于细致的事情负载。
别的，我们只形貌了立即处置惩罚的算法。但有时候运用列队算法能够会更有用。比方，一个算法能够只保护给定的数据库效劳器并发数目，统一时候只许可不凌驾 N 个活泼事件。假如有太多的活泼事件，就将新的要求放到一个行列里，然后让可用效劳器列表来处置惩罚。
2.3 一主多备间的负载平衡
最罕见的复制构造就是一个主库加多个备库。这类架构的扩大性较差，但我们能够经由过程一些要领连系负载平衡来取得更好的结果。
- 功用分区。关于厂家的功用包含报表、剖析、数据仓库以及全文索引，设置一个或一组备库来扩大单个功用的容量。
- 保证备库跟上主库。备库存在的题目就是脏数据。关于此，我们能够运用函数 MASTER_POS_WAIT() 壅塞主库的操纵，直到备库赶上了设置的主库同步点。别的，我们还能够运用复制心跳来搜检耽误状况。
我们不能也不该该在运用的最先就就想着把架构做成阿里那样的架构。最好的体式格局是完成运用当前所明白须要的，并为能够的疾速增长做好预先计划。
别的，为可扩大性制订一个数字目的是很有意义的，就像我们为机能制订了一个准确目的，满足 10K 或 100K 并发一样。如许能够经由过程相干理论防止诸如序列化或交互操纵的开支题目带入到我们的运用中。
在 MySQL 扩大战略方面，典范的的运用在增长到异常巨大时，平常先从单个效劳器转移到向外扩大的具有备库的架构，再到数据分片或按功用分区。这里要注意的是，我们不首倡诸如 “尽早分片，只管分片” 的发起。实际上，分片很庞杂，而且本钱很高，最主要的是很多运用能够基础不须要。与其花大本钱去分片，还不如先去看看新的硬件和新版本的 MySQL 有哪些变化，或许这些新变化会给你带来欣喜。
总结
- 直接衔接重 "星散"，平衡器和算法有范围。
为扩大性量化目标。
末了，愿望本文对你有所协助。
以上就是MySQL深切浅出负载平衡的细致内容，更多请关注ki4网别的相干文章！
