【秒杀购物商城业务服务】「分布式架构服务」盘点中间件服务的高可用模式及集群技术的方案分析

秒杀购物商城业务服务-分布式架构介绍

• 基于 MySQL 数据库集群技术实现服务的高可用

• 基于 Tomcat 的集群负载机制实现 Tomcat 服务器的高可用

• 基于 Nginx 负载均衡机制实现负载均衡（介绍和配置）

• 基于 Redis 缓存服务实现数据缓存控制相关介绍和技术点分析

• 对未来的分布式技术架构扩展和延伸介绍（包含云原生部分）

基于 MySQL 数据库集群技术实现服务的高可用

高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用需要更加认证对待。

MySQL 高可用架构分类

• MySQL 实现高可用之 MMM

• MySQL 实现高可用之 MHA

• MySQL 实现高可用之主从架构

• MySQL 实现高可用之 Cluster 模式

MMM 的技术分析

MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。

MMM 的基础组件分析

• mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。因此，脚本需要在监管上运行。

• mmm_agentd：运行在每个 msql 服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。

• mmm_control：一个简单的脚本，提供管理 mmm_mond 进行的命令。

MMM 实现基本实现原理

MMM 提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟 ip，同时它还可以备份数据，实现两节点之间的数据同步等。

MySQL 本身没有提供 replication failover 的解决方案，通过 MMM 方案能实现服务器的故障转移，从而实现 mysql 的高可用。

MHA 简介

MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本 DeNA 公司的 youshimaton（现就职于 Facebook 公司）开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。

MHA 的基础组件

MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。

MHA Manager 可以单独部署在独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。

MHA 的实现原理

• MHA Node 运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。

MySQL 主从架构

此种架构，一般初创企业比较常用，也便于后面步步的扩展

此架构特点

1. 成本低，布署快速、方便

2. 读写分离

3. 还能通过及时增加从库来减少读库压力

4. 主库单点故障

5. 数据一致性问题（同步延迟造成）

MySQL Cluster 基本概念

MySQL Cluster 简单地讲是一种 MySQL 集群的技术，是由一组计算机构成，每台计算机可以存放一个或者多个节点，其中包括 MySQL 服务器，DNB Cluster 的数据节点，管理其他节点，以及专门的数据访问程序，这些节点组合在一起，就可以为应用提高可高性能、高可用性和可缩放性的 Cluster 数据管理；

基于 Tomcat 的集群负载机制实现 Tomcat 服务器的高可用

Tomcat 集群原理

通过 Nginx 负载均衡进行请求转发

Tomcat 集群能带来什么

• 提高服务的性能, 并发能力, 以及高可用性

• 提供项目架构的横向扩展能力

Tomcat 集群产生什么问题

• Session 登录信息存储以及读取的问题

• 服务器定时任务并发的问题

Tomcat 单服务体系架构

在这个架构图中，一层 Nginx，首先 Nginx 主要职责给 Tomcat 一层反向代理。

此外，Nginx 还可以 FTPServer 指定的目录再做一层目录转发，保证上传上去的图片实时可以通过 http 协议访问到。单服务架构先不用考虑集群碰到的各种问题

Tomcat 集群"简单版"

比如，我们的登录的时候登录了 A 服务器，session 信息存储到 A 服务器上了，假设我们使用的负载均衡策略是 ip hash，那么登录信息还可以从 A 服务器上访问，但是这个有可能造成某些服务器压力过大，某些服务器又没有什么压力，这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈，并且请求不够分散。

首先要解决 Session 共享的问题

这时候我们使用轮询或者最小连接负载均衡策略，就导致了，第一次访问 A 服务器，第二次可能访问到 B 服务器，这个时候存储在 A 服务器上的 session 信息在 B 服务器上读取不到。

典型负载均衡策略分析

打个比方，我们有轮询，权重，地址散列，地址散列又分为原 ip 地址散列 hash，目标 ip 地址散列 hash，最少连接，加权最少连接，还有继续升级的很多种策略

• 轮询：优点：实现简单，缺点：不考虑每台服务器处理能力

• 权重：优点：考虑了服务器处理能力的不同

• 地址散列：优点：能实现同一个用户访问同一个服务器

• 最少连接：优点：使集群中各个服务器负载更加均匀

• 加权最少连接：在最少连接的基础上，为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重，计算出来的值小的服务器优先被选择。

Session 管理-Session Sticky 粘滞会话：

对于同一个连接中的数据包，负载均衡会将其转发至后端固定的服务器进行处理。

解决了我们 session 共享的问题，但是它有什么缺点呢？

• 一台服务器运行的服务挂掉，或者重启，上面的 session 都没了

• 负载均衡器成了有状态的机器，为以后实现容灾造成了羁绊

Session 管理-Session 复制

就是每一个 Tomcat 都存储我们的 Session，不同的 tomcat 之间进行拷贝复制。

解决了我们 session 共享的问题，但是它有什么缺点呢？

• 应用服务器间带宽问题，因为需要不断同步 session 数据

• 大量用户在线时，服务器占用内存过多

Session 管理-基于 Cookie

主要用于我们将 session 会话如同 token 一般存储在我们的前端

解决了我们 session 共享的问题，但是它有什么缺点呢？

• cookie 的长度限制

• cookie 存于浏览器，安全性是一个问题

Session 管理-Session 服务器

就是通过一个专门管理 session 会话的管理器服务，进行集中化存储和管理 session

解决了我们 session 共享的问题，这种方案需要思考哪些问题呢？保证 session 服务器的可用性，session 服务器单点如何解决？

• 我们在写应用时需要做调整存储 session 的业务逻辑

• 打个比方，我们为了提高 session server 的可用性，可以继续给 session server 做集群

Tomcat 单机部署多应用

1. 解压 2 个 tomcat, 分别命名为 tomcatA 和 tomcatB

2. 分别设置 2 个 tomcat 的 URIEncoding, 将 tomcat 的 conf/server.xml 里的 port 修改为两个不同端口。

设置 tomcat 的环境变量

tomcatA 的环境变量和以往一样, 不做改变

设置 tomcat 的环境变量

sudo vim /ect/profile

在 profile 文件里新增

export CATALINA_BASE=/Users/tomcat/apache-tomcat-9.0.21export CATALINA_HOME=/Users/tomcat/apache-tomcat-9.0.21export TOMCAT_HOME=/Users/tomcat/apache-tomcat-9.0.21

export CATALINA_2_BASE=/Users/tomcat/tomcat2export CATALINA_2_HOME=/Users/tomcat/tomcat2export TOMCAT_2_HOME=/Users/tomcat/tomcat2

强制保存退出

继续配置 tomcatB 下的 catalina.sh 里的内容,

cd tomcat 目录，在 # OS specific support. $var must be set to either true or false.下加入。

sudo vi catalina.shexport CATALINA_BASE=$CATALINA_2_BASEexport CATALINA_HOME=$CATALINA_2_HOME

执行刷新环境变量

source /etc/profile

使环境变量生效, 执行

echo $CATALINA_2_BASE

如果有输出, 即环境变量已经生效

/Users/tomcat/tomcat2

分别进入两个 tomcat 下的 bin 目录启动 tomcat, 正常即可

配置 nginx

修改 host

sudo vim /etc/hosts

所谓 tomcat 集群，就是可以向外提供并行服务的多台机器，任何一台服务器宕机，其它服务器可以替代它向外提供服务，而不影响用户访问。

nginx 是一个常用的反向代理服务，可自定义模块，实现请求转发及负载均衡（根具体采用策略有关）。为了 tomcat 集群的高可用性，还需要实现 nginx 的双机热备。

一，如果仅是对外提供一个页面访问，不用区分单一用户（不区分每个访问 session，不涉及用户权限，用户资料等内容），仅仅配置 nginx 负载均衡策略即可。

nginx 负载均衡策略主要分一下四种：

1)、轮询（默认）每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器宕机，能自动剔除。

2)、ip_hash 每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器。

3)、fair 按后端服务器的响应时间来分配请求，响应时间短的优先分配。

4)、url_hash 按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，后端服务器为缓存时比较有效。

二，如果涉及到用户 session，做一些鉴权缓存、存放临时信息时，就必须做 tomcat 的 session 共享。

目前可参考到的 session 共享方式主要分为两种。

1）利用 tomcat 自带的组播机制，实现 session 复制。

对 tomcat 及应用的若干配置文件进行配置即可实现，网上有很多资料可参考。但这种方式些弊端，看过一些资料，不建议用 session 复制的方式。在实际使用过程中，也发现有存在 session 莫名失踪的现象。

2）利用第三方机制存储 session。

比较常见的是 tomcat 集成 memcached 服务器来存储 session。实际项目中，我们采用过利用 redis 实现 session 存储，redis 高效的存取性能为高效的访问提供了保障，但是目前 redis 的集群功能似乎没有发布，如何解决 redis 的单点故障需要研究。

小结：是否实现 session 共享与 nginx 的负载策略有很大关系。比如采用轮询策略，就必须实现 session 共享，因为客户端会访问到每台服务器；而如果采用 ip_hash 策略，就可以不用考虑 session 共享的问题了，但是 ip_hash 有些缺陷使它不能随便使用（如多台 pc 使用同一个外网 ip）。

最近发现一个 nginx 的粘连模块（类似 session 粘连），可以看做 nginx 的第 5 种均衡策略。它利用客户端 cookie，对其写入一个 route 参数，每次访问可以根据 route 的值，固定的访问一台服务器，解决的 session 共享的问题。

Nginx 是什么？

Nginx（发音同 engine x）是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个 BSD-like 协议下发行。由俄罗斯的程序设计师 Igor Sysoev(伊戈尔·西索夫)所开发，供俄国大型的入口网站及搜索引擎 Rambler(漫步者)（俄文：Рамблер）使用。其特点是占有内存少，并发能力强，事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用 nginx 网站用户有：新浪、网易、 腾讯等。

优点

1. 可运行 linux,并有 Windows 移植版。

2. 在高连接并发的情况下，Nginx 是 Apache 服务器不错的替代品 Nginx 在美国是做虚拟主机生意的老板们经常选择的软件平台之一。能够支持高达 50,000 个并发连接数的响应

负载均衡的功能

• 转发

• 故障移除

• 恢复添加

• 高可用 Ha

我们想要使用 Nginx 那么就必须满足上面的四个条件.我们配置负载均衡的目的是在于当用户访问我们的服务器的时候, 首先会通过 Nginx 服务器来决定转发到哪个 Tomcat 服务器上去给用户提供服务, 当然这个概率是我们通过权重来配置的. 经过 Nginx 指派之后, 我们就可以处理高并发的访问了, 这里就能达到负载均衡的目的.

Nginx 如何实现负载均衡

Nginx 的负载均衡是通过 upstream 来实现的，在 upstream 中指定若干个 server，格式如下：

myserver 就是通过 upstream 定义的一组负载均衡模板，其中：

在配置完 upstream 后，还要让客户端过来的请求反向代理到 myserver，格式如下：

完成了负载均衡的配置，但是在实际需求中除了上面的设置外，还会增加一些额外设置：

负载均衡策略设置请求上游服务器携带请求头信息 upstream 模块中其他参数设置

Nginx 的负载均衡策略有 5 种方式：

除以上 5 种，还有一种：least-connected — 下一个请求被分配到拥有最少活动连接数的服务器。

编辑 nginx 配置文件(例中为/usr/local/ngnix/conf/nginx.conf)，找到 http 结点，

配置案例

http {    upstream myapp1 {        server 192.168.1.103:8080;        server 192.168.1.104:8080;   }   server {        listen 80;        server_name  localhost;        location /webautotest/ {            proxy_buffering off;            proxy_pass http://myapp1;        }    }}

重新加载配置文件

[root@localhost nginx-1.10.0]# /usr/local/ngnix/sbin/nginx -s reload

默认的负载均衡配置

http {    upstream myapp1 {        server srv1.example.com;        server srv2.example.com;        server srv3.example.com;    }    server {        listen 80;        location / {            proxy_pass http://myapp1;        }    }}

最少连接负载均衡

• 另一个负载均衡原则为 least-connected。当一些请求花费较长时间来完成时，least-connected 更“公平”的控制应用程序实例上的负载。

• 配置了 least-connected 的负载均衡机制的情况下，nginx 会尽量不让负载繁忙的应用服务器上负载过多的请求，相反的，会把新的请求发送到比较不繁忙的服务器。

配置示例：

upstream myapp1 {        least_conn;        server srv1.example.com;        server srv2.example.com;        server srv3.example.com;}

会话持久性

注意，round-robin 或 least-connected 负载均衡下，每个后续的客户端可能被分发至不同服务器，不保证相同客户端的请求总是被发送到相同的服务器。

如果有必要把客户端绑定至特定服务器，则可使用 ip-hash 负载均衡机制。

ip-hash 机制

ip-hash 机制下，客户端 ip 地址被用作 hash key 来判断客户端请求应该发送到哪个服务器，这种方法保证了来自相同客户端的请求总是发送到相同服务器（如果服务器可用的话）

upstream myapp1 {    ip_hash;    server srv1.example.com;    server srv2.example.com;    server srv3.example.com;}

负载均衡权重

可通过配置服务器权重来影响负载均衡机制。上面的例子中，都未配置服务器权重，这意味着所有服务器都拥有相同的权重。针对 round-robin 负载机制，权重意味着更多或更少的请求传送至服务器---假设有足够的请求，且按统一方式处理请求，且足够快完成请求处理。

配置示例：

  upstream myapp1 {        server srv1.example.com weight=3;        server srv2.example.com;        server srv3.example.com;}

上例配置中，每发送至服务器实例的 5 个新的请求中，有 3 个发送到 srv1,1 个发送到 srv2,另 1 个发送到 srv3。

注：当前版本似乎只实现了 round-robin 机制下的权重设置

健康检测

• nginx 反向代理实现包含服务器健康检查。如果来自特定服务器的响应失败，报错，nginx 将标记该服务器为 failed，一段时间内尽量避免选择此服务器作为随后请求的分发服务器。

• max_fails 机制设置 fail_timeout 期间，和服务器沟通失败的连续重试次数，默认为 1.当设置为 0 时，不做服务器健康检测。fail_timeout 定义了服务器被标记为 failed 的时长。fail_timeout 时间间隔过后，nginx 将开始使用活动客户端请求来探测服务器，如果探测成功则标记服务器为活动服务器。

Nginx 负载均衡配置项介绍

下面我们将介绍一下 proxy 模块的参数：

各个参数介绍：

设置 proxy_connect_timeout 为 2 秒，缩短超时时间，使其不至于太慢。