kbmMW均衡负载与容灾(1)(转载红鱼儿)

简介: kbmMW为均衡负载与容灾提供了很好的机制,支持多种实现方式,现在看看最简单的一种,客户端控制的容灾和简单的负载均衡。 现在,我们将kbmMWServer部署到不同的服务器,或者在同一服务器部署多份实例,这样,我们会有一个服务的访问列表: 192.168.0.88:9000 192.168.0.88:9001 192.168.0.89.9000 192.168.0.89.9001 服务准备好了,现在,改造一下客户端的Transport,就可以实现容灾和负载均衡。

kbmMW为均衡负载与容灾提供了很好的机制,支持多种实现方式,现在看看最简单的一种,客户端控制的容灾和简单的负载均衡。

现在,我们将kbmMWServer部署到不同的服务器,或者在同一服务器部署多份实例,这样,我们会有一个服务的访问列表:
192.168.0.88:9000
192.168.0.88:9001
192.168.0.89.9000
192.168.0.89.9001

服务准备好了,现在,改造一下客户端的Transport,就可以实现容灾和负载均衡。具体来说,就是利用ClientTransport的两个属性与一个事件:
两个属性:
MaxRetrires:重联次数,触发ClientTransportReconnect事件时,参数Alternative为False
MaxRetriesAlternative:换Transport地址的重联次数,触发ClientTransportReconnect事件时,参数Alternative为True

系统首先按MaxRetries定义的次数试着联接服务,如果都不成功,再按MaxRetriesAlternative定义的次数试着联接服务器,再不 成功,最终触发OnConnectionLost事件。如果你没有处理OnConnectionLost事件,则产生异常Connection lost。每次重联,都会触发ClientTransportReconnect事 件,在这个事件中,通过参数Alternative可以判断是否需要重新定义Transport服务地址,如果换了新的服务地址,则系统按新地址重联服务 器。假设MaxRetries定义3,MaxRetriesAlternative定义为2,则一共试着重联服务器5次,最后两次,在触发ClientTransportReconnect事件时,Alternative参数为True。

一个事件,这个事件有三个参数:
Sender:Transport对象
Alternative:为True表示应该换一个服务地址
RetriesLeft:剩余的重联次数


下面代码演示了如何利用这个事件更换服务器地址:
procedure TwpMainModule.kbmMWHTTPSYSClientTransport1Reconnect(Sender: TObject;
  Alternative: Boolean; RetriesLeft: Integer);
var
  i:integer;
const
  AltHosts:array [0..5] of string = (
  '192.168.0.88:9000',
  '192.168.0.88:9001',
  '192.168.0.88:9002',
  '192.168.0.89:9000',
  '192.168.0.89:9001',
  '192.168.0.89:9002'
  );
begin
  if Alternative then
  begin
    i:=Random(High(AltHosts)-1);
    TkbmMWCustomClientTransport(Sender).host:=AltHosts[i];
  end;
end;

OK,最简单的均衡负载就这样实现了!

这样处理看起来简单,但存在问题,第一是每个客户端都要知道服务的列表,如果列表变化,不便维护;另外,没有实现真正的均衡,用户有可能都跑到一个服务上。为了解决这些问题,明天计划整理【集中式均衡负载的实现方式】。

参考kbmMW作者的说明文档

目录
相关文章
|
2月前
|
监控 安全
Bently Nevada 3500/77M往复式气缸压力监控器
3500/77M往复式气缸压力监测器是4通道设备,用于接收并调节Bently Nevada认证的压力传感器信号,实现往复式压缩机的压力监测。它通过持续对比监测参数与预设报警值,确保机械安全,同时提供关键运行数据。每个通道可处理8个与气缸压力相关的测量变量,包括排气、吸气压力等,以及结合机械参数计算的峰值杆压缩、张力和反转度等。详情见用户指南(文件146282)。
|
数据中心 网络虚拟化 虚拟化
联盟时代VIII.灾难容错和切换(2)
在上期的分享中,笔者对Federation网络架构下满足“本地输出”要求的场景在出现故障时的容错和切换情况进行了说明。当整体NSX网络在设计时就充分考虑冗余的前提下,大部分的“组件故障”并不会引起大面积的“业务停摆”。但Edge集群的故障不仅仅会造成南北向网络可达性的中断,也同样会造成跨数据中心的东西向网络中断;因此笔者认为Edge集群的稳定性很大程度上决定了Federation网络的稳定性。今天的分享将围绕不满足“本地输出”的场景展开,看看在具有Tier1SR实例的Federation网络模型中,灾难容错和网络切换的情况究竟是如何的一番天地。
|
弹性计算 负载均衡 测试技术
|
NoSQL MongoDB 开发工具
分片第一套和第二套副本集搭建|学习笔记
快速学习分片第一套和第二套副本集搭建
分片第一套和第二套副本集搭建|学习笔记
|
负载均衡 调度 网络架构
LVS+Keepalived高可用群集(无论头上是怎样的天空,我准备着承受任何风暴)(一)
LVS+Keepalived高可用群集(无论头上是怎样的天空,我准备着承受任何风暴)(一)
106 0
LVS+Keepalived高可用群集(无论头上是怎样的天空,我准备着承受任何风暴)(一)
|
网络协议 调度
LVS+Keepalived高可用群集(无论头上是怎样的天空,我准备着承受任何风暴)(二)
LVS+Keepalived高可用群集(无论头上是怎样的天空,我准备着承受任何风暴)(二)
159 0
LVS+Keepalived高可用群集(无论头上是怎样的天空,我准备着承受任何风暴)(二)
|
存储 算法 安全
亿级流量架构,服务器如何扩容?写得太好了(2)
亿级流量架构,服务器如何扩容?写得太好了(2)
188 0
亿级流量架构,服务器如何扩容?写得太好了(2)
|
存储 缓存 固态存储
亿级流量架构,服务器如何扩容?写得太好了
亿级流量架构,服务器如何扩容?写得太好了
226 0
亿级流量架构,服务器如何扩容?写得太好了
|
存储 缓存 弹性计算
嗖嗖嗖,想了解一致性Hash,看这一篇就可以了
嗖嗖嗖,想了解一致性Hash,看这一篇就可以了
236 0
嗖嗖嗖,想了解一致性Hash,看这一篇就可以了
|
存储 NoSQL 算法
你管这破玩意儿叫高可用
你管这破玩意儿叫高可用

热门文章

最新文章