大家好，我是讯享网，很高兴认识大家。



MySQL的cluster方案有很多官方和第三方的选择，选择多就是一种烦恼，因此，我们考虑MySQL数据库满足下三点需求，考察市面上可行的解决方案：

• 高可用性：主服务器故障后可自动切换到后备服务器
• 可伸缩性：可方便通过脚本增加DB服务器
• 负载均衡：支持手动把某公司的数据请求切换到另外的服务器，可配置哪些公司的数据服务访问哪个服务器

 需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点：

综合考虑，决定采用MySQL Fabric和MySQL Cluster方案，以及另外一种较成熟的集群方案Galera Cluster进行预研。

 

简介：

MySQL Cluster 是MySQL 官方集群部署方案，它的历史较久。支持通过自动分片支持读写扩展，通过实时备份冗余数据，是可用性最高的方案，声称可做到99.999%的可用性。

 架构及实现原理：

MySQL cluster主要由三种类型的服务组成：

• NDB Management Server：管理服务器主要用于管理cluster中的其他类型节点（Data Node和SQL Node），通过它可以配置Node信息，启动和停止Node。
•  SQL Node：在MySQL Cluster中，一个SQL Node就是一个使用NDB引擎的mysql server进程，用于供外部应用提供集群数据的访问入口。
• Data Node：用于存储集群数据；系统会尽量将数据放在内存中。

缺点及限制：

• 对需要进行分片的表需要修改引擎Innodb为NDB，不需要分片的可以不修改。
• NDB的事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改；而Innodb支持所有的事务隔离级别，默认使用Repeatable Read，不存在这个问题。
• 外键支持：虽然最新的Cluster版本已经支持外键，但性能有问题（因为外键所关联的记录可能在别的分片节点中），所以建议去掉所有外键。
• Data Node节点数据会被尽量放在内存中，对内存要求大。

简介：

为了实现和方便管理MySQL 分片以及实现高可用部署，Oracle在2014年5月推出了一套为各方寄予厚望的MySQL产品 – MySQL Fabric, 用来管理MySQL 服务，提供扩展性和容易使用的系统，Fabric当前实现了两个特性：高可用和使用数据分片实现可扩展性和负载均衡，这两个特性能单独使用或结合使用。

MySQL Fabric 使用了一系列的python脚本实现。

应用案例：由于该方案在去年才推出，目前在网上暂时没搜索到有大公司的应用案例。

架构及实现原理：

Fabric支持实现高可用性的架构图如下：

• 自增长键不能作为分片的键；
• 事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。

测试高可用性

服务器架构：

安装过程省略，下面讲述如何设置高可用组、添加备份服务器等过程

首先，创建高可用组，例如组名group_id-1，命令：

mysqlfabric group create group_id-1

往组内group_id-1添加机器200.200.168.25和200.200.168.23：

mysqlfabric group add group_id-1 200.200.168.25:3306

mysqlfabric group add group_id-1 200.200.168.23:3306

然后查看组内机器状态：

但备份服务器等待了1-2分钟才同步完成（可以看到fabric使用的是异步复制，这是默认方式，性能较好，主服务器不用等待备份服务器返回，但同步速度较慢）

• 使用半同步加强数据一致性：异步复制能提供较好的性能，但主库只是把binlog日志发送给从库，动作就结束了，不会验证从库是否接收完毕，风险较高。半同步复制会在发送给从库后，等待从库发送确认信息后才返回。
• 可以设置从库中同步日志的更新方式，从而减少从库同步的延迟，加快同步速度。

安装半同步复制：
在mysql中运行
install plugin rpl_semi_sync_master soname ‘semisync_master.so’;
install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;
SET GLOBAL rpl_semi_sync_master_enabled=ON;
SET GLOBAL rpl_semi_sync_slave_enabled=ON;
修改my.cnf ：
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
sync_relay_log=1
sync_relay_log_info=1
sync_master_info=1

稳定性测试：
测试案例：使用java代码建连接，往某张表插入1w条记录，插入过程中将其中的master服务器停了，看备份服务器是否有这1w笔记录
测试结果，停止主服务器后，java程序抛出异常：

可以看到在插入1059条记录后被停止了。

现在看看备份服务器的记录数是多少，看看在主服务器当机后是否所有数据都能同步过来

大约经过了几十秒，才同步完，数据虽然不是立即同步过来，但没有丢失。

1.2、分片：如何支持可扩展性和负载均衡

fabric分片简介：当一台机器或一个组承受不了服务压力后，可以添加服务器分摊读写压力，通过Fabirc的分片功能可以将某些表中数据分散存储到不同服务器。我们可以设定分配数据存储的规则，通过在表中设置分片key设置分配的规则。另外，有些表的数据可能并不需要分片存储，需要将整张表存储在同一个服务器中，可以将设置一个全局组（Global Group）用于存储这些数据，存储到全局组的数据会自动拷贝到其他所有的分片组中。

简介：

Galera Cluster号称是世界上最先进的开源数据库集群方案

• 真正的多主服务模式：多个服务能同时被读写，不像Fabric那样某些服务只能作备份用
• 同步复制：无延迟复制，不会产生数据丢失
• 热备用：当某台服务器当机后，备用服务器会自动接管，不会产生任何当机时间
• 自动扩展节点：新增服务器时，不需手工复制数据库到新的节点
• 支持InnoDB引擎
• 对应用程序透明：应用程序不需作修改

架构及实现原理：
首先，我们看看传统的基于mysql Replication（复制）的架构图：

Replication方式是通过启动复制线程从主服务器上拷贝更新日志，让后传送到备份服务器上执行，这种方式存在事务丢失及同步不及时的风险。Fabric以及传统的主从复制都是使用这种实现方式。

讯享网

• 由于同一个事务需要在集群的多台机器上执行，因此网络传输及并发执行会导致性能上有一定的消耗。
• 所有机器上都存储着相同的数据，全冗余。
• 若一台机器既作为主服务器，又作为备份服务器，出现乐观锁导致rollback的概率会增大，编写程序时要小心。
• 不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…
• 不支持XA Transaction

目前基于Galera Cluster的实现方案有三种：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。
我们采用较成熟、应用案例较多的Percona XtraDB Cluster。
应用案例：
超过2000多家外国企业使用：

包括：

集群部署架构：

4.1、测试数据同步

在机器24上创建一个表：

使用Java代码在24服务器上插入100条记录

综合考虑上面方案的优缺点，我们比较偏向选择Galera 如果只有两台数据库服务器，考虑采用以下数据库架构实现高可用性、负载均衡和动态扩展：

如果三台机器可以考虑：

MySQL各种集群解决方案的对比：https://www.acquia.com/blog/high-availability-database-tools  

Percona XtraDB Cluster 搭配 HAProxy：http://itindex.net/detail/47688-percona-xtradb-cluster

MySQL Fabric : http://dev.mysql.com/doc/mysql-utilities/1.6/en/fabric.html

MySQL Cluster: http://dev.mysql.com/tech-resources/articles/mysql-cluster-7.3.html

Percona XtraDB Cluster:  http://www.percona.com

======================================

前言
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用方案是一直以来的讨论热点，今天就各种的高可用方案，谈一下个人的一些看法，如有错误，还请指正！！
一、MySQL主从架构
此种架构，一般初创企业比较常用，也便于后面步步的扩展

此架构特点：
1、成本低，布署快速、方便
2、读写分离
3、还能通过及时增加从库来减少读库压力
4、主库单点故障
5、数据一致性问题（同步延迟造成）
二、MySQL+DRDB架构
通过 DRBD 基于 block 块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题





















此架构特点：
1、高可用软件可使用 Heartbeat, 全面负责 VIP、数据与 DRBD 服务的管理
2、主故障后可自动快速切换，并且从库仍然能通过 VIP 与新主库进行数据同步
3、从库也支持读写分离，可使用中间件或程序实现
三、MySQL+MHA架构
MHA 目前在 Mysql 高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在 mysql 故障切换过程中，MHA 能做到快速自动切换操作，而且还能最大限度保持数据的一致性















此架构特点：
1、安装布署简单，不影响现有架构
2、自动监控和故障转移
3、保障数据一致性
4、故障切换方式可使用手动或自动多向选择
5、适应范围大（适用任何存储引擎）
四、MySQL+MMM架构
MMM 即 Master-Master Replication Manager for MySQL（mysql 主主复制管理器），是关于 mysql 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），这个套件也能基于标准的主从配置的任意数量的从服务器进行读负载均衡，所以你可以用它来在一组居于复制的服务器启动虚拟 ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。
MySQL 本身没有提供 replication failover 的解决方案，通过 MMM 方案能实现服务器的故障转移，从而实现 mysql 的高可用。
























此方案特点：
1、安全、稳定性较高，可扩展性好
2、 对服务器数量要求至少三台及以上
3、 对双主（主从复制性要求较高）

4、 同样可实现读写分离

=============================

第一种：主从复制+读写分离

第二种：Mysql Cluster

第三种：Heartbeat+双主从复制

第四种：HeartBeat+DRBD+Mysql

第五种：Lvs+keepalived+双主复制

第六种:MariaDB Galera

==========================================

在这篇文章中，我们将看到不同的MySQL高可用性解决方案，并且检查它们的优势与不足。

高可用性环境为数据库必须保持可用性提供大量的好处。高可用性数据库环境是跨多台机器共同部署的一个数据库，其中任何一个都可以假定数据库的功能。通过这种方式，数据库将不会有“单点故障”。

这儿有很多HA策略和解决方案，那么如何在无数选项中选择最好的解决方案。首先你要考虑的第一个问题是：你要解决的问题是什么？答案归结为冗余、扩展和高可用性，这些并不一定都一样！

• 在灾难事件中需要数据的多个副本
• 需要增加读/写的吞吐量
• 必须尽量减少停机时间

当你规划你的数据库环境时，你重要的是要记住CAP定理的应用。CAP定理将问题分成三个类别：一致性、可用性和分区容忍性。从这三个中，你可以选择任意两个，并牺牲第三个。

• 一致性。所有节点同时看到相同的数据。
• 可用性。每个请求不管成功或者失败都有响应。
• 分区容忍性。尽管任意分区会导致网络故障，但系统仍继续运作。

无论你选择何种解决方案，它应该最大限度的保持一致性。问题是，虽然MySQL复制是伟大的，它本身并不能保证所有节点的一致性。总有潜在的数据不同步，因为事务可能会在故障转移中丢失或由于其他原因。Galera-based集群如Percona XtraDB集群是以认证为基础，来防止这种情况发生！

数据丢失

你应该问自己的第一个问题是：我能承受丢失数据吗?

这通常取决于应用程序。应用程序应该检查事务中的状态码，以确保他们数据不丢失。然而，很多人却不这样！那么，后果是它有可能在故障转移期间丢失事务。在故障转移时，简单的复制方案会有丢失数据的可能性

不一致的节点是另一个问题。如果没有冲突检测和有效的解决方案，则不一致的节点是不可避免的。一个解决方案是运行pt-table-checksum，并经常跨复制节点检查不一致的数据。另一个选择是使用一个Galera-based分布式集群，如Percona XtraDB集群，来认证过程。

避免单点故障

我能承受丢失事务？

很多MySQL DBA担心设置innodb_flush_log_at_trx_commit到1为ACID Compliance和sync_binlog，但使用复制没有一致性检查！这在逻辑上是一致的吗？通过认证Percona XtraDB集群保持一致性。

冲突检测与解决方案

所有的解决方案都必须有一些冲突检测和解决方案。Galera的认证过程遵循以下方法：

• 事务继续作为正常节点，直到达到提交阶段。　　
• 更改收集到一个writeset中。　　
• Writeset发送到所有节点进行认证。　　
• PKs是用来确定writeset是否可以应用。　　
• 如果认证失败，writeset下降，事务回滚。　　
• 如果它成功，事务提交和writesets被应用到所有的节点。　　
• 所有的节点将在每一次事务中都会做出同样的决定，因此确定。

我想做故障转移或分布式系统？

另一个重要考虑因素是是否应该有一个故障转移或分布式系统。故障转移系统在一段时间内运行一个实例，并且当出现问题时，“故障转移”将到另一个实例中。一个分布式系统在同一时间内运行多个实例，并且处理不同的数据。

• 故障转移陷阱：　　　　
  
  • 故障转移系统监控检测失败的节点和移动服务在其他地方是否可用　　
  • 故障转移需要时间！
  
  
  
• 分布式系统：
  
  • 分布式系统最小化故障转移的时间
  
  
  

另一个问题是：你的故障转移应该自动还是手动?

• 利用手动故障转移
  
  • 手动故障转移的主要优点是，人类通常可以做出更好的决定是否有必要做故障转移。　　
  • 系统很少能让它完美，但他们可以关闭！
  
  
  
• 利用自动故障转移
  
  • 更多的9由于最小化中断
  • 不需要等待一个DBA执行
  
  
  

进一步的问题是如何快速使故障转移发生？显然，它发生的速度越快，潜在数据丢失的时间就越少。

• 复制/MHA/MMM
  
  • 取决于需要多长时间来等待副本事务完成之前发生故障转移　　
  • 通常约30秒
  
  
  
• DRBD
  
  • 通常15至30秒
  
  
  
• XtraDB集群/ MySQL集群
  
  • VERY 快速故障转移。通常小于1秒取决于负载均衡器
  
  
  

你有多少9是真的需要的？

“9”测量的精度是为了如何完善系统的一个标准。当涉及到“多少个9”，“每个9的数量级是更准确的。99.99是4个9，而99.999是5个9。

每个管理者一直都会回答多少个9的问题，“尽我所能。“这听起来不错，但现实是需要权衡！许多应用程序可以忍受几分钟的停机时间。下面的表显示了对每个9相关的宕机时间 ︰

我需要进行大规模的读和/或写操作？

当在看你的环境时，重要的是要了解你的工作负载。到底你的工作量沉重的原因是由于读取还是写入或者二者都有？选择你的HA解决方案，最重要的是要知道你读取或写入的规模：

• 规模读取
  
  • 大多数解决方案提供从多个节点读取或副本的能力　　
  • MHA，XtraDB集群，MySQL集群和其他都非常适合
  
  
  
• 规模写入
  
  • 很多人错误地通过写入 XtraDB Cluster 中的多个节点来尝试规模写入，最终导致冲突
  • 其它人尝试主主复制也是有问题的　　
  • 这一点可能是关于MySQL集群最好的解决方案
  
  
  

配置新节点呢？

• 复制
  
  • 很大程度上，这是一个手动过程
  • MySQL工具使这比以往更容易
  
  
  
• 分布式集群
  
  • XtraDB集群和MySQL集群使这更容易
  • XtraDB集群使用状态传输(不锈钢或IST)到自动化集群节点的过程
  
  
  

万事皆三

有多少数据中心?

知道有多少数据中心参与你搭建的环境是一个关键因素。运行多个数据中心会影响你采用 HA 解决方案。

如果我只有一个数据中心呢？你可以获得保护单个失败的节点或者更多，这取决于集群大小。如果你有两个数据中心，你或许应该考虑作为DR解决方案的第二个数据中心。当使用Galera-based集群如XtraDB集群时，有三个或更多的数据中心是最健壮的解决方案。

如何进行故障恢复计划？

灾难恢复计划在HA环境中是至关重要的。确保DR节点(s)可以处理交通，即使在最小的性能水平。

• 从XtraDB集群复制到一个DR网站　　
  
  • 异步复制从XtraDB集群到单个节点　　
  • 异步复制从XtraDB集群复制拓扑　　
  • 从集群XtraDB异步复制到另一个XtraDB集群
  
  
  

需要什么存储引擎？

尤其是现在，还有大量的存储引擎可用于数据库环境。为了你的HA解决方案，你应该使用哪一个？你的解决方案将帮助你确定可以使用哪些存储引擎。

• 不依赖于存储引擎。适用于所有的存储引擎
• XtraDB集群。需要InnoDB。支持MyISAM 是实验性的，并不应在生产中使用
• MySQL集群。需要NDB存储引擎

负载平衡器的选择

负载平衡器提供了一种手段，将你的工作量分布到您的环境资源中去，以免在任何一个特定点造成瓶颈。以下是一些负载平衡选项：

• HAProxy 　　
  
  • 开源软件解决方案　　
  • 不能读和写。如果这是一个前提，这个应用程序需要去使用它！　
  
  
  
• F5 BigIP 　　
  
  • 典型的硬件解决方案　　
  
  
  
• MaxScale 　　
  
  • 可以读/写拆分　　
  
  
  
• 弹性负载均衡器(ELB)

如果群集重新启动，会发生什么?

为了更改应用，某些更改要求集群被重新启动。例如，更改参数组的参数值仅适用于群集后重新启动的群集。群集可能也由于电源中断或其他技术故障而重新启动。由于电源中断或其他技术故障，集群也可以重新启动。

• 断电在单个数据中心可能会导致问题　　
  
  • XtraDB集群为自动启动可以进行配置　
  • 在所有节点同时失去权力时，可能不总是工作。当服务器正在运行时，grastate.dat文件显示了序号 1
  
  
  
• 幸存的重新启动　　
  
  • 如果节点是关机重启或其他此类过程，对系统管理员很有帮助　
  • 正常关机设置正确的序号
  
  
  

需要能够读取后写入吗？

异步复制跨节点并不能保证数据的一致视图。XtraDB集群提供了因果读取。副本将等待该事件用于处理其他查询，保证一致的跨节点读取状态。

如果做很多数据加载呢?

在过去，这是传统的智慧，在这样的场景中使用复制的XtraDB集群。MTS对数据分布在多个模式下有所帮助，但不适合所有的情况。XtraDB集群现在是一个可行的选择，因为我们发现了一个错误，在Galera不能正确地拆分大事务。

对Split Brain采取预防措施

脑裂发生在集群的节点划分，通常由于网络信号，其会形成两个或两个以上的节点新的和独立的集群。XtraDB集群配置进入无主状态，并拒绝接受。一个更新的设置与XtraDB集群将允许脏读取非主节点

我的应用程序需要高并发吗？

新方法来复制允许并行线程(XtraDB集群已经开始)，如多线程服务器(MTS)。MTS允许复制多个SQL线程都有自己的中继日志。由于无法信任SHOW SLAVE STATUS获得中继日志位置，它通过Percona XTRABackup安全使GTID备份。

有限的内存？

一些分布式解决方案比如MySQL集群需要大量的内存，即使基于文件表。一定要适当地计划。XtraDB集群工作更像是一个独立的节点。

我的网络有多稳定？

网络是没有100%的可靠。一些“网络问题”是由于外部因素导致的，如系统资源争用(特别是在虚拟机)。网络问题导致不恰当的故障转移问题。使用局域网段XtraDB集群跨WAN来减少网络流量。

结论

做出正确的选择取决于：

• 知道你真正需要的！　
• 知道你的选择。　　
• 了解你的约束！　
• 了解每种解决方案的优缺点。　
• 设置正确的期望值！

================================

高可用指的是通过尽量缩短因日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性

1. 服务器磁盘空间耗尽
2. 性能糟糕的SQL
3. 表结构和索引没有优化
4. 主从数据不一致
5. 人为的操作失误
6. ……….

• 建立完善的监控和报警系统
• 对备份数据进行恢复测试
• 正确配置数据库环境（从服务器建议只读）
• 对不需要数据进行归档和清理
• 增加系统的冗余，保证系统发生不可用时尽快的恢复
  
  • 避免存在单点故障
  • 主从切换和故障转移
  
  
  

1. 利用SUN共享存储或DRDB磁盘复制解决mysql单点故障
2. 利用多写集群或NDB集群来解决mysql单点故障
   1. NDB很少使用在生成环境中
   2. 如果内存不足，NDB集群的性能就会非常差
3. 利用mysql主从复制来解决单点故障
   1. 主服务器切换后，如何通知应用新的主服务器的IP地址
   2. 如何检查MYSQL主服务器是否可用
   3. 如何处理从服务器和新主服务器的复制关系

MMM的提供了什么功能

• MMM监控主从复制健康情况
• 在主库出现宕机时进行故障转移并自动配置其他从服务器对新主服务器的复制
  
  • 如何找到从库对应的新的主库日志中的同步点
  • 如果存在多个从库出现数据不一致的情况，如何处理
  
  
  
• 提供了主，写 虚拟IP，在主从服务器 出现问题时，可以自动迁移虚拟IP

MMM部署所需资源

MMM部署步骤

1. 配置主主复制 和主从同步集群
2. 安装主从节点所需要的支持包
3. 安装和配置MMM工具包

MMM工具的优点

1. 使用Perl语言开发并完全开源
2. 提供了读写虚拟IP，使服务器角色的变更对前端应用透明
3. 在从服务器出现大量主从延迟，主从链路中断时，可以把这台服务器上的读的虚拟IP，漂移到集群中其他正常的服务器上
4. MMM提供了从服务器的延迟监控
5. MMM提供了主数据库故障转移后，从服务器对新主服务器的重新同步功能
6. 很容易对发生故障的主数据库重新上线

MMM工具的缺点

1. 发布时间比较早，不支持MYSQL新的复制功能（只支持是基于日志点的复制）
   
   1. 注：基于gtid的复制可以保证日志不会重复在slave服务器上被执行
   2. 对于mysql5.6后所提供的多线程复制技术也不支持
   
   
   
2. 没有读负载均衡的功能
3. 在进行主从切换时，容易造成数据丢失
4. MMM监控服务存在单点故障

1. 监控主数据库服务器是否可用
2. 当主DB不可用时，从多个从服务器中选举出新的主数据库服务器
3. 提供了主从切换和故障转移功能

MHA的主从切换过程

1. 尝试从出现故障的主数据库保存二进制日志
2. 从多个备选从服务器中选举出新的备选主服务器
3. 在备选主服务器和其他从服务器之间同步差异二进制数据
4. 应用从原主DB服务器上保存的二进制日志
5. 提升备选主DB服务器为新的主DB服务器

MHA配置步骤

1. 配置集群内所有主机的SSH免认证登录
2. 安装MHA-node软件包和 MHA-manager软件包
   
3. 建立主从复制集群
4. 建立MHA管理节点
5. 使用 和 对配置进行检验

MHA工具的优缺点

1. 同样是由Perl语言开发的开源工具
2. 可以支持GTID的复制模式
3. MHA在进行故障转移时，更不容易产生数据丢失
4. 同一个监控节点可以监控多个集群
5. 需要编写脚本或借助第三方工具来实现虚拟IP的配置
6. MHA启动后只会对主数据库进行监控
7. 需要基于SSH免认证配置，存在一定安全隐患
8. 没有提供从服务器的负载均衡功能

进行mysql主从复制配置的一个主要目的，是为了分担主库的读负载

为什么要读写分离呢？写负载是不能分担的，只能在主库操作，而读操作既可以在主库也可以在从库。

读写分离的方式

• 程序实现读写分离
  • 优点： 由开发人员决定什么样的查询在从库执行，因此比较灵活
  • 优点：由程序直接连接数据库，性能损耗比较少
  • 缺点：增加了开发的工作量，是程序逻辑更加复杂
  • 缺点：人为控制，容易程序错误
• 通过数据库中间件实现
  • mysql-proxy（一直没有稳定版本）
  • MaxScale (比较好)

由中间件实现读写分离的优缺点

• 由中间件根据查询语法分析，自动完成读写分离
• 对于程序透明，对于已有程序不用做任何调整
• 由于增加了中间层，所以对查询效率有损耗（有的达到50%）
• 对于（延迟）敏感业务无法自动在主库执行

如何实现负载均衡

• LVS
• Haproxy
• MaxScale
• F5（硬件）

---