Page 272 - 《软件学报》2026年第1期
P. 272

向清平 等: 分布式数据库高可用研究进展                                                             269


                 寻找一个合适的虚拟机        (virtual machine,VM) 来执行任务. TA  将保存所有  VM  的列表以及它们的索引值, 这被称
                 为索引表或分配表, 其中       VM  的各自状态    (如可用/忙/闲) 也被存储. 如果一个        VM  是可用的并且有足够的空间, 则
                 任务被接受并分配给该        VM; 如果没有找到可用的        VM, 则  TA  返回  1, 否则请求排队进行快速处理.
                    基于均衡扩展电流执行         (equally spread current execution, ESCE) 的负载均衡是一种动态算法. 它将作业的大小
                 作为优先级, 然后将工作负载随机地分配给一个轻负载的                   VM. ESCE  依赖于使用队列来存储请求, 并在存在过载
                 的  VM  时将负载分配给     VM. Aliyu  等人  [56] 提出了一种混合方法, 为每个   VM  保持一个阈值作为优先级, 以实现相
                 同的负载分配. 减少响应时间, 降低成本, 提高系统可用性.
                    基于加权轮询      (weighted round robin, WRR) 的负载均衡与传统的轮询类似, 但该算法考虑了每个节点的权重.
                 权重由开发者分配, 基于容量最大的虚拟机. 在此基础上, Chen               [57] 提出了一种基于聚类的      WRR  方法. 该云负载均
                 衡  (cloud load balancing, CLB) 算法可以基于  CPU、内存对虚拟机进行聚类, 并为每个虚拟机分配不同的权重值.
                 结果表明, 在虚拟     Web  服务器数量相同的情况下, 减少了响应时间, 提高了系统的可用性.

                  2.3   应用与服务
                    本节通过分析查询处理、中间件和虚拟化这                3  个层面的技术, 展示高可用数据库在不同的层面上的应用与服
                 务. 本文针对每个层面介绍相关的技术和方法. 这些技术既可以独立应用也可以结合使用, 形成一个更加完善的高
                 可用性体系, 从而在云计算和大规模分布式系统中, 保障服务的连续性和用户体验的优化.
                  2.3.1    查 询
                    随着系统规模的增长, 节点故障变得很常见, 文献               [58] 介绍了一种新的框架, 允许主机数据库有效地管理大
                 规模辅助分布式系统的可用性, 并描述了一种通过在辅助分布式系统上透明地重新执行查询                                (子) 计划来实现主
                 数据库查询容错的机制. 该框架减少由于故障引起的系统停机时间, 并在查询执行过程中实现对用户的故障透明
                 性, 使用户无感知地获得完整的查询结果, 达到改善 分布式系统的可用性的目标. 该框架的提出基于一种为
                 RDBMS  加速器系统开发和部署的新可用性框架, 称为              RAPID [59] . RAPID  是一个可插拔的横向扩展关系查询处理
                 引擎, 可以连接到关系数据库系统以卸载分析查询. 该框架指出, 影响系统可用性和用户体验的重要参数是错误率、
                 平均恢复时间和透明故障率. 错误率因素取决于系统软件和硬件组件的弹性, 透明性意味着用户在                               RAPID  中执行
                 查询期间不会收到失败通知, 并且无缝地接收查询结果. 其对于任何给定的错误率, 通过低延迟故障转移实现高可
                 用性  (改善“平均恢复时间”), 在查询执行期间将故障与最终用户隔离                   (改善“透明故障率”). 当    RAPID  节点发生故
                 障时, 由备用节点替换, 并从主机数据库中重新加载其数据分区. 查询计划中存在一个                         RAPID  运算符, 该运算符可
                 以访问为   RAPID  编译的可分配负载子计划和另一个相同的为主机数据库编译的子计划. 为了确保用户查询的透
                 明执行, 系统引入了一种自动重新执行查询的机制: 当                RAPID  节点发生故障时, 系统会自动检测并重新执行受影
                 响的查询, 确保查询结果的完整性和一致性. 此外, 系统还实现了一个托管机制, 在主机数据库中的                            RAPID  操作符
                 处保存从每个节点到达的结果行, 直到该节点完成其所有结果的发送. 主机数据库中的                            RAPID  操作符与   RAPID
                 节点之间的通信基于使用零拷贝机制的网络协议.
                  2.3.2    中间件
                    文献  [60] 将高可用性解决方案分为中间件方法和基于虚拟化的方法两类, 针对不同层的故障提供不同的保
                 护机制, 提出了一个评估可用性解决方案的框架, 针对不同的故障类型                      (应用程序故障、VM       故障、主机故障) 设
                 置评审标准. 在文献      [61] 的研究中, 又进一步将解决方案组织为          3  层  (底层技术、服务和中间件), 并且上层可以由
                 底层的一个或多个解决方案组成. 在云环境中, 数据库系统与中间件的高可用性机制密切相关. 虽然中间件通过冗
                 余、负载均衡和故障转移等机制保证应用层的高可用性, 但若数据库系统出现故障或不可用, 则会直接影响整个
                 系统的稳定性和数据一致性. 数据库的容错性需要与中间件层的容错机制协同工作, 保证在数据库节点发生故障
                 时, 中间件能够自动进行备份和故障转移, 确保数据的高可用性. 中间件架构也会通过集成数据库的分布式副本、
                 数据同步和恢复机制来实现高可用. 数据库系统和中间件的高可用性之间的协作和融合在提供云服务时显得尤为
                 重要. 高效的高可用性设计需要同时考虑数据库的冗余复制、故障转移机制与中间件的容错处理策略, 确保云平
   267   268   269   270   271   272   273   274   275   276   277