搭建高可用系统架构与性能优化

Posted 2022-04-05 赵广陆

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了搭建高可用系统架构与性能优化相关的知识，希望对你有一定的参考价值。

1 单点架构分析

当我们看到一个庞大的系统架构，看似高可用，但是避免不了部分单点问题，因为有成本在，有时候不是非常需要某一部分高可用，设计上就比较简单。

在哪些场景中会存在单点？先来看一下一个典型互联网高可用架构。

典型互联网高可用架构：

（1）客户端层，这一层是浏览器或者APP，第一步先访问DNS-server，由域名拿到nginx的外网IP

（2）负载均衡层，nginx是整个服务端的入口，负责反向代理与负载均衡工作

（3）站点层，web-server层，典型的是tomcat或者apache

（4）服务层，service层，典型的是dubbo或者thrift等提供RPC调用的后端服务，或者微服务架构体系

（5）数据层，包含cache和db，典型的是主从复制读写分离的db架构

在这个互联网架构中，站点层、服务层、数据库的从库都可以通过冗余的方式来保证高可用

但是存在的问题：

（1）nginx层是一个潜在的单点
（2）数据库写库master也是一个潜在的单点

2 单点架构存在的问题

单点系统一般来说存在两个很大的问题：

（1）非高可用：既然是单点，master一旦发生故障，服务就会受到影响
（2）性能瓶颈：既然是单点，不具备良好的扩展性，服务性能总有一个上限，这个单点的性能上限往往就是整个系统的性能上限

接下来，就看看有什么优化手段可以优化上面提到的两个问题

3 shadow-master解决单点高可用问题

shadow-master是一种很常见的解决单点高可用问题的技术方案。

“影子master”，顾名思义，服务正常时，它只是单点master的一个影子，在master出现故障时，shadow-master会自动变成master，继续提供服务。

shadow-master它能够解决高可用的问题，并且故障的转移是自动的，不需要人工介入，但不足是它使服务资源的利用率降为了50%，业内经常使用keepalived+vip的方式实现这类单点的高可用。

对于mysql读写分离主master解决方法

（1）两个主库设置相互同步的双主模式

（2）平时只有一个主库提供服务，言下之意，shadow-master不会往master同步数据

（3）异常时，虚IP漂移到另一个主库，shadow-master变成主库继续提供服务

需要说明的是，由于数据库的特殊性，数据同步需要时延，如果数据还没有同步完成，流量就切到了shadow-master，可能引起小部分数据的不一致。

4 减少与单点的交互

减少与单点的交互是单点的系统优化的核心方向

既然知道单点存在性能上限，单点的性能有可能成为系统的瓶颈，那么，减少与单点的交互，便成了存在单点的系统优化的核心方向。

怎么来减少与单点的交互，这里提两种常见的方法。

4.1 批量写

分布式系统之所以难，很重要的原因之一是“没有一个全局时钟，难以保证绝对的时序”，要想保证绝对的时序，还是只能使用单点服务，用本地时钟保证“绝对时序”。数据库写压力大，是因为每次生成ID都访问了数据库，可以使用批量的方式降低数据库写压力。

数据库中只存储当前ID的最大值，例如0。ID生成服务假设每次批量拉取6个ID，服务访问数据库，将当前ID的最大值修改为5，这样应用访问ID生成服务索要ID，ID生成服务不需要每次访问数据库，就能依次派发0,1,2,3,4,5这些ID了，当ID发完后，再将ID的最大值修改为11，就能再次派发6,7,8,9,10,11这些ID了，于是数据库的压力就降低到原来的1/6了。

4.2 合理利用缓存

缓存也是一种降低与单点交互次数，提升系统整体性能的方法。

1、用户请求经过Nginx
2、Nginx检查是否有缓存，如果Nginx有缓存，直接响应用户数据
3、Nginx如果没有缓存，则将请求路由给后端Java服务
4、Java服务查询Redis缓存，如果有数据，则将数据直接响应给Nginx，并将数据存入缓存，Nginx将数据响应给用户
5、如果Redis没有缓存，则使用Java程序查询MySQL，并将数据存入到Reids，再将数据存入到Nginx中