分库分表中间件的高可用实践

梦里梦外; 2022-01-30 02:31 169阅读 0赞

## 前言 ##

分库分表中间件在我们一年多的锤炼下，基本解决了可用性和高性能的问题(只能说基本，肯定还有隐藏的坑要填)，问题自然而然的就聚焦于高可用。本文就阐述了我们在这方面做出的一些工作。

## 哪些高可用的问题 ##

作为一个无状态的中间件，高可用问题并没有那么困难。但是尽量减少不可用期间的流量损失，还是需要一定的工作的。这些流量损失主要分布在:

(1)某台中间件所在的物理机突然宕机。      
    (2)中间件的升级和发布。

由于我们的中间件是作为数据库的代理提供给应用的,即应用把我们的中间件当做数据库，如下图所示:  
![3f0670453000af8d3609b48aabddb6437c6.jpg][]  
所以出现上述问题后，业务上很难通过重试等操作去屏蔽这些影响。这就势必需要我们在底层做一些操作，能够自动的感知中间件的状态从而有效避免流量的损失。

## 中间件所在物理机宕机的情况 ##

物理机宕机其实是一种常见现象，这时候应用一瞬间就没了响应。那么跑在上面的sql肯定也是失败了的(准确来说是未知状态，除非重新查询后端数据库，应用无法得知准确的状态)。这部分流量我们肯定是无法挽救。我们所做的是在client端(Druid数据源)能够快速的发现并剔除宕机的中间件节点。

### 发现并剔除不可用节点 ###

通过心跳去发现不可用节点

自然而然的我们通过心跳来探查后端中间件的存活状态。我们通过定时创建一个新连接ping(mysql的ping)一下然后立马关闭来做心跳(这种做法便于我们区分正常流量和心跳流量，如果通过保持一个连接然后一直发送类似select '1'的sql这种方式的话区分流量会稍微麻烦点)。 ![2c251045cec3109bc1833ad984049783e7c.jpg][]  
为了防止网络抖动造成的偶发性connect失败，我们在三次connect都失败后才判定某台中间件处于不可用状态。而这三次的探活却延长了错误感知时间，所以我们三次connect的时间间隔是指数级衰减的，如下图所示: ![7030877a8b9d4fe08a07ad0f948ca099d3a.jpg][]  
为何不在第一次connect失败后，连续发送两次connect呢？可能考虑到网络的抖动可能会有一个时间窗口，如果在时间窗口内连续发了3次，出了这个时间窗口网络又okay了，那么会错误的发现后端某节点不可用了,所以我们就做了指数级衰减的折衷。

通过错误计数去发现不可用节点

上述的心跳感知始终有一个时间窗口，当流量很大的时候，在这个时间窗口内使用这个不可用节点的都会失败,所以我们可以使用错误计数去辅助不可用节点的感知(当然这个手段的实现还在计划中)。 ![791e4d646fb8ccb50676ba1d2eb727cd03e.jpg][]  
这边有一个注意的点是，只能通过创建连接异常来计数，并不能通过read timeout之类的来计算。原因是，read timeout异常可能是慢sql或者后端数据库的问题导致，只有创建连接异常才能确定是中间件的问题(connection closed也可能是后端关闭了这个连接,并不代表整体不可用),如下图所示:  
![a2db446d9329662ad1d13bb51e91af182ac.jpg][]

### 一个请求使用若干个连接导致的问题 ###

由于我们需要保证事务尽可能小，所以在一个请求里面多条sql并不使用同一个连接。在非事务(auto-commit)情况下，运行多少条sql就从连接池里面取出多少连接，并放回。保证事务小是非常重要的，但是这在中间件宕机的时候会导致一些问题，如下图所示: ![2b7d985e8bad232d7f0912b27dc233ae5af.jpg][]  
如上图所示，在故障发现窗口期中(即还没有确定某台中间件不可用时)，数据源是随机选择连接的。而这个连接就有一定1/N(N为中间件个数)的概率命中不可用中间件导致一条sql失败进而导致整个请求失败。我们做一个计算：

假设N为8,一个请求有20条sql,
    那么在这个期间每个请求失败的概率就为(1-(7/8)的20次方)=0.93,
    即有93%的概率会失败！

更为甚者，整个应用集群都会经历这个阶段，即每台应用都有93%的概率失败。 一台中间件宕机导致整个服务在十几秒内基本所有请求基本都失败，这是不可忍受的。

采用sticky数据源解决问题

由于我们不能瞬间发现并确认中间件不可用，所以这个故障发现窗口肯定存在(当然，错误计数法会在很大程度上缩短发现时间)。但理想状况下，宕机一台，只损失1/N的流量就好了。我们采用了sticky数据源解决了这个问题，使得在概率上大致只损失1/N的流量,如下图所示: ![3f3090bd8126e62ed1a71b7206cf0b7b312.jpg][]  
而配合错误计数的话，总流量的损失会更小(因为故障窗口短)  
如上图所示，只有在故障时间内随机选择到中间件2(不可用)的请求才会失败，再让我们看下整个应用集群的情况。 ![10d0670fbd30e24b9c81ca3c3137ac5ebaa.jpg][]  
只有sticky到中间件2的请求流量才有损失，由于是随机选择，所以这个流量的损失应用在1/N。

## 中间件升级发布过程中的高可用 ##

分库分表中间件的升级发布不可避免。例如bug fix以及新功能添加等都需要重启中间件。而重启的时间也会导致不可用，与物理机宕机的情况相比是其不可用的时间点是可知的，重启的动作也是可控的，那么我们就可以利用这些信息去做到流量的平滑无损。

### 让client端感知即将下线 ###

在笔者所知的很多做法中，让client端感知下线是引入一个第三方协调者(例如zookeeper/etcd)。而我们并不想引入第三方的组件去做这个操作，因为这又会引入zookeeper的高可用问题，而且会让client端的配置更加复杂。平滑无损的大致思路(状态机)如下图所示: ![47ec1986451cd812e74b71e8ef4da2081d2.jpg][]

让心跳流量感知下线而正常流量保持

我们可以复用之前client端检测不可用的逻辑，即让心跳的新建连接失败，而正常请求的新建连接成功。这样，client端就会认为Server不可用，而在内部剔除调这个server。由于我们只是模拟不可用，所以已经建立的连接和正常新建的连接(非心跳)都是正常可用的，如下图所示:  
![6c4a4ee1cf7fdfd50a1aeab7d9389fbe954.jpg][]  
心跳连接的创建在server端可以通过其第一条执行的是mysql的ping而正常流量第一条执行的是一条sql来区分(当然我们采用的Druid连接池在新建连接成功以后也会ping一下，所以采用了另一种方式区分,这个细节在这里就不阐述了)。

三次心跳失败后，client端判定Server1失败，需要将连接到server1的连接销毁。其思路是，业务层用完连接返回连接池的时候,直接给close掉(当然这个是简单的描述，实际操作到Druid数据源也是有细微的差别的)。  
![8cf8c07405e4e822445e04b21b3952de7e9.jpg][]  
由于配置了一个connection最长保持时间,所以在这个时间之后肯定会对Server1的连接数为0 由于线上流量也不低,这个收敛时间是比较快的(进一步的做法，其实是主动去销毁,不过我们尚未做这个操作)。

如何判定下线Server再也没有流量

在上述小心翼翼的操作之后，在Server1下线的过程中，是不会有流量损失的。但是我们在Server端还需要判定何时不会再有新的流量,这个判定标准即是Server1没有任何一个client端的连接。 这也是上面我们在执行完sql后销毁连接从而可以让连接数变为0的原因，如下图所示: ![b2918b273b4b6e600d05153e6ffb31d8714.jpg][]  
当连接数为0后，我们就可以重新发布Server1(分库分表中间件)了。对于这一点，我们写了个脚本,其伪代码如下所示:

while(true){
    	count =`netstat -anp | grep port | grep ESTABLISHED | wc -l`
    	if(0 == count){
    		// 流量已经为0，关掉服务器
    		kill Server
    		// 发布升级服务器
    		public Server
    		break
    	}else{
    		Sleep(30s)
    	}
    }

将这个脚本接入发布平台，即可进行滚动式上下线了。  
现在可以解释下recover\_time为何要较长了，因为新建连接也会导致脚本计算出来的 connection count数量增加，所以需要一个时间窗口不去建立心跳，从而能让这个脚本顺利运行。

recover\_time其实是非必要的

如果我们将心跳创建的端口号和正常流量的端口号分开，是不需要recover\_time的，如下图所示: ![06661563e17efbce31f3cfa5d4b748d3bd8.jpg][]  
采用这种方案的话，会在很大程度上降低我们client端代码的复杂度。  
但是这样无疑又给client端增加了一个新的配置，对使用人员就又多了一个负担，还得在网络上多一次开墙的操作，所以我们采取了recover\_time的方案。

### 中间件的启动顺序问题 ###

前面的过程是一个优雅下线的过程，但我们发现我们的中间件才上线的时候在某些情况下也不会优雅。即在中间件启动时候，如果对后端数据库刚建立的连接建立上去后由于某些原因断开了，会导致中间件的reactor线程卡住一分钟左右，这段时间无法服务，造成流量损失。所以我们在后端数据库连接全部创建成功后，再启动reactor的accept线程从而接收新的流量，从而解决这一问题，如下图所示: ![f3b36db23894680c9c7b8b1c99428d5ac6a.jpg][]

## 总结 ##

笔者个人感觉高可用比高性能还要复杂。因为高性能可以在线下反复的去压测，通过压测的数据去分析瓶颈，提高性能。而高可用需要应付线上各种千奇百怪的现象，本篇博客讲述的高可用方案只是我们工作的一小部分，还有很大一部分精力是处理中间件本身的问题上。但只要不放过任何一个点，将问题都能够分析清楚并解决，就会让系统越来越好。

[3f0670453000af8d3609b48aabddb6437c6.jpg]: /images/20220130/8001b84daec040e2b5ae8f33cf16cf53.png
[2c251045cec3109bc1833ad984049783e7c.jpg]: /images/20220130/7e403cfd28df498ba49127a9b8e1b9f8.png
[7030877a8b9d4fe08a07ad0f948ca099d3a.jpg]: /images/20220130/cc58b89ea33c450282d2f89734b4046d.png
[791e4d646fb8ccb50676ba1d2eb727cd03e.jpg]: /images/20220130/4b8d808fd3c2491ca6f91189b97a9030.png
[a2db446d9329662ad1d13bb51e91af182ac.jpg]: /images/20220130/06471b03b4694a1a90e169ea86ad287b.png
[2b7d985e8bad232d7f0912b27dc233ae5af.jpg]: /images/20220130/b2418a41367449deba60a83d9af0eec3.png
[3f3090bd8126e62ed1a71b7206cf0b7b312.jpg]: /images/20220130/f7a8dbff27f041018fbff8f078931d73.png
[10d0670fbd30e24b9c81ca3c3137ac5ebaa.jpg]: /images/20220130/a7696edebe98486bbe67f30598f565bd.png
[47ec1986451cd812e74b71e8ef4da2081d2.jpg]: /images/20220130/683af098965c4f2f9cce12528becd09e.png
[6c4a4ee1cf7fdfd50a1aeab7d9389fbe954.jpg]: /images/20220130/890b8868feca4278b9cb64f4d3168e08.png
[8cf8c07405e4e822445e04b21b3952de7e9.jpg]: /images/20220130/2c2f472fc78a4d608c47b03881a038fe.png
[b2918b273b4b6e600d05153e6ffb31d8714.jpg]: /images/20220130/99c669a50a78482da6b81718bea5d9b3.png
[06661563e17efbce31f3cfa5d4b748d3bd8.jpg]: /images/20220130/3d2d324019eb40ad8403ea1ff23ee49f.png
[f3b36db23894680c9c7b8b1c99428d5ac6a.jpg]: /images/20220130/12dc40fb0096420588329baa6dd96aa7.png