Web 架构之高可用基础

引言

在当今数字化时代，Web应用的高可用性至关重要。用户期望随时随地都能流畅地访问网站和应用，任何服务中断都可能导致用户流失和业务损失。本文将深入探讨 Web架构高可用的几个基础方面，包括无状态服务设计、数据库读写分离以及服务冗余部署，并给出相关代码示例、问题解决思路，最后附上思维导图帮助大家梳理知识体系。

一、无状态服务设计（Session 托管至 Redis 集群）

1. 概念与原理

无状态服务是指服务的每一次请求都不依赖于之前的请求状态。在传统的 Web 应用中，用户的会话状态（Session）通常存储在服务器端，这使得服务器具有状态，不利于扩展和高可用。将 Session 托管至 Redis 集群可以解决这个问题，Redis 是一个高性能的键值存储数据库，集群模式可以提供高可用性和扩展性。

2. 代码示例（Python Flask 应用）

from flask import Flask, session
from flask_redis import FlaskRedisapp = Flask(__name__)
# 设置会话密钥，用于加密会话数据
app.secret_key = 'your_secret_key'
# 初始化 Redis 连接
redis_store = FlaskRedis(app)@app.route('/')
def index():# 从 Redis 中获取会话数据if 'counter' in session:session['counter'] = session.get('counter') + 1else:session['counter'] = 1# 将会话数据存储到 Redis 中redis_store.set(session.sid, str(session['counter']))return f"Hello! You have visited this page {session['counter']} times."if __name__ == '__main__':app.run(debug=True)

注释：

• FlaskRedis 是 Flask 的一个扩展，用于方便地与 Redis 进行交互。
• session.sid 是会话的唯一标识符，通过它可以在 Redis 中存储和获取会话数据。

3. 常见问题及解决办法

• 问题：Redis 集群故障导致会话数据丢失。
  • 解决办法：使用 Redis Sentinel 或 Redis Cluster 提供的高可用机制。Redis Sentinel 可以监控 Redis 节点的状态，当主节点故障时自动进行故障转移；Redis Cluster 则是一个分布式的 Redis 解决方案，具有自动分片和故障转移功能。
• 问题：会话数据过期时间设置不合理。
  • 解决办法：根据业务需求合理设置会话数据的过期时间。可以在 Redis 中使用 EXPIRE 命令为会话数据设置过期时间，避免占用过多的内存。

二、数据库读写分离（MySQL 主从 + ProxySQL 流量分发）

1. 概念与原理

数据库读写分离是指将数据库的读操作和写操作分离到不同的数据库节点上，以提高数据库的性能和可用性。MySQL 主从复制是实现读写分离的常用方法，主节点负责处理写操作，从节点负责处理读操作。ProxySQL 是一个开源的 MySQL 代理，用于分发数据库流量。

2. 配置示例

MySQL 主从复制配置

• 主节点配置（my.cnf）

[mysqld]
server-id = 1
log-bin = mysql-bin

• 从节点配置（my.cnf）

[mysqld]
server-id = 2
relay-log = mysql-relay-bin
read-only = 1

ProxySQL 配置

-- 添加 MySQL 主从节点
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (0, 'master_host', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, 'slave_host', 3306);-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*', 1, 1);
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (2, 1, '^INSERT|UPDATE|DELETE.*', 0, 1);-- 加载配置
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL QUERY RULES TO DISK;

注释：

• server-id 是 MySQL 节点的唯一标识符，用于区分不同的节点。
• log-bin 开启二进制日志，用于主从复制。
• read-only = 1 表示从节点只能处理读操作。

3. 常见问题及解决办法

• 问题：主从复制延迟。
  • 解决办法：优化数据库配置，如增加从节点的硬件资源、调整复制参数等。可以使用 SHOW SLAVE STATUS 命令查看主从复制的延迟情况。
• 问题：ProxySQL 配置错误导致流量分发异常。
  • 解决办法：仔细检查 ProxySQL 的配置文件，确保规则正确。可以使用 SHOW MYSQL QUERY RULES 命令查看当前的查询规则。

三、服务冗余部署（多 AZ + 健康检查自动剔除）

1. 概念与原理

服务冗余部署是指在多个可用区（AZ）中部署多个服务实例，以提高服务的可用性。健康检查是指定期检查服务实例的状态，当发现某个实例出现故障时，自动将其从负载均衡器中剔除，避免将请求分发到故障实例上。

2. 示例（使用 Nginx 作为负载均衡器）

http {upstream backend {# 定义多个服务实例server backend1.example.com;server backend2.example.com;server backend3.example.com;# 健康检查配置check interval=3000 rise=2 fall=3 timeout=1000 type=http;}server {listen 80;server_name example.com;location / {# 将请求转发到后端服务proxy_pass http://backend;}}
}

注释：

• upstream 块定义了后端服务的集群。
• check 指令用于配置健康检查，interval 表示检查间隔时间，rise 表示连续成功多少次认为实例健康，fall 表示连续失败多少次认为实例故障，timeout 表示检查超时时间。

3. 常见问题及解决办法

• 问题：健康检查误判导致正常实例被剔除。
  • 解决办法：调整健康检查的参数，如增加 rise 和 fall 的值，延长 timeout 时间，避免因网络波动等原因导致误判。
• 问题：负载均衡器故障导致服务不可用。
  • 解决办法：使用多个负载均衡器进行冗余部署，如使用 Keepalived 实现负载均衡器的高可用。

思维导图

结语

通过无状态服务设计、数据库读写分离和服务冗余部署等基础技术，可以显著提高 Web架构的高可用性。在实际应用中，需要根据具体的业务需求和场景选择合适的技术方案，并注意解决可能出现的问题。希望本文能为你构建高可用的 Web架构提供一些帮助。