容灾处理 - Githubissues

前言

本篇聊一聊最近在的相关的容灾处理。在前端开发中，容灾也是一块需要考虑的部分。因为一旦线上的请求崩溃了，系统能够及时的进行容灾，对于用户来说，至关重要。一般来说，容灾的方案有很多种，这里涉及到的就是最简单的一种容灾方案。如果喜欢我的博客，请关注github博客

首先，我们来聊一下，前后端部分都是如何处理进行容灾处理的。

最简单的方案就是：后端将最新请求的一份数据，备份下来，存入hashMap里面去，然后放到cdn上面；前端在判断后端数据请求失败之后，请求相应的cdn上面的数据。如图所示：

其中用第一次请求，表示一个用户的正常请求，然后将第一次请求的数据备份在CDN上面，之后，在第二次请求失败的时候，前端会去请求，相对应的cdn地址，获取相应的数据。根据这份备份的数据，重新渲染页面。

首先，我们需要在前端设置一下请求参数，因为根据后端的规则，后端不会每次都去备份数据，之后当请求参数，出现不一致时，后端那边才会根据请求参数去备份数据。

这种方案的缺点：

数据实时性不高

对于动态数据来说，这个容灾方案并不适用于实时性很高的应用，如果需要实时性较高的方案，还是切换服务器来的实在一些。

一般来说，使用hash是比较方便的，直接对相应的参数拼接成的参数进行md5加密，然后拼接成对应的cdn链接。

这样的好处是，hash的唯一性，使得前后端交流的成本较低。如下代码：

backupUrl: (params) => {
    const key = md5(params.join(''));
    return `https://cdnxxx.com/${key}`;
}

后端也可以根据这样的拼接规则，同步到cdn，然后前端根据之前生成的cdn去请求数据。

需要注意的地方就是：跨域问题。

这部分请求回来的数据，大多都是JSON的格式，通过get方法请求回来的，必然会遇到不同域之间的跨域问题。

容灾的处理方法有很多种，这里只是使用了最简单的一种方式。业务中尤其是对于一些商品列表来说，可以使用这种方式进行处理。当然咯，这里的商品不是实时切换的那种，哈。