魔卡动漫网，总裁别再玩了，品匠
分库分表中间件的高可用实践 前言
分库分表中间件在我们一年多的锤炼下，基本解决了可用性和高性能的问题(只能说基本，肯定还有隐藏的坑要填)，问题自然而然的就聚焦于高可用。本文就阐述了我们在这方面做出的一些工作。
哪些高可用的问题
作为一个无状态的中间件，高可用问题并没有那么困难。但是尽量减少不可用期间的流量损失，还是需要一定的工作的。这些流量损失主要分布在:
(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也可能是后端关闭了这个连接,并不代表整体不可用),如下图所示:
本文地址：http://www.reviewcode.cn/bianchengyuyan/211697.html 转载请注明出处！
伍佰目录声明:本站部分文章来源于网络,版权属于原作者所有。如有转载或引用文章/图片涉及版权问题,请联系我们处理.我们将在第一时间删除！ 联系邮箱：tsk@qq.com
