后台服务架构高性能设计之道

比眉伴天荒 2024-04-08 10:09 114阅读 0赞

> “N 高 N 可”，高性能、高并发、高可用、高可靠、可扩展、可维护、可用性等是后台开发耳熟能详的词了，它们中有些词在大部分情况下表达相近意思。本序列文章旨在探讨和总结后台架构设计中常用的技术和方法，并归纳成一套方法论。

#### 前言 ####

本文主要探讨和总结服务架构设计中高性能的技术和方法，如下图的思维导图所示，左边部分主要偏向于编程应用，右边部分偏向于组件应用，文章将按图中的内容展开。

![b7560b754b6d034173afe678acab2f31.jpeg][]

高性能思维导图

#### 1 无锁化 ####

大多数情况下，多线程处理可以提高并发性能，但如果对共享资源的处理不当，严重的锁竞争也会导致性能的下降。面对这种情况，有些场景采用了无锁化设计，特别是在底层框架上。无锁化主要有两种实现，串行无锁和数据结构无锁。

1.1 串行无锁

无锁串行最简单的实现方式可能就是单线程模型了，如 redis/Nginx 都采用了这种方式。在网络编程模型中，常规的方式是主线程负责处理 I/O 事件，并将读到的数据压入队列，工作线程则从队列中取出数据进行处理，这种半同步/半异步模型需要对队列进行加锁，如下图所示：

![3241f0e5a239592f354981e48d015577.jpeg][]

单Reactor多线程模型

上图的模式可以改成无锁串行的形式，当 MainReactor accept 一个新连接之后从众多的 SubReactor 选取一个进行注册，通过创建一个 Channel 与 I/O 线程进行绑定，此后该连接的读写都在同一个线程执行，无需进行同步。

![302743e1c9b11ace59004bbf08091713.jpeg][]

主从Reactor职责链模型

1.2 结构无锁

利用硬件支持的原子操作可以实现无锁的数据结构，很多语言都提供 CAS 原子操作（如 go 中的 atomic 包和 C++11 中的 atomic 库），可以用于实现无锁队列。我们以一个简单的线程安全单链表的插入操作来看下无锁编程和普通加锁的区别。

template<typename T>
    struct Node
    {
        Node(const T &value) : data(value) { }
        T data;
        Node *next = nullptr;
    };

有锁链表 WithLockList：

template<typename T>
    class WithLockList
    {
        mutex mtx;
        Node<T> *head;
    public:
        void pushFront(const T &value)
        {
            auto *node = new Node<T>(value);
            lock_guard<mutex> lock(mtx); //①
            node->next = head;
            head = node;
        }
    };

无锁链表 LockFreeList：

template<typename T>
    class LockFreeList
    {
        atomic<Node<T> *> head;
    public:
        void pushFront(const T &value)
        {
            auto *node = new Node<T>(value);
            node->next = head.load();
            while(!head.compare_exchange_weak(node->next, node)); //②
        }
    };

从代码可以看出，在有锁版本中 ① 进行了加锁。在无锁版本中，② 使用了原子 CAS 操作 compare\_exchange\_weak，该函数如果存储成功则返回 true，同时为了防止伪失败（即原始值等于期望值时也不一定存储成功，主要发生在缺少单条比较交换指令的硬件机器上），通常将 CAS 放在循环中。

下面对有锁和无锁版本进行简单的性能比较，分别执行 1000,000 次 push 操作。测试代码如下：

int main()
    {
        const int SIZE = 1000000;
        //有锁测试
        auto start = chrono::steady_clock::now();
        WithLockList<int> wlList;
        for(int i = 0; i < SIZE; ++i)
        {
            wlList.pushFront(i);
        }
        auto end = chrono::steady_clock::now();
        chrono::duration<double, std::micro> micro = end - start;
        cout << "with lock list costs micro:" << micro.count() << endl;
    
        //无锁测试
        start = chrono::steady_clock::now();
        LockFreeList<int> lfList;
        for(int i = 0; i < SIZE; ++i)
        {
            lfList.pushFront(i);
        }
        end = chrono::steady_clock::now();
        micro = end - start;
        cout << "free lock list costs micro:" << micro.count() << endl;
    
        return 0;
    }

三次输出如下，可以看出无锁版本有锁版本性能高一些。with lock list costs micro:548118 free lock list costs micro:491570 with lock list costs micro:556037 free lock list costs micro:476045 with lock list costs micro:557451 free lock list costs micro:481470

#### 2 零拷贝 ####

这里的拷贝指的是数据在内核缓冲区和应用程序缓冲区直接的传输，并非指进程空间中的内存拷贝（当然这方面也可以实现零拷贝，如传引用和 C++中 move 操作）。现在假设我们有个服务，提供用户下载某个文件，当请求到来时，我们把服务器磁盘上的数据发送到网络中，这个流程伪代码如下：

filefd = open(...); //打开文件
    sockfd = socket(...); //打开socket
    buffer = new buffer(...); //创建buffer
    read(filefd, buffer); //从文件内容读到buffer中
    write(sockfd, buffer); //将buffer中的内容发送到网络

数据拷贝流程如下图：

![bbb8beb45ee533827c355e2ff1cabfe0.jpeg][]

普通读写

上图中绿色箭头表示 DMA copy，DMA（Direct Memory Access）即直接存储器存取，是一种快速传送数据的机制，指外部设备不通过 CPU 而直接与系统内存交换数据的接口技术。红色箭头表示 CPU copy。即使在有 DMA 技术的情况下还是存在 4 次拷贝，DMA copy 和 CPU copy 各 2 次。

2.1 内存映射

内存映射将用户空间的一段内存区域映射到内核空间，用户对这段内存区域的修改可以直接反映到内核空间，同样，内核空间对这段区域的修改也直接反映用户空间，简单来说就是用户空间共享这个内核缓冲区。

使用内存映射来改写后的伪代码如下：

filefd = open(...); //打开文件
    sockfd = socket(...); //打开socket
    buffer = mmap(filefd); //将文件映射到进程空间
    write(sockfd, buffer); //将buffer中的内容发送到网络

使用内存映射后数据拷贝流如下图所示：

![9c8c658950279af13e27d29a02780eb9.jpeg][]

内存映射

从图中可以看出，采用内存映射后数据拷贝减少为 3 次，不再经过应用程序直接将内核缓冲区中的数据拷贝到 Socket 缓冲区中。RocketMQ 为了消息存储高性能，就使用了内存映射机制，将存储文件分割成多个大小固定的文件，基于内存映射执行顺序写。

2.2 零拷贝

零拷贝就是一种避免 CPU 将数据从一块存储拷贝到另外一块存储，从而有效地提高数据传输效率的技术。Linux 内核 2.4 以后，支持带有 DMA 收集拷贝功能的传输，将内核页缓存中的数据直接打包发到网络上，伪代码如下：

filefd = open(...); //打开文件
    sockfd = socket(...); //打开socket
    sendfile(sockfd, filefd); //将文件内容发送到网络

使用零拷贝后流程如下图：

![fa2a4fdfbffdcc7d4b79ad0115e26d77.jpeg][]

零拷贝

零拷贝的步骤为：1）DMA 将数据拷贝到 DMA 引擎的内核缓冲区中；2）将数据的位置和长度的信息的描述符加到套接字缓冲区；3）DMA 引擎直接将数据从内核缓冲区传递到协议引擎；

可以看出，零拷贝并非真正的没有拷贝，还是有 2 次内核缓冲区的 DMA 拷贝，只是消除了内核缓冲区和用户缓冲区之间的 CPU 拷贝。Linux 中主要的零拷贝函数有 sendfile、splice、tee 等。下图是来住 IBM 官网上普通传输和零拷贝传输的性能对比，可以看出零拷贝比普通传输快了 3 倍左右，Kafka 也使用零拷贝技术。

![b5bd869cc365064145072c88571e21ad.jpeg][]

普通读写和零拷贝性能对比

#### 3 序列化 ####

当将数据写入文件、发送到网络、写入到存储时通常需要序列化（serialization）技术，从其读取时需要进行反序列化（deserialization），又称编码（encode）和解码（decode）。序列化作为传输数据的表示形式，与网络框架和通信协议是解耦的。如网络框架 taf 支持 jce、json 和自定义序列化，HTTP 协议支持 XML、JSON 和流媒体传输等。

序列化的方式很多，作为数据传输和存储的基础，如何选择合适的序列化方式尤其重要。

3.1 分类

通常而言，序列化技术可以大致分为以下三种类型：

*  **内置类型**：指编程语言内置支持的类型，如 java 的 java.io.Serializable。这种类型由于与语言绑定，不具有通用性，而且一般性能不佳，一般只在局部范围内使用。
 *  **文本类型**：一般是标准化的文本格式，如 XML、JSON。这种类型可读性较好，且支持跨平台，具有广泛的应用。主要缺点是比较臃肿，网络传输占用带宽大。
 *  **二进制类型**：采用二进制编码，数据组织更加紧凑，支持多语言和多平台。常见的有 Protocol Buffer/Thrift/MessagePack/FlatBuffer 等。

3.2 性能指标

[b7560b754b6d034173afe678acab2f31.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/9a3bf0ce9b9e4fe9abfb8f85f841d835.jpeg
[3241f0e5a239592f354981e48d015577.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/c326e0ed50034ceca333ed193ae8abf2.jpeg
[302743e1c9b11ace59004bbf08091713.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/96326d44aefd4433865b89957599636e.jpeg
[bbb8beb45ee533827c355e2ff1cabfe0.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/07f00ca02ead48598264e119ceff3780.jpeg
[9c8c658950279af13e27d29a02780eb9.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/d7f5801d1d2e45e885de41124ecf5197.jpeg
[fa2a4fdfbffdcc7d4b79ad0115e26d77.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/7572c4bf61f9431fb4bb3f1ad133f5a9.jpeg
[b5bd869cc365064145072c88571e21ad.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/e5c7b893016d4781ba7d86cd43e9702c.jpeg