深证通mr-深入了解，配置文件、异常案例、负载

一：生产负载

第一阶段

配置文件配置，两个机房的网关平均连接到四台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内（不同的项目计算方式不一样，大致可以累加，每支交易都按照理想的响应时间计算，）