分布式架构下，如何实现秒杀商城中间件服务的高可用性与集群技术方案？

本文共计1722个文字，预计阅读时间需要7分钟。

秒杀购物商城业务介绍 - 分布式架构介绍 + 基于MySQL数据库集群技术实现服务的高可用 + 基于Tomcat的集群负载机制实现Tomcat服务器的可用性 + 基于Nginx负载均衡机制实现负载均衡（介绍和配置）

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

• 基于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主从架构

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

此架构特点

成本低，布署快速、方便

读写分离

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

主库单点故障

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

MySQL Cluster基本概念

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

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

Tomcat集群原理

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

Tomcat集群能带来什么

• 提高服务的性能, 并发能力, 以及高可用性
• 提供项目架构的横向扩展能力

Tomcat集群产生什么问题

• Session登录信息存储以及读取的问题
• 服务器定时任务并发的问题

Tomcat 单服务体系架构

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

此外，Nginx还可以FTPServer指定的目录再做一层目录转发，保证上传上去的图片实时可以通过myapp1; } }}

重新加载配置文件

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

默认的负载均衡配置

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秒，缩短超时时间，使其不至于太慢。