高可用和高并发的详解

高可用：

            是分布式系统架构设计中必须考虑的因素之一，通常指的是减少系统不能提供服务的时间，而保持其服务的高度可用性。

高并发：

                也是分布式系统架构设计中必须考虑的因素之一，通常指的是系统可以并行处理很多请求。

1.如何提升系统的并发能力：

      

互联网分层架构

      

1.客户端：网页端或者手机，PC端。

2.nginx反向代理。

3.实现核心应用逻辑，返回 HTML

4.后端服务。

5.数据写入内存，缓存。

6.数据库主从库，读写分离。

客户端到反向代理的高可用

客户端到nginx的高可用，是通过 反向代理层的冗余 来实现的。以nginx为例子，一台提供正常的服务，一台保证高可用。常见的实践是 keepalived 存活探测。

双机高可用一般是通过虚拟IP（飘移IP）方法来实现的，基于Linux/Unix的IP别名技术。
双机高可用方法目前分为两种：
1）双机主从模式：即前端使用两台服务器，一台主服务器和一台热备服务器，正常情况下，主服务器绑定一个公网虚拟IP，提供负载均衡服务，热备服务器处于空闲状态；当主服务器发生故障时，热备服务器接管主服务器的公网虚拟IP，提供负载均衡服务；但是热备服务器在主机器不出现故障的时候，永远处于浪费状态，对于服务器不多的网站，该方案不经济实惠。

2）双机主主模式：即前端使用两台负载均衡服务器，互为主备，且都处于活动状态，同时各自绑定一个公网虚拟IP，提供负载均衡服务；当其中一台发生故障时，另一台接管发生故障服务器的公网虚拟IP（这时由非故障机器一台负担所有的请求）。这种方案，经济实惠，非常适合于当前架构环境。

反向代理到web应用层的高可用

自动故障转移：当 web-server 挂了的时候，nginx 能够探测到，会自动的进行故障转移，将流量自动迁移到其他的 web-server，整个过程由 nginx 自动完成，对调用方是透明的。

Web应用层到服务层的高可用

“服务连接池”会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。

自动故障转移：当 web-server 挂了的时候，nginx 能够探测到，会自动的进行故障转移，将流量自动迁移到其他的 web-server，整个过程由 nginx 自动完成，对调用方是透明的。

服务层到缓存层的高可用

缓存层的数据冗余又有几种方式：第一种是利用客户端的封装，service 对 cache 进行双读或者双写。

缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

以 redis 为例，redis 天然支持主从同步，redis 官方也有 sentinel 哨兵机制，来做 redis 的存活性检测。

主redis 配置文件不变动。

从redis 修改端口port

再slaveof备注这一行下

# slaveof <masterip> <masterport>

添加如下一行，设置从库链接的主库

slaveof 127.0.0.1 6379

sentinel哨兵的配置

修改哨兵的端口

sentinel monitor mymaster 127.0.0.1 6379 2

配置中的这一行表示 我们要监视的主的ip和端口，mymaster是主的名称，因为我们的主是127.0.0.1:6379,所以三个哨兵中的这个地方都不用修改。

然后所有的配置就ok了，本地测试环境貌似需要改动的地方不多。

服务层到数据库层的高可用

数据库层都会用到主从同步，读写分离。

下面又分读库高可用和写库高可用。也和之前的高可用差不多，用的冗余的方法。

读库高可用：建立一个写库，多个读库。（一个主库，多个从库，一主多从），由数据库连接池实现。

自动故障转移：当读库挂了的时候，db-connection-pool 能够探测到，会自动的进行故障转移，将流量自动迁移到其他的读库，整个过程由连接池自动完成，对调用方是透明的。

写库高可用：建立多个主库（双主同步），常见的实践是 keepalived 存活探测。

自动故障转移：当写库挂了的时候，keepalived 能够探测到，会自动的进行故障转移，将流量自动迁移到 shadow-db-master，由于使用的是相同的 virtual IP，这个切换过程对调用方是透明的。