阅读笔记（六）

高可用目标-传统方法

确定这个方向之后我们就需要定一个目标，首先确定一个目标。高可用其实都是指几个9，5个9的话可能就是电信级或者金融级的，互联网大部分是3个9到4个9。

刚开始也想用这个指标作为一个目标，比如说想达到4个9或者5个9，但是这个指标的优点是业界通用，搞技术的大家都接受了这个指标。

但是有一个缺点，除了技术人员，其他同学不是很好理解，他们没有办法将4个9或者5个9转换成直观的理解。所以，我们当时在定项目目标的时候并没有这样去定。

高可用目标-面向业务

我们最终确定的目标跟几个9的目标有一个比较大的区别，几个9的目标主要是从系统的角度去考虑的，就是说这个系统的可靠性是几个9。

而我们的目标是面向整个业务，这个目标就是3分钟来定位问题，5分钟能恢复业务，而且问题的发生频率不能太高，2个月发生一次。

这个目标的优点：

1、聚焦业务。

2、容易分解。目标本身就是我们的工作方向，首先要定位问题，怎么定位问题？我们就可以想一个办法，其次是恢复业务，第三是故障的频率不能太高；

3、容易衡量。我们后来再做方案的时候，很多方案只要拿这个标准一套，基本上就能够判断这个方案是否可行。

整个目标最后折算下来，对应的差不多是4个9左右，比4个9高一点点。

HTTP-DNS

客户端重试

在游戏接入阶段，游戏里会嵌入我们的SDK，对于SDK内的产品来说，如果遇到后端故障，最快、对用户影响最小的解决方式是立刻去重试，服务器1有故障的话，我们重新发一个请求到服务器2，就能够正确处理业务。

重试里面有一个关键点需要特别注意，重试的时候必须保证这个请求不要再发到原来有问题的服务器上面，否则这个重试只是浪费时间。

原文部分转载：

阿里游戏高可用架构设计实践