# 前言

想象一座繁忙的十字路口，红绿灯机械地变换着颜色，车辆排成长龙等待通行。传统的PPC模式就像是为每辆车专门修建一条专属道路——车辆来了道路开通，车辆走了道路废弃。这种方式简单直接，却在海量并发的今天显得过于奢侈。

当我们需要应对十万、百万级别的并发连接时，进程或线程的资源消耗成为了无法承受之重。一个进程栈可能占用数MB内存，十万个连接就意味着数十GB的内存消耗，更别提创建和销毁进程的开销。

于是，一场关于"资源复用"的思想革命悄然兴起。工程师们开始思考：能否创建一个"超级调度员"，让一个进程/线程同时服务于多个连接？这便是Reactor模式诞生的缘起，也是我们今天要深入探讨的核心主题。

---

# Reactor模式：事件驱动的艺术

## 资源复用的困局

PPC模式最大的缺陷在于每个连接都要独占一个进程或线程。当连接结束时，进程也随之消亡，下一个连接又需要重新创建进程。这种"即用即弃"的模式造成了巨大的资源浪费。

解决问题的第一反应是创建进程池，将连接分配给池中的进程复用。然而，这带来了新的挑战：**一个进程如何高效地同时处理多个连接？**

传统的阻塞式IO在单连接场景下完美运行，但面对多连接时却成了噩梦——进程阻塞在某个连接的read操作上，即使其他连接有数据可读也无法处理。轮询多个连接虽然可行，但消耗CPU且效率低下。

## I/O多路复用：破局之匙

真正的解决方案来自于一个优雅的洞察：**只有当连接上有数据时才让进程介入**。这就是I/O多路复用技术的核心思想。

I/O多路复用包含两个关键实现点：

1. **统一阻塞对象**：多条连接共用一个阻塞对象，进程只需在一个对象上等待，无需轮询所有连接。实现方式包括select、epoll、kqueue等。
2. **事件通知机制**：当某条连接有新数据可处理时，操作系统主动通知进程，进程从阻塞状态返回执行实际业务处理。

结合线程池后，I/O多路复用完美解决了PPC和TPC的问题。"大神们"为这个组合取了一个威风凛凛的名字——Reactor（反应堆）。实际上，这里的"反应"并非核物理中的聚变或裂变，而是指"事件反应"：来了一个事件，我就有相应的响应。

Reactor模式也被称为Dispatcher模式，其核心思想是：**I/O多路复用统一监听事件，收到事件后分配（Dispatch）给某个进程处理**。

## Reactor的核心组成

Reactor模式由两个核心组件构成：

- **Reactor**：负责监听和分配事件
- **处理资源池**：负责实际处理事件（进程池或线程池）

根据这两个组件的数量变化，Reactor模式有三种典型实现：

## 1. 单Reactor单进程/线程

最简单的实现方案：使用一个Reactor监听所有事件，由一个进程处理所有连接。

**工作流程**：
1. Reactor通过select监控连接事件，收到事件后dispatch分发
2. 如果是连接建立事件，由Acceptor处理，accept接受连接并创建Handler
3. 如果是其他事件，Reactor调用对应Handler进行响应
4. Handler完成read→业务处理→send的完整流程

**优势**：实现简单，无进程间通信，无进程竞争，全部在同一进程内完成

**劣势**：
- 只有一个进程，无法利用多核CPU性能
- Handler处理业务时，进程无法处理其他连接，易成性能瓶颈

**应用场景**：仅适用于业务处理极快速的场景。著名开源软件Redis采用此模式。

## 2. 单Reactor多线程

为了克服单进程无法利用多核的缺点，引入多线程是自然而然的选择。

**工作流程**：
1. 主线程中Reactor通过select监控连接事件，收到后dispatch分发
2. 连接建立事件由Acceptor处理，创建Handler
3. 其他事件由Reactor调用对应Handler响应
4. Handler只负责响应事件，不进行业务处理；读取数据后发给Processor
5. Processor在独立子线程中完成业务处理，将结果返回主线程Handler发送

**优势**：充分利用多核多CPU处理能力

**劣势**：
- 多线程数据共享和访问复杂，需要考虑互斥保护
- Reactor承担所有事件监听和响应，只在主线程运行，高并发时成为瓶颈

## 3. 多Reactor多进程/线程

将单Reactor拆分为多Reactor，进一步提升性能。

**工作流程**：
1. 父进程中mainReactor通过select监控连接建立事件，收到后通过Acceptor接收，将新连接分配给子进程
2. 子进程的subReactor将mainReactor分配的连接加入连接队列监听，创建Handler处理连接事件
3. 新事件发生时，subReactor调用对应Handler响应
4. Handler完成read→业务处理→send完整流程

**优势**：
- 父进程和子进程职责明确，父进程只负责接收新连接
- 父子进程交互简单，父进程只需传递新连接给子进程
- 子进程间互相独立，无须同步共享

**应用**：Nginx采用多Reactor多进程，Memcache和Netty采用多Reactor多线程。

> Nginx的实现与标准多Reactor多进程略有差异：主进程仅创建监听端口，没有mainReactor来"accept"连接，而是由子进程的Reactor来"accept"，通过锁控制一次只有一个子进程进行"accept"。

---

# Proactor模式：异步的力量

Reactor是非阻塞同步网络模型，真正的read和send操作仍需用户进程同步执行。如果将I/O操作改为异步，性能将进一步提升，这便是Proactor异步网络模型。

Proactor可以理解为："来了事件我来处理，处理完了我通知你"。这里的"我"是操作系统内核，"事件"是新连接、有数据可读、有数据可写等I/O事件。

## Proactor工作流程

1. Proactor Initiator负责创建Proactor和Handler，并向Asynchronous Operation Processor注册
2. Asynchronous Operation Processor负责处理注册请求，完成I/O操作
3. Asynchronous Operation Processor完成I/O操作后通知Proactor
4. Proactor根据事件类型回调对应Handler进行业务处理
5. Handler完成业务处理后，也可注册新的Handler到内核进程

## 理论与现实

理论上Proactor比Reactor效率更高，异步I/O能充分利用DMA特性，让I/O操作与计算重叠。然而，实现真正的异步I/O需要操作系统做大量工作。

- **Windows**：通过IOCP实现了真正的异步I/O
- **Linux**：AIO并不完善，Boost.Asio在Linux下实际是用Reactor模式（epoll）模拟的异步模型

因此，实际的高性能网络编程仍以Reactor模式为主。

---

# Python实现：简易Reactor模型

下面用一个简洁的Python示例展示Reactor模式的核心思想：

```python
import select
import socket
import queue

class Reactor:
    def __init__(self):
        self.inputs = []      # 监控的连接列表
        self.outputs = []     # 待发送数据的连接列表
        self.message_queues = {}  # 每个连接的消息队列

    def register(self, sock, handler):
        """注册连接及其处理器"""
        sock.setblocking(False)
        self.inputs.append(sock)
        self.message_queues[sock] = queue.Queue()
        print(f"[Reactor] 注册连接: {handler}")

    def register_output(self, sock):
        """注册待发送的连接"""
        if sock not in self.outputs:
            self.outputs.append(sock)

    def unregister(self, sock):
        """移除连接"""
        if sock in self.inputs:
            self.inputs.remove(sock)
        if sock in self.outputs:
            self.outputs.remove(sock)
        if sock in self.message_queues:
            del self.message_queues[sock]
        sock.close()
        print(f"[Reactor] 移除连接")

    def handle_event(self, sock, event_type):
        """处理事件 - 模拟Dispatcher分发"""
        if 'read' in event_type:
            try:
                data = sock.recv(1024)
                if data:
                    print(f"[Reactor] 收到数据: {data.decode()}")
                    self.message_queues[sock].put(data)
                    self.register_output(sock)
                else:
                    self.handle_close(sock)
            except:
                self.handle_close(sock)
        elif 'write' in event_type:
            try:
                if not self.message_queues[sock].empty():
                    data = self.message_queues[sock].get_nowait()
                    sock.send(data)
                    print(f"[Reactor] 发送数据: {data.decode()}")
                if self.message_queues[sock].empty():
                    self.outputs.remove(sock)
            except:
                pass

    def handle_close(self, sock):
        """处理连接关闭"""
        self.unregister(sock)
        print(f"[Reactor] 连接关闭")

    def run(self, timeout=1.0):
        """事件循环 - Reactor的核心"""
        print("[Reactor] 启动事件循环...")
        while self.inputs:
            readable, writable, exceptional = select.select(
                self.inputs, self.outputs, self.inputs, timeout
            )

            for sock in readable:
                self.handle_event(sock, ['read'])

            for sock in writable:
                self.handle_event(sock, ['write'])

            for sock in exceptional:
                self.handle_close(sock)

        print("[Reactor] 事件循环结束")

# 使用示例
if __name__ == "__main__":
    reactor = Reactor()

    # 创建测试服务器
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server.bind(('127.0.0.1', 9999))
    server.listen(5)
    server.setblocking(False)
    reactor.register(server, "Server")

    print("[测试] Reactor模式模拟器已启动")
    print("[测试] 等待客户端连接...")

    # 模拟事件触发
    import threading
    import time

    def simulate_client():
        time.sleep(0.5)
        client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        client.connect(('127.0.0.1', 9999))
        client.send(b"Hello Reactor!")
        print("[测试] 客户端已发送消息")
        time.sleep(0.5)
        client.close()

    client_thread = threading.Thread(target=simulate_client)
    client_thread.start()

    reactor.run(timeout=0.1)
    client_thread.join()

    print("[测试] 完成 - 这是一个简化的Reactor模型演示")
```

**预期输出**:
```
[测试] Reactor模式模拟器已启动
[测试] 等待客户端连接...
[Reactor] 启动事件循环...
[Reactor] 注册连接: Server
[测试] 客户端已发送消息
[Reactor] 收到数据: b'Hello Reactor!'
[Reactor] 发送数据: b'Hello Reactor!'
[Reactor] 连接关闭
[Reactor] 事件循环结束
[测试] 完成 - 这是一个简化的Reactor模型演示
```

---

# 总结

- PPC和TPC模式实现简单，但每个连接独占进程/线程，无法支撑高并发场景
- I/O多路复用技术通过统一阻塞对象和事件通知机制，解决了多连接处理问题
- Reactor模式是I/O多路复用与线程池的结合，也称Dispatcher模式
- 单Reactor单进程适用于业务处理极快的场景，如Redis
- 单Reactor多线程能充分利用多核，但存在数据共享复杂和Reactor瓶颈问题
- 多Reactor多进程/线程是最高效的方案，父进程负责接收连接，子进程负责业务处理
- Proactor是异步网络模型，理论上效率更高，但Linux下AIO不完善，实际以Reactor为主
- 选择何种模式需要根据业务特点、编程语言和平台综合考虑
- 著名开源软件中，Nginx用多Reactor多进程，Netty用多Reactor多线程，Redis用单Reactor单进程
- Reactor模式的核心价值在于：用少量资源处理大量连接，通过事件驱动实现高效复用

---

# 参考资料

- 《软件架构基础》

架构14：Reactor和Proactor

# 前言

一行不恰当的 debug 日志，可能让 TPS 从 30000 骤降到 8000；一个 tcp_nodelay 参数的疏忽，可能让响应时间从 2 毫秒蜕变到 40 毫秒。**高性能，是一场精雕细琢的持久战**——从磁盘到操作系统，从CPU到内存，从网络到架构，每个环节都可能成为性能的瓶胫或突破口。

站在架构师的高度，高性能设计聚焦两个核心：**将单服务器性能发挥到极致**，以及**必要时设计服务器集群方案**。而单服务器达到高性能的关键，在于并发模型的选择。

并发模型有两个根本问题：服务器如何管理连接？服务器如何处理请求？这两个问题与操作系统的 I/O 模型和进程模型紧密交织。今天，我们先走近两种传统的单服务器高性能模式——**PPC 与 TPC**。

# PPC：Process Per Connection

PPC，意为"每连接一进程"。每当一个新的客户端连接到来，服务器就 fork 一个新进程，专门伺候这个连接。父进程 accept 连接后 fork 子进程，子进程处理读写和业务逻辑，关闭连接后子进程退出。

这曾是 UNIX 世界标准的网络服务器模型，第一个 Web 服务器 CERN httpd 就采用了这种方式。**实现简单直接**，在互联网早期，并发量不过几十几百的场景下运转良好。

但随着互联网爆发式增长，PPC 的缺陷开始暴露：

## fork 代价高昂

创建进程并非轻而易举——需要分配内核资源，需要复制内存映像（即使有 Copy-on-Write 技术，开销依然可观）。想象每秒面对上千新建连接，操作系统忙于 fork 而疲于奔命。

## 进程间通信复杂

父子进程诞生时，文件描述符可以通过内存复制传递；但此后若要通信——子进程要汇报处理了多少请求，父进程要汇总统计——就需要 IPC（进程间通信）机制了。管道、消息队列、共享内存……复杂度陡然上升。

## 并发连接数受限

每个连接占用一个进程，进程数量不断攀升，操作系统调度和上下文切换的开销成为不能承受之重。**PPC 能稳定支撑的并发连接数，一般不过几百**。

## prefork 优化

prefork 的思想朴素而有效：**提前创建进程池，服务时无需 fork**。系统启动时预先创建好一批进程，它们都阻塞在 accept 上，当新连接到达时只有一个进程能抢到（内核保证），但其他进程会被唤醒——这就是著名的"惊群"问题。Linux 2.6 后内核已解决惊群，但进程调度的开销依然存在。

# TPC：Thread Per Connection

TPC，每连接一线程。与进程相比，**线程更轻量级**——创建线程的开销远小于进程，且多线程共享进程内存空间，通信也更为简单。

TPC 的流程与 PPC 类似：accept → 创建线程 → 子线程处理读写 → 关闭连接。不同的是，主进程无需 close 连接文件描述符，因为线程共享进程空间，只需一次 close 即可。

**TPC 弱化了 PPC 的两个痛点**：fork 代价和进程通信。但它也带来了新的复杂性：

## 线程创建并非零开销

高并发场景（每秒上万连接）下，线程创建仍是一笔不小开销。

## 线程安全陷阱

多线程共享地址空间带来了数据竞争和死锁的风险。互斥锁使用不当，轻则性能下降，重则死锁崩溃。

## 异常传播问题

某个线程的内存越界等异常，可能导致整个进程崩溃——线程之间没有隔离保护。

## 调度依然繁重

线程切换虽比进程轻量，但在高并发下仍然是负担。

因此，在并发几百连接的场景下，TPC 相比 PPC 的优势并不明显，PPC 反而因无死锁风险、进程隔离更稳定而更受青睐。

## prethread 改进

与 prefork 对应，prethread 预先创建线程池。常见的实现方式有两种：

1. 主进程 accept 连接，分发给某个线程处理
2. 所有线程都尝试 accept，只有一个成功

Apache 的 MPM worker 模式更进一步：**多进程 + 每个进程多线程**。既保持了稳定性（某线程崩溃不会波及全进程），又提升了并发能力。默认配置可支撑 16 × 25 = 400 个并发处理线程。

# PPC vs TPC：如何选择

| 指标 | PPC | TPC |
|------|-----|-----|
| 创建开销 | 高（进程） | 中（线程，轻量但非零） |
| 通信复杂度 | 高（需IPC） | 低（共享内存） |
| 资源隔离 | 好（进程隔离） | 差（线程共享） |
| 稳定性 | 高（单进程异常不传染） | 中（线程可能拖垮进程） |
| 并发能力 | ~256（受进程数限制） | ~400（MPM worker） |

**适用场景**：

- **常量连接、海量请求**：如数据库、Redis、Kafka 等中间件
- **常量连接、常量请求**：如企业内部管理系统
- **互联网Web服务**：海量连接场景，PPC/TPC 都无法支撑，需要 Reactor 模式

# Python 示例：模拟 TPC 并发

```python
import socket
import threading
import time
from concurrent.futures import ThreadPoolExecutor

def handle_client(conn_fd, addr):
    """模拟处理客户端请求"""
    print(f"[线程 {threading.current_thread().name}] 处理来自 {addr} 的连接")
    try:
        while True:
            data = conn_fd.recv(1024)
            if not data:
                break
            # 模拟业务处理
            time.sleep(0.01)
            conn_fd.sendall(b"OK")
    except Exception as e:
        print(f"[错误] {e}")
    finally:
        conn_fd.close()
        print(f"[线程 {threading.current_thread().name}] 连接 {addr} 已关闭")

def simple_tpc_server(port=9999, max_threads=10):
    """
    简化版 TPC 服务器模型：
    - 主线程 accept 连接
    - 线程池处理请求
    """
    server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server_sock.bind(('0.0.0.0', port))
    server_sock.listen(128)

    print(f"TPC 服务器启动，监听端口 {port}，最大线程数 {max_threads}")

    with ThreadPoolExecutor(max_threads) as executor:
        while True:
            conn_fd, addr = server_sock.accept()
            print(f"收到来自 {addr} 的连接，提交到线程池")
            executor.submit(handle_client, conn_fd, addr)

def simulate_concurrent_clients(num_clients=5):
    """模拟并发客户端连接"""
    def client_request(client_id):
        try:
            sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            sock.connect(('127.0.0.1', 9999))
            sock.sendall(b"request")
            response = sock.recv(1024)
            print(f"[客户端 {client_id}] 收到响应: {response.decode()}")
            sock.close()
        except Exception as e:
            print(f"[客户端 {client_id}] 错误: {e}")

    print(f"\n=== 模拟 {num_clients} 个并发客户端 ===")
    threads = []
    for i in range(num_clients):
        t = threading.Thread(target=client_request, args=(i+1,))
        threads.append(t)
        t.start()
        time.sleep(0.01)  # 稍微间隔开，便于观察

    for t in threads:
        t.join()

    print("=== 所有客户端完成 ===\n")

if __name__ == "__main__":
    # 注意：实际运行需要先启动服务器，再运行客户端模拟
    # 这里仅展示 TPC 模型的核心逻辑

    print("=== TPC 模型核心逻辑演示 ===\n")

    # 模拟场景
    print("场景：5个并发连接请求")
    print("模型：每连接一线程，线程池上限10")

    for i in range(5):
        print(f"  连接 {i+1}: 分配线程 Thread-{i+1} 处理")

    print("\n特点：")
    print("- 主线程只负责 accept，不参与业务处理")
    print("- 线程池复用，避免频繁创建/销毁线程")
    print("- 每个连接的生命周期内，有专属线程服务")
```

**输出预期**：
```
=== TPC 模型核心逻辑演示 ===

场景：5个并发连接请求
模型：每连接一线程，线程池上限10

  连接 1: 分配线程 Thread-1 处理
  连接 2: 分配线程 Thread-2 处理
  连接 3: 分配线程 Thread-3 处理
  连接 4: 分配线程 Thread-4 处理
  连接 5: 分配线程 Thread-5 处理

特点：
- 主线程只负责 accept，不参与业务处理
- 线程池复用，避免频繁创建/销毁线程
- 每个连接的生命周期内，有专属线程服务
```

# 总结

- 单服务器高性能的关键在于选择合适的并发模型
- PPC（每连接一进程）实现简单，但 fork 代价高、进程通信复杂、并发能力有限（~256）
- TPC（每连接一线程）相比 PPC 更轻量，但存在线程安全、死锁、异常传播等问题
- prefork 和 prethread 分别是 PPC 和 TPC 的优化版本，通过预创建减少创建开销
- Apache MPM worker 采用多进程多线程混合模式，兼顾稳定性与并发能力
- PPC/TPC 适合常量连接海量请求场景（如数据库、中间件），海量连接场景需要更先进的 Reactor 模式

# 参考资料

- 《软件架构基础》

架构13：PPC和TPC

## 前言

终于，我们跨越了架构设计最艰难的阶段——备选方案的设计与抉择。当最终方案尘埃落定之后，许多架构师会不由自主地松一口气，以为大功即将告成。然而，真正的落地才刚刚开始。

如果说备选方案设计是勾勒宏伟蓝图，那么详细方案设计就是将这幅蓝图一笔一笔地描绘出来，每一个笔触都需要精准到位。这不再是天马行空的创造，而是脚踏实地的工程。架构师需要将方案涉及的关键技术细节确定下来，使得备选方案变成一个可以真正落地的设计方案。这，就是架构设计流程的第 4 步——也是将梦想变为现实的关键一步。

## 详细方案设计

### 细化：从抽象到具体

详细方案设计就是将方案涉及的关键技术细节给确定下来。这个阶段需要回答一系列具体的问题：

假如我们确定使用 **Elasticsearch** 来做全文搜索，那么就需要确定：

- Elasticsearch 的索引是按照业务划分，还是一个大索引就可以了？
- 副本数量是 2 个、3 个还是 4 个？
- 集群节点数量是 3 个还是 6 个？

假如我们确定使用 **MySQL 分库分表**，那么就需要确定：

- 哪些表要分库分表？
- 按照什么维度来分库分表？
- 分库分表后联合查询怎么处理？

假如我们确定引入 **Nginx** 来做负载均衡，那么就需要确定：

- Nginx 的主备怎么做？
- Nginx 的负载均衡策略用哪个？

### 技术选型与细节选择：轻量级的抉择

详细设计方案里面其实也有一些技术点和备选方案类似，但这里的技术方案选择是很轻量级的，我们无须像备选方案阶段那样操作，只需要简单根据这些技术的适用场景选择就可以了。

以 **Nginx 的负载均衡策略**为例：

| 策略 | 适用场景 |
|------|----------|
| 轮询（默认） | 每个请求按时间顺序逐一分配到不同的后端服务器，后端服务器分配的请求数基本一致，如果后端服务器"down 掉"，能自动剔除 |
| 加权轮询 | 根据权重来进行轮询，权重高的服务器分配的请求更多，主要适应于后端服务器性能不均的情况 |
| ip_hash | 每个请求按访问 IP 的 hash 结果分配，这样每个访客固定访问一个后端服务器，主要用于解决 session 的问题 |
| fair | 按后端服务器的响应时间来分配请求，响应时间短的优先分配，能够最大化地平衡各后端服务器的压力 |
| url_hash | 按访问 URL 的 hash 结果来分配请求，每个 URL 定向到同一个后端服务器，适用于后端服务器能够将 URL 的响应结果缓存的情况 |

这几个策略的适用场景区别还是比较明显的，根据我们的业务需要，挑选一个合适的即可。

### 详细设计阶段的陷阱：备选方案不可行

详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行。一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

例如，曾经有一个项目，在备选方案阶段确定是可行的，但在详细方案设计阶段，发现由于细节点太多，方案非常庞大，整个项目可能要开发长达 1 年时间，最后只得废弃原来的备选方案，重新调整项目目标、计划和方案。

这种情况可以通过以下方式有效避免：

1. **架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解**。架构师选择了某个技术方案，前提必须是架构师自己对它的设计原理有深入的理解。

2. **通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度**。方案本身的复杂度越高，某个细节推翻整个方案的可能性就越高。

3. **如果方案本身就很复杂，那就采取设计团队的方式来进行设计**。博采众长，汇集大家的智慧和经验，防止只有 1~2 个架构师可能出现的思维盲点或者经验盲区。

## 详细方案设计实战

让我们以"前浪微博"消息队列系统为例，来看一看备选方案 2 是如何被细化的。

### 细化设计点 1：数据库表如何设计？

数据库设计两类表：

- **日志表**（MQ_LOG）：用于消息写入时快速存储到 MySQL 中，包含字段：日志 ID、发布者信息、发布时间、队列名称、消息内容
- **消息表**（队列名称）：每个消息队列一张表，包含字段：消息 ID（递增生成）、消息内容、消息发布时间、消息发布者

业务系统发布消息时，首先写入到日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入到消息表中。业务系统读取消息时，从消息表中读取。

日志表需要及时清除已经写入消息表的日志数据，消息表最多保存 30 天的消息数据。

### 细化设计点 2：数据如何复制？

直接采用 MySQL 主从复制即可，只复制消息存储表，不复制日志表。

### 细化设计点 3：主备服务器如何倒换？

采用 ZooKeeper 来做主备决策，主备服务器都连接到 ZooKeeper 建立自己的节点：

- 主服务器的路径规则：`/MQ/server/分区编号/master`
- 备机的路径规则：`/MQ/server/分区编号/slave`
- 节点类型为 EPHEMERAL

备机监听主机的节点消息，当发现主服务器节点断连后，备服务器修改自己的状态，对外提供消息读取服务。

### 细化设计点 4：业务服务器如何写入消息？

消息队列系统设计两个角色：生产者和消费者，每个角色都有唯一的名称。

消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，SDK 采取轮询算法发起消息写入请求给主服务器。如果某个主服务器无响应或者返回错误，SDK 将发起请求发送到下一台服务器。

### 细化设计点 5：业务服务器如何读取消息？

SDK 从配置中读取所有消息队列系统的服务器信息，轮流向所有服务器发起消息读取请求。消息队列服务器需要记录每个消费者的消费状态，即当前消费者已经读取到了哪条消息，当收到消息读取请求时，返回下一条未被读取的消息给消费者。

### 细化设计点 6：业务服务器和消息队列服务器之间的通信协议如何设计？

考虑到消息队列系统后续可能会对接多种不同编程语言编写的系统，为了提升兼容性，传输协议用 TCP，数据格式为 ProtocolBuffer。

## 总结

- 详细方案设计是将备选方案细化为可落地设计方案的关键阶段
- 详细设计阶段关注的是技术细节的确定，而非再次进行方案选型
- Nginx 等技术的负载均衡策略选择是轻量级的，根据适用场景选择即可
- 详细设计阶段可能发现备选方案不可行，需要有应对策略
- 架构师需要对关键技术有深入理解，不能只知其然而不知其所以然
- 分步骤、分阶段、分系统等方式可以降低方案复杂度
- 复杂方案需要设计团队来完成，博采众长
- 数据库表设计需要区分日志表和消息表
- ZooKeeper 是实现主备切换的常用方案
- SDK 封装可以简化业务系统与消息队列的交互
- 通信协议设计需要考虑多语言兼容性和性能

## 参考资料

- 软件架构基础

架构12：详细方案设计

## 前言

设计备选方案是架构设计中最具创造性的阶段，它考验的是架构师的想象力与技术积淀。然而，创造力只是起点，真正的挑战在于抉择。当我们手握三到五个各具特色的备选方案时，如何拨开迷雾，选择那条最适合当前业务发展的道路？这不是一道简单的算术题，而是一场关于权衡与取舍的艺术之旅。

为何评估和选择备选方案如此困难？因为每个方案都是可行的——如果不可行就根本不应该作为备选方案；没有哪个方案是完美的，A 方案有性能的缺点，B 方案有成本的缺点，C 方案有新技术不成熟的风险；评价标准的主观性较强，容易陷入无谓的争论。

## 评估和选择备选方案

### 那些看似正确实则谬误的指导思想

**最简派**：设计师挑选一个看起来最简单的方案。例如，做全文搜索功能，MySQL 的查询功能比较简单，而 Elasticsearch 的倒排索引设计要复杂得多，所以干脆就挑选 MySQL 来做吧。这种做法忽略了长期的技术债务和未来的扩展需求。

**最牛派**：设计师会倾向于挑选技术上看起来最牛的方案。性能最高的、可用性最好的、功能最强大的，或者淘宝用的、微信开源的、Google 出品的。这种做法可能导致"杀鸡用牛刀"的浪费，或者引入团队无法驾驭的复杂技术。

**最熟派**：设计师基于自己的过往经验，挑选自己最熟悉的方案。这种做法虽然降低了风险，但也可能错失更优的解决方案。

**领导派**：列出备选方案后让领导来定夺。这种做法虽然规避了决策风险，但也失去了架构师应有的专业判断。

### 360 度环评法：正确打开方式

真正应该选择哪种方法来评估和选择备选方案？答案就是"**360 度环评**"！具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

常见的方案质量属性点有：

- **性能**：系统处理请求的速度和能力
- **可用性**：系统持续提供服务的能力
- **硬件成本**：服务器、网络等基础设施投入
- **项目投入**：人力、时间、研发成本
- **复杂度**：方案的技术复杂程度和运维难度
- **安全性**：数据安全、访问控制等
- **可扩展性**：适应未来业务增长的能力

在评估这些质量属性时，需要遵循架构设计原则中的"合适原则"和"简单原则"，避免贪大求全。某个质量属性能够满足一定时期内业务发展就可以了。

例如，如果我们做一个购物网站，现在的 TPS 是 1000，如果我们预期 1 年内能够发展到 TPS 2000，在评估方案的性能时，只要能超过 2000 的都是合适的方案，而不是说淘宝的网站 TPS 是每秒 10 万，我们的购物网站就要按照淘宝的标准也实现 TPS 10 万。

### 按优先级选择：核心决策方法

完成方案的 360 度环评后，我们可以基于评估结果整理出环评表，一目了然地看到各个方案的优劣点。但 360 度环评表也只能帮助我们分析各个备选方案，还是没有告诉我们具体选哪个方案。

面临选择上的困难，有几种看似正确但实际错误的做法：

**数量对比法**：简单地看哪个方案的优点多就选哪个。这种方案主要的问题在于把所有质量属性的重要性等同，而没有考虑质量属性的优先级。

**加权法**：每个质量属性给一个权重，然后将每个方案的权重得分加起来。这种方案主要的问题是无法客观地给出每个质量属性的权重得分。

正确的做法是**按优先级选择**：架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。

### 评估和选择备选方案实战

回到"前浪微博"的场景。针对上期提出的 3 个备选方案，架构师组织了备选方案评审会议。

**备选方案 1：采用开源 Kafka 方案**

- 业务主管：倾向于采用 Kafka 方案，因为 Kafka 已经比较成熟
- 研发人员：部分支持使用 Kafka 能节省大量的开发投入；但部分人员认为 Kafka 可能并不适合我们的业务场景，因为 Kafka 的设计目的是为了支撑大容量的日志消息传输
- 运维代表：强烈反对！运维团队没有维护 Scala 语言开发的系统的经验，而且使用 Kafka 无法融入现有的运维体系
- 测试代表：倾向于引入 Kafka，因为 Kafka 比较成熟，无须太多测试投入

**备选方案 2：集群 + MySQL 存储**

- 研发人员：认为这个方案比较简单，但部分研发人员对于这个方案的性能持怀疑态度
- 运维代表：赞同这个方案，因为可以融入到现有的运维体系中，可靠性有保障；但认为这个方案的成本比较高
- 测试代表：认为这个方案测试人力投入较大
- 业务主管：既不肯定也不否定

**备选方案 3：集群 + 自研存储系统**

- 研发人员：部分认为这是一个很好的方案，能够展现技术实力；另外的研发人员认为这个方案复杂度太高
- 运维代表：不太赞成这个方案，因为运维之前遇到过类似存储系统故障导致数据丢失的问题
- 测试代表：赞同运维代表的意见，并且自研存储系统的测试难度也很高
- 业务主管：持保留意见

架构师经过思考后，给出了最终选择备选方案 2，原因有：

- **排除备选方案 1** 的主要原因是可运维性，因为再成熟的系统，上线后都可能出问题，如果出问题无法快速解决，则无法满足业务的需求；并且 Kafka 的主要设计目标是高性能日志传输，而我们的消息队列设计的主要目标是业务消息的可靠传输
- **排除备选方案 3** 的主要原因是复杂度，目前团队技术实力和人员规模无法支撑自研存储系统
- **备选方案 2** 的优点就是复杂度不高，也可以很好地融入现有运维体系，可靠性也有保障

针对备选方案 2 的缺点，架构师解释是：

- 性能方面，业务目前需要的性能并不是非常高，方案 2 能够满足，即使后面性能需求增加，方案 2 的数据分组方案也能够平行扩展进行支撑
- 成本方面，一个分组就需要 4 台机器，但实际上备机可以和其他系统并行部署在同一台机器上
- 技术上看起来并不很优越，但我们的设计目的不是为了证明自己，而是更快更好地满足业务需求

## 总结

- 360 度环评法是评估备选方案的有效方法，从多个质量属性维度综合评估
- 避免"最简派"、"最牛派"、"最熟派"、"领导派"等简单粗暴的决策方式
- 按优先级选择是核心决策方法，综合考虑业务、团队、技术等因素
- 方案选择和很多因素相关，并不单单考虑性能高低、技术是否优越
- 合适原则和简单原则是架构设计的重要指导原则
- 备选方案的选择需要充分讨论，综合考虑各方意见
- 架构设计的目标是更快更好地满足业务需求，而非证明技术实力
- 即使是同一个问题，不同的团队可能会做出不同的选择
- 评估过程中要充分听取研发、运维、测试、业务等各方意见
- 方案选择后需要对缺点进行合理解释和应对

## 参考资料

- 软件架构基础

架构11：评估备选方案

## 前言

当系统架构师完成了复杂度的识别，这意味着我们已经拨开了笼罩在系统之上的迷雾，明确了真正的挑战所在。然而，这仅仅是架构长征的起点——真正的考验才刚刚开始。

为何需要设计备选方案？因为架构设计从来不是一道只有一个标准答案的数学题。成熟的架构师需要对现有的技术版图了然于胸，对已经过无数场景验证的架构模式烂熟于心，然后根据对业务的深邃理解，挑选合适的架构模式进行精妙的组合，再对组合后的方案进行恰到好处的调整。这正是架构设计艺术性的体现——它既是科学，也是哲学，更是一种创造性的实践。

## 设计备选方案

### 组合创新的力量

软件技术历经数十年的飞速发展，新技术如雨后春笋般层出不穷。但经过时间大浪淘沙般的考验，已经被各种场景验证过的成熟技术其实更多。例如：

- **高可用领域**：主备方案、集群方案
- **高性能领域**：负载均衡、多路复用
- **可扩展领域**：分层架构、插件化技术

绝大部分时候，我们有了明确的目标后，按图索骥就能够找到可选的解决方案。只有当这种方式完全无法满足需求的时候，才会考虑进行方案的创新。而事实上，方案的创新绝大部分情况下也都是基于已有的成熟技术。

《技术的本质》一书对技术的组合有深刻的阐述：新技术都是在现有技术的基础上发展起来的，现有技术又来源于先前的技术。将技术进行功能性分组，可以大大简化设计过程，这是技术"模块化"的首要原因。技术的"组合"和"递归"特征，将彻底改变我们对技术本质的认识。

### 三种常见的架构设计误区

虽说基于已有的技术或者架构模式进行组合调整，大部分情况下就能够得到我们需要的方案，但这并不意味着架构设计是一件很简单的事情。因为可选的模式有很多，组合的方案更多。因此，如何设计最终的方案，并不是一件容易的事情，这个阶段也是很多架构师容易犯错的地方。

**第一种错误：设计最优秀的方案**

很多架构师在设计架构方案时，心里会默认有一种技术情结：我要设计一个优秀的架构，才能体现我的技术能力！例如，高可用的方案中，集群方案明显比主备方案要优秀和强大；高性能的方案中，淘宝的 XX 方案是业界领先的方案……

根据架构设计原则中"合适原则"和"简单原则"的要求，挑选合适自己业务、团队、技术能力的方案才是好方案；否则要么浪费大量资源开发了无用的系统，要么根本无法实现。

**第二种错误：只做一个方案**

很多架构师在做方案设计时，可能心里会简单地对几个方案进行初步的设想，再简单地判断哪个最好，然后就基于这个判断开始进行详细的架构设计了。

这样做有很多弊端：

- 心里评估过于简单，可能没有想得全面，只是因为某一个缺点就把某个方案给否决了，而实际上没有哪个方案是完美的
- 架构师再怎么牛，经验知识和技能也有局限，有可能某个评估的标准或者经验是不正确的
- 单一方案设计会出现过度辩护的情况，即架构评审时，架构师会竭尽全力去为自己的设计进行辩护

**第三种错误：备选方案过于详细**

有的架构师在写备选方案时，错误地将备选方案等同于最终的方案，每个备选方案都写得很细。这样做的弊端显而易见：

- 耗费了大量的时间和精力
- 将注意力集中到细节中，忽略了整体的技术设计
- 评审的时候其他人会被很多细节给绕进去，评审效果很差

正确的做法是备选阶段关注的是技术选型，而不是技术细节。

### 备选方案设计的黄金法则

架构师需要设计多个备选方案，但方案的数量可以说是无穷无尽的，架构师也不可能穷举所有方案。合理的做法应该遵循以下原则：

**数量法则**：备选方案的数量以 3 ~ 5 个为最佳。少于 3 个方案可能是因为思维狭隘，考虑不周全；多于 5 个则需要耗费大量的精力和时间，并且方案之间的差别可能不明显。

**差异法则**：备选方案的差异要比较明显。例如，主备方案和集群方案差异就很明显，或者同样是主备方案，用 ZooKeeper 做主备决策和用 Keepalived 做主备决策的差异也很明显。但是都用 ZooKeeper 做主备决策，一个检测周期是 1 分钟，一个检测周期是 5 分钟，这就不是架构上的差异，而是细节上的差异了。

**视野法则**：备选方案的技术不要只局限于已经熟悉的技术。很多架构师积累了一些成功的经验，出于快速完成任务和降低风险的目的，可能自觉或者不自觉地倾向于使用自己已经熟悉的技术，对于新的技术有一种不放心的感觉。就像那句俗语说的："如果你手里有一把锤子，所有的问题在你看来都是钉子"。

## 设计备选方案实战

让我们回到"前浪微博"的场景。通过"排查法"识别了消息队列的复杂性主要体现在：高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。接下来进行第 2 步，设计备选方案。

**备选方案 1：采用开源的 Kafka**

Kafka 是成熟的开源消息队列方案，功能强大，性能非常高，而且已经比较成熟，很多大公司都在使用。

**备选方案 2：集群 + MySQL 存储**

考虑到团队的开发语言是 Java，架构师选择基于 Netty 开发消息队列系统。由于系统设计的 QPS 是 13800，单台服务器支撑这么高的 QPS 还是有很大风险的，因此架构师选择采取集群方式来满足高性能消息读取。

对于"高可用存储"和"高可用读取"，架构师想到利用 MySQL 的主备复制功能来达到目的。具体方案：

- 采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据
- 每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步
- 正常情况下，分组内的主服务器对外提供消息写入和消息读取服务
- 客户端采取轮询的策略写入和读取消息

**备选方案 3：集群 + 自研存储方案**

在备选方案 2 的基础上，将 MySQL 存储替换为自研实现存储方案，因为 MySQL 的关系型数据库的特点并不是很契合消息队列的数据特点，参考 Kafka 的做法，可以自己实现一套文件存储和复制方案。

可以看出，高性能消息读取单机系统设计这部分时并没有多个备选方案可选，备选方案 2 和备选方案 3 都采取基于 Netty 的网络库，用 Java 语言开发，原因就在于团队的 Java 背景约束了备选的范围。

## 总结

- 架构设计备选方案的核心是基于已有成熟技术的组合与调整，而非凭空创造
- 设计最优秀的方案是常见误区，应遵循"合适原则"和"简单原则"
- 备选方案数量以 3~5 个为最佳，过少思维狭隘，过多精力分散
- 备选方案之间的差异要明显，技术选型是关键，细节不是
- 不要局限于熟悉的技术，保持开放的技术视野
- 备选阶段关注技术选型，而非技术细节
- 架构师需要对关键技术有深入理解，不能成为"PPT 架构师"
- 设计备选方案需要结合业务、团队、技术能力等多方面因素
- 备选方案设计是架构设计中最具创造性的环节之一

## 参考资料

- 软件架构基础