众多团队当业务发展起来后，都会碰到同一个令人头疼之问题，即数据库压力过大，读写愈发迟缓。特别是从事网站、APP 或者企业内部系统相关工作的朋友，必定经历过用户数量增多时，查询出现转圈、后台产生卡顿之尴尬情形。此时倘若仅仅依靠升级单台服务器硬件，不仅成本高昂，而且效果未必理想。实际上更为主流的解决思路，乃是搭建一套数据库负载均衡集群。其究竟如何运作？具备哪些好处与存在哪些坑？今日运用通俗易懂之语言向大家阐释清楚。
集群到底是怎么分担压力的
将数据库请求分散至多台服务器，而非仅由一台机器独自承担，这便是负载均衡集群的核心思想了 ，换种说法就是 ， 在应用程序与数据库之间 ， 会添加一个控制端 （ 也被称作负载均衡器）。 程序不再直接连接数据库 ， 而是先连接这个控制端 ， 由该控制端来判定此次查询应访问哪台数据库服务器。 控制端会实时查看每台数据库当下的连接数 、 CPU 使用率等状况 ， 接着把新请求交付给最空闲的那一台。这般众多服务器共同运转，整体而言处理能力自然而然便提升了。就使用网站或者软件的人来讲，其人对此全然无法觉着背后存在好几台数据库，好似于访问一台具备极强性能的独立服务器。
多台数据库之间怎么保持数据一致
集群若要正常开展工作，存在一个前提是绝对不可以模糊不清的：所有服务器之上的数据都必须是处于实时同步状态的。你仔细想想看，用户 A 从服务器 1 查询到自己刚刚下达的订单，仅仅过了一秒进行刷新就被分配到了服务器 2，然而订单却消失不见了，这样的情况谁能够接受呢？所以说数据同步乃是负载均衡的基础所在。就拿常见的 Moebius for SQL Server 集群方案来说，它会在每一个数据库节点当中安装一个中间件程序。对于这个中间件而言，它能够监测得出哪张表发生了变化，还能监测得出哪条数据发生了变化，之后会将这些变化同步至集群里的其他数据库，等待至所有节点都更新完备，才会给客户端返回“操作成功”。同步过程是以并发形式完成的，同步 10 台所用的时间跟同步 1 台所用的时间大致一样。更为聪慧的是，中间件会按照 SQL 语句的类型，进行智能的同步方式选择：当数据量较小时，会直接传输数据；要是数据中存在大字段，会先进行压缩处理然后再传输；倘若属于批量修改数据或者调整表结构的情况，干脆将 SQL 语句自身发送给其他节点去执行，如此效率要高很多。
扩展强、容灾好，优点很实在
此架构最吸引人之处在于扩展性颇强，业务增长时不必推倒重来，若觉速度慢，直接增添数据库服务器，配置于集群之中便可，对线上服务几乎无影响。并且其可维护性亦佳，集群会自动检测故障节点，将请求转至健康服务器，数据库不会因一台机器宕机而停摆。数据于多台服务器存储了多份，安全性大幅提升，即便一块硬盘损坏或一台服务器出现问题，数据亦不会丢失。此外，鉴于集群对外仅展露一个 IP 地址，数据库服务器皆置于内网，自然而然地便增添了一层安全防护。对于开发人员而言，应用代码之中仅需配置此集群 IP，在更改数据库结构之际亦无需频繁改动代码，极为省事。
控制端和负载分配，两个明显的短板
任何技术都并非完美无缺，有无疑义。这类集群存在一个常见缺点，那就是它无法依据 Web 服务器的处理能力来实施负载分配。缘由在于控制端通常关注的是数据库自身的负载情形，并非全然与前方 Web 服务器的繁忙程度紧密关联，所以在某些复杂调用场景当中，或许会出现分配不够妥当的状况。另外还有一个更理应加以留意的风险，即负载均衡器本身变成了单点故障。要是这台用于控制的机器忽然出现宕机状况，那么整个数据库集群就好似缺失了“门卫”，没有人能够知晓应该连接哪一台数据库，进而业务将会直接陷入瘫痪状态。所以在生产环境当中，通常还需要针对控制端再构建一套高可用方案，就像主备模式那样，以此防止这个“唯一的通道口”发生问题。
总体而言，数据库负载均衡集群是用于解决数据库性能瓶颈的、颇为成熟的一套方案，特别适用于读多写少且数据一致性要求较高的业务场景，它具备突出优点，即扩展较为容易、具备良好容灾能力以及数据安全性较高，然而与此同时，你也必须考虑如何去应对控制端单点故障这一问题。倘若你的业务正受数据库性能困扰，不妨自这套架构着手展开研究。在实际进行落地操作之前，建议先于一个小环境中将同步机制、故障转移流程进行完整测试，待确认均符合预期之后再投入生产，如此更为稳妥。
Comments NOTHING