日志

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

 来源    2020-09-16    0  

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

前言

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

哪些高可用的问题

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

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

由于我们的中间件是作为数据库的代理提供给应用的,即应用把我们的中间件当做数据库,如下图所示:

所以出现上述问题后,业务上很难通过重试等操作去屏蔽这些影响。这就势必需要我们在底层做一些操作,能够自动的感知中间件的状态从而有效避免流量的损失。

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

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

发现并剔除不可用节点

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

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

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

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

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

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

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

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

采用sticky数据源解决问题

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

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

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

让client端感知即将下线

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

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

我们可以复用之前client端检测不可用的逻辑,即让心跳的新建连接失败,而正常请求的新建连接成功。这样,client端就会认为Server不可用,而在内部剔除调这个server。由于我们只是模拟不可用,所以已经建立的连接和正常新建的连接(非心跳)都是正常可用的,如下图所示:

心跳连接的创建在server端可以通过其第一条执行的是mysql的ping而正常流量第一条执行的是一条sql来区分(当然我们采用的Druid连接池在新建连接成功以后也会ping一下,所以采用了另一种方式区分,这个细节在这里就不阐述了)。

三次心跳失败后,client端判定Server1失败,需要将连接到server1的连接销毁。其思路是,业务层用完连接返回连接池的时候,直接给close掉(当然这个是简单的描述,实际操作到Druid数据源也是有细微的差别的)。

由于配置了一个connection最长保持时间,所以在这个时间之后肯定会对Server1的连接数为0 由于线上流量也不低,这个收敛时间是比较快的(进一步的做法,其实是主动去销毁,不过我们尚未做这个操作)。

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

在上述小心翼翼的操作之后,在Server1下线的过程中,是不会有流量损失的。但是我们在Server端还需要判定何时不会再有新的流量,这个判定标准即是Server1没有任何一个client端的连接。 这也是上面我们在执行完sql后销毁连接从而可以让连接数变为0的原因,如下图所示:
当连接数为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的,如下图所示:
采用这种方案的话,会在很大程度上降低我们client端代码的复杂度。
但是这样无疑又给client端增加了一个新的配置,对使用人员就又多了一个负担,还得在网络上多一次开墙的操作,所以我们采取了recover_time的方案。

中间件的启动顺序问题

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

总结

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

公众号

关注笔者公众号,获取更多干货文章:

轻量级的分库分表中间件 – aude-sharding
日志说明 轻量级的分库分表中间件.可以和spring搭配使用. 图解 配置 主要是两个方面的配置:数据源和路由规则 数据源 (spring-db.xml) <beans xmlns="ht ...
1
sharding-jdbc,轻量级数据库分库分表中间件
日志Sharding-JDBC是当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架,实现透明化数据库分库分表访问.Sharding-JDBC是继dubbox和ela ...
2
Mysql系列五:数据库分库分表中间件mycat的安装和mycat配置详解
日志 一.mycat的安装 环境准备:准备一台虚拟机192.168.152.128 1. 下载mycat cd /software wget http://dl.mycat.io/1.6-RELEASE/ ...
分库分表中间件sharding-jdbc的使用
日志数据分片产生的背景,可以查看https://shardingsphere.apache.org/document/current/cn/features/sharding/,包括了垂直拆分和水平拆分的 ...
2
当当开源sharding-jdbc,轻量级数据库分库分表中间件
日志近期,当当开源了数据库分库分表中间件sharding-jdbc. Sharding-JDBC是当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架,实现透明化数据 ...
1
分布式事务、多数据源、分库分表中间件之spring boot基于Atomikos+XADataSource分布式事务配置(100%纯动态)
日志本文描述spring boot基于Atomikos+DruidXADataSource分布式事务配置(100%纯动态),也就是增加.减少数据源只需要修改application.properties文件 ...
分布式数据库中间件,分库分表中间件
日志分布式数据库中间件对比总结(1) 目前数据库中间件有很多,基本这些中间件在下都有了解和使用,各种中间件优缺点及使用场景也都有些心的.所以总结一个关于中间件比较的系列,希望可以对大家有帮助. 1. 什么 ...
高可用Mysql架构_Mysql主从复制、Mysql双主热备、Mysql双主双从、Mysql读写分离(Mycat中间件)、Mysql分库分表架构(Mycat中间件)的演变
日志[Mysql主从复制]解决的问题数据分布:比如一共150台机器,分别往电信.网通.移动各放50台,这样无论在哪个网络访问都很快.其次按照地域,比如国内国外,北方南方,这样地域性访问解决了.负载均衡:M ...
2
SpringBoot 2.0 整合sharding-jdbc中间件,实现数据分库分表
日志本文源码:GitHub·点这里 || GitEE·点这里 一.水平分割 1.水平分库 1).概念: 以字段为依据,按照一定策略,将一个库中的数据拆分到多个库中. 2).结果 每个库的结构都一样:数据都 ...
1
基于代理的数据库分库分表框架 Mycat实践
日志192.168.199.75 MySQL . MyCAT master 192.168.199.74 MySQL slave 192.168.199.76 MySQL standby master 如 ...
1
分库分表 sharding-jdbc实践—分库分表入门
日志一.准备工作 1.准备三个数据库:db0.db1.db2 2.每个数据库新建两个订单表:t_order_0.t_order_1 DROP TABLE IF EXISTS `t_order_x`; CR ...
中间件 MyCat读写分离、分库分表
日志系统开发中,数据库是非常重要的一个点.除了程序的本身的优化,如:SQL语句优化.代码优化,数据库的处理本身优化也是非常重要的.主从.热备.分表分库等都是系统发展迟早会遇到的技术问题问题.Mycat是一 ...
Mycat数据库中间件对Mysql读写分离和分库分表配置
日志Mycat是一个开源的分布式数据库系统,不同于oracle和mysql,Mycat并没有存储引擎,但是Mycat实现了mysql协议,前段用户可以把它当做一个Proxy.其核心功能是分表分库,即将一个 ...
1
MyCat | 分库分表实践
日志引言 先给大家介绍2个概念:数据的切分(Sharding)根据其切分规则的类型,可以分为两种切分模式. 切分模式 一种是按照不同的表(或者Schema)来切分到不同的数据库(主机)之上,这种切可以称之 ...
1
分库分表(1) --- 理论
日志分库分表---理论 当一张表的数据达到几千万时,查询一次所花的时间会变长.业界公认MySQL单表容量在 1千万 以下是最佳状态,因为这时它的BTREE索引树高在3~5之间. 数据切分可以分为:垂直切分 ...
2
分库分表之后,id 主键如何处理?
日志面试题 分库分表之后,id 主键如何处理? 面试官心理分析 其实这是分库分表之后你必然要面对的一个问题,就是 id 咋生成?因为要是分成多个表之后,每个表都是从 1 开始累加,那肯定不对啊,需要一个全 ...
三、SpringBoot 整合mybatis 多数据源以及分库分表
日志前言 说实话,这章本来不打算讲的,因为配置多数据源的网上有很多类似的教程.但是最近因为项目要用到分库分表,所以让我研究一下看怎么实现.我想着上一篇博客讲了多环境的配置,不同的环境调用不同的数据库,那接 ...
2
数据库分库分表思路
日志一. 数据切分 关系型数据库本身比较容易成为系统瓶颈,单机存储容量.连接数.处理能力都有限.当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库.优化索引,做很多操作时性能仍下降 ...
1
分库分表的基本思想
日志Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上,从而缓解单一数据库的性能问题.不太严格的讲,对于海量数据的数据库,如果是因为表多而数据多,这时候适合使用垂直 ...
1
Sql的分库分表,及优化
日志对Sql细节优化 在sql查询中为了提高查询效率,我们常常会采取一些措施对查询语句进行sql优化,下面总结的一些方法,有需要的可以参考参考. 首先给大家介绍一下分库分表 分库分表 分库 垂直分库 业务 ...