一:生产负载
第一阶段
配置文件配置,两个机房的网关平均连接到四台mr服务器上:
第二阶段
根据配置文件,项目启动中,网关和mr进行关联,哪一台mr最先连接到网关服务,则本mr服务器为主mr,其余mr作为负载机器;备机-mr;
(类似负载算法里面的最快响应时间)
第三阶段
主mr因网卡、内存等服务器问题导致此服务器故障,切换到备机,内部也是以最快响应时间,选举出某一台备mr作为主mr
注:1.四台mr服务器是怎么关联起来的,我怎么知道我挂了,要从你们三个里面选举一个为主mr呢;
因为,配置文件可配置共享单元配置,将四台mr建立连接关系(注意四台mr必须都要启动),第三章节讲究配置
2.切换过程中,请求会怎么半,丢失吗
分为两种情况,
2.1:mr1挂掉之前收到的未消费的请求,会迁移到另一台mr中,
2.2:在高tps情况下,迁移网关连接mr点、以及迁移请求,会占用网速等服务器资源,在这个迁移过程中,客户发过来的请求,会出现收不到的情况;
二:非功能异常案例
测试场景:
tps200
满足1.1第一阶段情况,四各网关服务,四台mr
每台网关10个实例接收请求,10个实例发送请求,共计80个连接点;
2.1异常场景测试
2.2负载切换
三:配置参数
参数样例如下:
待补充:
注:
消息队列,消息堆积排查思路:
1.排查是否是因为交易响应时间超长导致的,
· 响应时间超长,优化后,还是存在消息堆积的情况,再往下分析
2.交易的响应时间正常时,就要想办法增加从消息队列中获取消息的 速度
2.1 观察服务器当前,cpu和内存使用率,
例如,我们项目组,非功能测试时,200tps要求的cpu使用率,长时间运行,固定在40%左右,
所以当存在堆积情况时,可以第一时间观看服务器资源,要是在60%以下,尝试增加三分之一的线程配置,增加获取消息队列的请求速度;
2.2 获取当前消息队列中,观察一段时间计算,得到一分钟内丢包的交易量,以及大概得出一秒内消息队列的请求量,看一下当前tps大概是多少,结合上面第一部分mr负载配置,计算出线程数,配置到consul内(不同的项目计算方式不一样,大致可以累加,每支交易都按照理想的响应时间计算,)