服务架构性能优化方式与实践

服务架构性能优化方式与实践

主要内容转载自孙加亮的九大服务架构性能优化方式 与【工程】服务性能优化入门与实践指南

在后端场景中，服务是一种提供特定功能的模块或系统，通过 REST API、RPC 等方式对外提供接口。服务可以独立运行，也可以和其他服务共同协作，构成一个庞大的系统。常见的服务有鉴权服务、搜索服务、数据库服务、广告召回服务等。

服务是整个系统的重要组成部分，为前端应用和其他上游服务提供支持，必须保证稳定可靠。现代服务通常需要应对高并发的请求、处理大规模的数据。随着业务和架构复杂度的增加，性能问题也会随之出现。这不仅会影响用户体验，也可能影响整个系统的稳定性。因此，服务性能优化显得尤为重要。通过优化服务性能，一方面可以降低延迟，保障服务的高可用性，提升用户体验，另一方面可以减少 CPU、内存等硬件资源的消耗，节约成本。

在这篇文章中，我们将围绕「服务性能优化」展开讨论，从代码、系统、架构等层面，探索服务性能优化的最佳实践。

一、相关术语

衡量服务性能的指标

  • QPS（Query Per Second，每秒请求数）
  • 响应时间（Response Time，RT），它可以理解为服务器处理响应的耗时。
  • 延时 Latency：分成客户端和服务端两个视角，客户端即调用方，服务端即被调用方。客户端延时，表示调用方从发出请求到收到服务响应所需的时间。服务端延时，表示服务从收到请求到发出响应所需的时间。前者比后者多出两次网络传输、以及序列化 / 反序列化的时间。客户端延时通常有一个上界，这是因为客户端会设置超时时间。而服务端延时没有这样的上界，因为服务端无法感知客户端是否已经超时结束。显然，延时越低越好。
  • 吞吐量 Throughput：服务在一段时间内处理请求的能力，单位通常是 QPS (Queries Per Second) 或 TPS (Transactions Per Second)。QPS 指每秒钟能够处理多少个查询请求，常用于数据库、搜索引擎等场景。TPS 指每秒钟能够完成多少个事务或操作，通常用于交易系统、支付系统等场景。在保证稳定性的前提下，吞吐量越高越好。
  • 错误率 Error Rate：服务出现错误的请求数占总请求数的百分比。错误率直观展示了服务的稳定性，越低越好。
  • 资源使用率：运行服务的主机或容器上各种系统资源的使用率，包括 CPU、内存、磁盘和网络等。不同服务对于资源的需求不同，例如 CPU 密集型服务更注重 CPU 的使用率，内存密集型服务则更注重内存的使用率。资源使用率越高，说明服务的负载越大，可能导致服务响应变慢、稳定性降低。因此，各项资源使用率越低越好。某些场景下可以用 A 资源兑换 B 资源，比如某个定制版的 Golang 编译器通过优化内存管理模型，用冗余的内存来兑换 CPU，效果是 (CPU 50%, MEM 10%) → (CPU 30%, MEM 60%)。对于 CPU 密集型服务来说，这个内存到 CPU 的兑换比是很划算的。

SLO、SLA

SLO 和 SLA 也是服务性能优化中两个常见的概念：

  • SLO (Service Level Objective)：服务水平目标，通常是一个数值或范围，比如稳定性达到 99.9%，即 3 个 9，表示一年内的停机时间最多为 8 小时 45 分钟、一个月内的停机时间最多为 43.2 分钟。注意，「SLO 达到 3 个 9」和「错误率低于 0.1%」并不是等价的。
  • SLA (Service Level Agreement)：服务水平协议，是由服务提供方和服务使用方达成的一份协议，约定了服务提供方应该达到的最小服务水平，若达不到应有补偿。
  • SLO 是为了满足 SLA 而制定的。SLO 可以看作是 SLA 的内部指标，用于衡量服务是否符合 SLA 中约定的服务水平要求。

avg、pct50、pct99

当我们观测服务性能指标时，通常会查看一个统计值，比如所有请求的平均延时、集群中所有主机的平均 CPU 使用率等。

  • avg (平均值) 是所有数据的算术平均值，可以帮助我们快速了解服务性能的整体水平，但是不够准确，容易被异常值影响。
  • pct50 (中位数) 是位于所有数据最中间的一个值。和 avg 相比，pct50 更稳定，不易受异常值影响。适用于数据分布不均匀、有异常值或者极值的场景。
  • pct99 (百分位数) 是位于所有数据第 99% 位置的值，比如 100 个请求中的前 99 个请求，它们的延时都比 pct99 小，只有最后 1 个请求的延时比 pct99 大。pct99 可以帮助我们快速发现一些问题，比如存在大包体、慢查询等长尾请求，或者集群中有异常实例。
  • 类似的，还有 pct90、pct999 等指标。

总之，pct{n} 反映了数据的分布情况，有助于我们了解服务在极端情况下的性能表现。实际场景下，我们需要同时关注 avg、pct50、pct99 等指标，以获取更全面的性能数据。

基准测试、压力测试

基准测试 (Benchmarking) 是一种衡量系统性能的标准化方法。基准测试常用来验证性能优化效果：首先在系统上运行一系列测试程序，保存性能指标结果；然后在代码或硬件环境变化之后，再执行一次基准测试，以确定那些变化对性能的影响。

压力测试 (Stress Testing) 通过增加系统负载，测试系统在极端情况下的表现。压力测试可以帮助发现系统的性能瓶颈。常用的压测工具有 Apache JMeter、LoadRunner 等。

二、分析服务性能问题的工具

日志和监控

  • 收集数据：通过日志和监控记录服务运行过程中的信息。这些信息既要包含时间戳、接口名、IP 地址、请求延时等通用信息，也要包含服务内部的具体数据，如每个子步骤的执行耗时、请求传入的数据量级等。

    监控数据一般用 Metrics 框架来收集。一个知名的 Metrics 框架是 OpenTSDB。

    Metrics 框架提供了存储时序数据和对时序数据进行聚合查询的功能：

    • 时序数据：对于某一项数据，记录其在不同时间点的值。绘制出来是横轴为时刻、纵轴为值的折线图。
    • 聚合查询：支持多种聚合方式 (avg、sum、p99 等) 和多种查询条件。

    Metrics 框架提供了通用的 API，可以在应用程序中收集各种类型的指标，比如 counter、timer 等。Metrics 数据可以展示在 Grafana 看板中。

  • 展示数据：对收集到的日志和监控数据进行处理，可视化地展示其中的各项关键指标。常用的可视化工具是 Grafana。

    image-20230405210259360

    图片来源：Grafana Playground

  • 分析数据：观察指标的 avg、pct99 等分位数，分析是否有长尾请求或单点异常；观察指标随时间的变化情况，定位出现性能异常的时间；同时观察多项指标，发现指标之间的关联关系，比如某时刻请求量上涨，导致 CPU 利用率上涨，进而导致服务稳定性下降。

下面是几个分析数据的实际案例。

(1) 根据日志发现单点异常：

假设我们从服务集群上下载了一批请求日志：

1
2
3
4
5
6
192.168.0.1 - - [23/Sep/2021:14:45:32 +0800] "GET /api/v1/users?page=1&limit=20 HTTP/1.1" 200 3567 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36" 0.504
192.168.0.2 - - [23/Sep/2021:14:45:33 +0800] "POST /api/v1/login HTTP/1.1" 200 256 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36" 1.267
192.168.0.3 - - [23/Sep/2021:14:45:34 +0800] "DELETE /api/v1/user/123 HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36" 0.873
192.168.0.4 - - [23/Sep/2021:14:45:35 +0800] "PUT /api/v1/user/123 HTTP/1.1" 200 1343 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36" 0.901
192.168.0.5 - - [23/Sep/2021:14:45:36 +0800] "GET /api/v1/products?id=1234 HTTP/1.1" 200 4382 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36" 0.702
...

每行日志对应了一个请求，日志的第一列是处理该请求的服务主机 IP 地址，最后一列是处理该请求的耗时，单位是秒。我们可以这样统计每台主机处理请求耗时的 avg 指标：

1
2
3
4
5
6
7
awk '{ips[$1]++; total[$1]+=$NF} \
END {for (ip in ips) { \
        avg=total[ip]/ips[ip]; \
        n=ips[ip]; \
        printf("%-15s requests: %-5d avg_time: %.3fs\n", ip, ips[ip], avg); \
    } \
}' log.txt | sort -k3nr

以上命令执行后，会输出每个 IP 地址的请求数量和平均耗时，并按平均耗时从大到小排列。输出格式如下：

1
2
3
4
5
192.168.0.2    requests: 1011     avg_time: 2.267s
192.168.0.4    requests: 1103     avg_time: 0.901s
192.168.0.3    requests: 1021     avg_time: 0.873s
192.168.0.5    requests: 1007     avg_time: 0.702s
192.168.0.1    requests: 1097     avg_time: 0.504s

不难发现， 192.168.0.2 的平均耗时远大于其他主机。最简单的处理办法是重启或迁移它。

但上面从日志统计耗时的流程很繁琐。实际场景中，一般使用 Metrics 框架收集单个请求的耗时、每台主机的 CPU 利用率等指标，然后在 Grafana 中展示。

(2) 根据监控发现单点异常：

通过 Metrics 和 Grafana 可以更实时、更直观地发现单点异常。比如下图是一个服务单机 QPS 的 Grafana 看板，当有一条曲线远远高于 / 低于其他曲线时，说明对应的主机有单点异常。在这个场景下，很有可能是集群负载均衡器的问题。

image-20230405220119360

火焰图

火焰图是一种性能分析工具，它以可视化的方式展示系统中的函数调用层级和执行时长。

image-20230405224650600

图源：http://openresty.org/download/user-flamegraph.svg

火焰图是一张形如火炬的 SVG 图片。火焰图上的每个矩形代表了一个函数的执行过程，其宽度表示执行时间的长短。矩形从下向上表示函数的调用层次，底部是外层函数，顶部是被调用的函数。矩形颜色没有含义，只是为了便于区分。

显然，矩形的宽度越宽，该函数的执行时间就越长，表明该函数可能存在性能问题。我们需要寻找火焰图中最宽的矩形，针对性地优化代码。

生成火焰图时，首先需要使用 perf 或 DTrace 等命令，收集一份包含函数执行堆栈的数据报告。然后可以使用 Brendan Gregg 开发的 FlameGraph 或者 Google 开发的 pprof 等工具，根据收集到的数据生成火焰图。最后可以使用 d3-flame-graph 等工具，将静态的 SVG 文件转换成动态的 HTML 文件，以便深入分析。

img

图源：https://github.com/spiermar/d3-flame-graph

火焰图不仅可以用来分析 CPU 热点，也可以用来排查内存泄漏问题。这里需要使用某些内存分配追踪工具，记录内存的分配和释放情况，然后基于这些数据生成内存火焰图。内存火焰图的矩形块颜色是绿色的，每个矩形块的宽度表示该函数内部分配的字节数。

image-20230405231152705

图源：Memory Leak (and Growth) Flame Graphs - Brendan Gregg

最后介绍一下差分火焰图。差分火焰图可以对比不同时间段的两张火焰图的差异，以观察哪些函数的资源开销发生了变化。差分火焰图的形状和第二张火焰图相同，矩形块的颜色表示该函数资源开销 (占比) 的差异，红色代表增长，蓝色代表减少。

Differential Flame Graphs

图源：Differential Flame Graphs - Brendan Gregg

差分火焰图可以用来定量分析某项性能优化工作是否有效，比如优化了一个热点函数后，应该能从差分火焰图上看到该函数的 CPU 开销有显著减少。此外，差分火焰图也可以用来排查内存泄漏问题，比如在一台发生内存泄漏的机器上，每隔一段时间采集一份内存数据报告，然后生成内存差分火焰图，便可以很直观地看出增长的内存来自哪里。

Perf

Perf 是 Linux 操作系统中一个强大的性能分析工具，可以用来追踪 CPU、内存和 I/O 等方面的性能问题。它的原理是利用 Linux 内核提供的系统调用接口，跟踪和记录各种事件的性能数据，并输出到文本文件中。Perf 命令可以和火焰图工具结合使用 —— 前者收集数据，后者可视化展示。

使用 perf record 命令，将程序的 CPU 执行情况记录到 perf.data 文件中：

1
perf record -p {pid} sleep 30

上面的命令表示采集指定 pid 的进程，持续 30s。可能的输出：

1
2
3
4
5
$ ./perf record -p 59 sleep 30
Lowering default frequency rate from 4000 to 1000.
Please consider tweaking /proc/sys/kernel/perf_event_max_sample_rate.
[ perf record: Woken up 55 times to write data ]
[ perf record: Captured and wrote 21.482 MB perf.data (462814 samples) ]

使用 perf report 命令，可视化地查看和分析数据。默认加载当前目录的 perf.data 文件：

1
perf report

一个可能的数据样例如下，从中我们可以看到每个函数执行占用的 CPU 百分比：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Samples: 100K of event 'cycles:u'
# Event count (approx.): 1000000
#
# Overhead  Command      Shared Object                  Symbol
# ........  .......  .................  ..............................
#
    38.02%  my_prog  libfoo.so.1.2.3   /usr/lib64/libfoo.so.1.2.3
              9.21%  Foo::bar()
              8.08%  Foo::baz()
              7.12%  Foo::qux()
              6.61%  Foo::quux()
              4.48%  Annex::foo()
              2.22%  Annex::bar()
              0.30%  Annex::baz()
              0.01%  std::string::operator[](unsigned long)
              0.01%  std::operator+(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)
              0.01%  Annex::qux()

    24.41%  my_prog  libbar.so.4.5.6   /usr/lib64/libbar.so.4.5.6
             13.05%  Bar::foo()
              6.89%  Bar::bar()
              4.70%  Bar::baz()

加载数据后，按 / 可以搜索函数名，会从高到低展示不同线程中该函数的 CPU 占比。

一般来说，我们可以很快通过 perf report 或火焰图定位到哪个函数是热点。接下来需要在机器指令级别深入分析产生性能热点的原因。在某个函数名上回车，可以进入该函数，查看每条机器指令的执行开销。以下是一个可能的数据报告：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
------------------------------------------------
 Percent |   Source code & Disassembly of noploop
------------------------------------------------
         :   int main(int argc, char **argv)
         :   {
    0.00 :    8048484:       55                      push   %ebp
    0.00 :    8048485:       89 e5                   mov    %esp,%ebp
[...]
    0.00 :    8048530:       eb 0b                   jmp    804853d <main+0xb9>
         :                           count++;
   14.22 :    8048532:       8b 44 24 2c             mov    0x2c(%esp),%eax
    0.00 :    8048536:       83 c0 01                add    $0x1,%eax
   14.78 :    8048539:       89 44 24 2c             mov    %eax,0x2c(%esp)
         :           memcpy(&tv_end, &tv_now, sizeof(tv_now));
         :           tv_end.tv_sec += strtol(argv[1], NULL, 10);
         :           while (tv_now.tv_sec < tv_end.tv_sec ||
         :                  tv_now.tv_usec < tv_end.tv_usec) {
         :                   count = 0;
         :                   while (count < 100000000UL)
   14.78 :    804853d:       8b 44 24 2c             mov    0x2c(%esp),%eax
   56.23 :    8048541:       3d ff e0 f5 05          cmp    $0x5f5e0ff,%eax
    0.00 :    8048546:       76 ea                   jbe    8048532 <main+0xae>
[...]

从中可以看到，cmp 指令占用了大量的 CPU 时钟周期，原因是它位于一个循环体中。

下面是另一份数据报告，对应了一段「在哈希表中查找关键字」的代码：

1
2
3
4
5
6
7
8
9
 0.00 :    xor    %edx,%edx
 1.80 :    mov    $rdx,$r8
      :    _ZNKSt10_HashtableI1St4pair__equal_toI1ESt4hash_20_Default_
 0.03 :    mov    (%rcx),%rax
 0.03 :    mov    (%rax,%r8,8),%rax
18.60 :    test   %rax,%rax
 ...
14.78 :    cmp    0x8(%rbx),%r14
 ...

💡 上面的 _ZNKSt10_xxx 是一个 C++ 符号名。使用 c++filt 命令可以将其转换为人类可读的形式。

从中可以看出，访存指令的开销很大，这表明哈希表在查找过程中经常失败。对应的优化手段有调整哈希函数、改进哈希冲突解决策略等，以减少哈希表的 miss 率。

按照类似的思路，我们可以利用 Perf 命令，在指令级别分析某个函数成为性能热点的原因。比如：某指令在循环中被频繁执行、某指令涉及访存操作、某指令依赖某些暂不可用的数据 (如锁)、某指令本身是一个多周期指令等。针对不同的问题，需要采用不同的优化方案。

最后，Brandan Gregg 有一篇非常详细的 Perf 命令使用指南，涵盖了 CPU 统计、事件分析、内核跟踪等话题，配合火焰图，基本可以排查出任意性能问题。建议深入阅读原文，此处不再展开。

pprof

pprof 是 Golang 官方提供的性能分析工具，可以生成 CPU、内存等多种类型的 Profiling 数据，支持以可视化的方式展示。pprof 内置了火焰图、函数调用图、表格等多种展示方式。

对于 Golang 服务的性能优化，建议使用 pprof，或者 pkg/profile 等开源库。

三、腾讯实践案例（原文链接：九大服务架构性能优化方式）

最近做了一些服务性能优化，文章池服务平均耗时跟p99耗时都下降80%左右，事件底层页服务平均耗时下降50%多左右，主要优化项目中一些不合理设计，例如服务间使用json传输数据，监控上报处理逻辑在主流程中，重复数据每次都请求下游服务，多个耗时操作串行请求等，这些问题都对服务有着严重的性能影响。

在服务架构设计时通常可以使用一些中间件去提升服务性能，例如使用mysql，redis，kafka等，因为这些中间件有着很好的读写性能。除了使用中间件提升服务性能外，也可以通过探索它们通过什么样的底层设计实现的高性能，将这些设计应用到我们的服务架构中。

常用的性能优化方法可以分为以下几种：

性能优化方式：

缓存

性能优化，缓存为王，所以开始先介绍一下缓存。缓存在我们的架构设计中无处不在的，常规请求是浏览器发起请求，请求服务端服务，服务端服务再查询数据库中的数据，每次读取数据都会至少需要两次网络I/O，性能会差一些，我们可以在整个流程中增加缓存来提升性能。首先是浏览器测，可以通过Expires、Cache-Control、Last-Modified、Etag等相关字段来控制浏览器是否使用本地缓存。

其次我们可以在服务端服务使用本地缓存或者一些中间件来缓存数据，例如redis。redis之所以这么快，主要因为数据存储在内存中，不需要读取磁盘，因为内存读取速度通常是磁盘的数百倍甚至更多；

然后在数据库测，通常使用的是mysql，mysql的数据存储到磁盘上，但是mysql为了提升读写性能，会利用bufferpool缓存数据页。mysql读取时会按照页的粒度将数据页读取到bufferpool中，bufferpool中的数据页使用LRU算法淘汰长期没有用到的页面，缓存最近访问的数据页。

Image

此外小到cpu的l1、l2、l3级cache，大到浏览器缓存都是为了提高性能，缓存也是进行服务性能优化的重要手段，使用缓存时需要考虑以下几点。

使用什么样的缓存

使用缓存时可以使用redis或者机器内存来缓存数据，使用redis的好处可以保证不同机器读取数据的一致性，但是读取redis会增加一次I/O，使用内存缓存数据时可能会出现读取数据不一致，但是读取性能好。例如文章的阅读数数据，如果使用机器内存作为缓存，容易出现不同机器上缓存数据的不一致，用户不同刷次会请求到不同服务端机器，读取的阅读数不一致，可能会出现阅读数变小的情况，用户体验不好。对于阅读数这种经常变更的数据比较适合使用redis来统一缓存。

也可以将两者结合提升服务的性能,例如在内容池服务，利用redis跟机器内存缓存热点文章详情，优先读取机器内存中的数据，数据不存在的时候会读取redis中的缓存数据，当redis中的数据也不存在的时候，会读取下游持久化存储中的全量数据。其中内存级缓存过期时间为15s，在数据变更的时候不保证数据一致性，通过数据自然过期来保证最终一致性。redis中缓存数据需要保证与持久化存储中数据一致性，如何保证一致性在后续讲解。可以根据自己的业务场景可以选择合适的缓存方案。

使用缓存时可以使用redis或者机器内存来缓存数据，使用redis的好处可以保证不同机器读取数据的一致性，但是读取redis会增加一次I/O，使用内存缓存数据时可能会出现读取数据不一致，但是读取性能好。例如文章的阅读数数据，如果使用机器内存作为缓存，容易出现不同机器上缓存数据的不一致，用户不同刷次会请求到不同服务端机器，读取的阅读数不一致，可能会出现阅读数变小的情况，用户体验不好。对于阅读数这种经常变更的数据比较适合使用redis来统一缓存。

也可以将两者结合提升服务的性能,例如在内容池服务，利用redis跟机器内存缓存热点文章详情，优先读取机器内存中的数据，数据不存在的时候会读取redis中的缓存数据，当redis中的数据也不存在的时候，会读取下游持久化存储中的全量数据。其中内存级缓存过期时间为15s，在数据变更的时候不保证数据一致性，通过数据自然过期来保证最终一致性。redis中缓存数据需要保证与持久化存储中数据一致性，如何保证一致性在后续讲解。可以根据自己的业务场景可以选择合适的缓存方案。

Image

缓存常见问题

1、缓存雪崩：缓存雪崩是指缓存中的大量数据同时失效或者过期，导致大量的请求直接读取到下游数据库，导致数据库瞬时压力过大，通常的解决方案是将缓存数据设置的过期时间随机化。在事件服务中就是利用固定过期时间+随机值的方式进行文章的淘汰，避免缓存雪崩。

2、 缓存穿透：缓存穿透是指读取下游不存在的数据，导致缓存命中不了，每次都请求下游数据库。这种情况通常会出现在线上异常流量攻击或者下游数据被删除的状况，针对缓存穿透可以使用布隆过滤器对不存在的数据进行过滤，或者在读取下游数据不存在的情况，可以在缓存中设置空值，防止不断的穿透。事件服务可能会出现查询文章被删除的情况，就是利用设置空值的方法防止被删除数据的请求不断穿透到下游。

3、 缓存击穿: 缓存击穿是指某个热点数据在缓存中被删除或者过期，导致大量的热点请求同时请求数据库。解决方案可以对于热点数据设置较长的过期时间或者利用分布式锁避免多个相同请求同时访问下游服务。在新闻业务中，对于热点新闻经常会出现这种情况，事件服务利用golang的singlefilght保证同一篇文章请求在同一时刻只有一个会请求到下游，防止缓存击穿。

4、热点key: 热点key是指缓存中被频繁访问的key，导致缓存该key的分片或者redis访问量过高。可以将可热点key分散存储到多个key上，例如将热点key+序列号的方式存储，不同key存储的值都是相同的，在访问时随机访问一个key，分散原来单key分片的压力；此外还可以将key缓存到机器内存中，避免redis单节点压力过大，在新闻业务中，对于热点文章就是采用这种方式，将热点文章存储到机器内存中，避免存储热点文章redis单分片请求量过大。

1
key val    =>  key1 val 、  key2 val、  key3 val 、 key4 val
缓存淘汰

缓存的大小是有限的，因为需要对缓存中数据进行淘汰，通常可以采用随机、LRU或者LFU算法等淘汰数据。LRU是一种最常用的置换算法，淘汰最近最久未使用的数据，底层可以利用map+双端队列的数据结构实现。

Image

最原生的LRU算法是存在一些问题的，不知道大家在使用过有没有遇到过问题。首先需要注意的是在数据结构中有互斥锁，因为golang对于map的读写会产生panic，导致服务异常。使用互斥锁之后会导致整个缓存性能变差，可以采用分片的思想，将整个LRUCache分为多个，每次读取时读取其中一个cache片，降低锁的粒度来提升性能，常见的本地缓存包通常就利用这种方式实现的。

1
2
3
4
5
6
7
8
9
10
11
type LRUCache struct {
    sync.Mutex
    size int     
    capacity int
    cache map[int]*DLinkNode
    head, tail *DLinkNode
}
type DLinkNode struct {
    key,value int
    pre, next *DLinkNode
}

mysql也会利用LRU算法对buffer pool中的数据页进行淘汰。由于mysql存在预读，在读取磁盘时并不是按需读取，而是按照整个数据页的粒度进行读取，一个数据页会存储多条数据，除了读取当前数据页，可能也会将接下来可能用到的相邻数据页提前缓存到bufferpool中，如果下次读取的数据在缓存中，直接读取内存即可,不需要读取磁盘，但是如果预读的数据页一直没有被访问，那就会存在预读失效的情况，淘汰原来使用到的数据页。mysql将buffer pool中的链表分为两部分，一段是新生代，一段是老生代，新老生代的默认比是7:3，数据页被预读的时候会先加到老生代中，当数据页被访问时才会加载到新生代中，这样就可以防止预读的数据页没有被使用反而淘汰热点数据页。此外mysql通常会存在扫描表的请求，会顺序请求大量的数据加载到缓存中，然后将原本缓存中所有热点数据页淘汰，这个问题通常被称为缓冲池污染，mysql中的数据页需要在老生代停留时间超过配置时间才会老生代移动到新生代时来解决缓存池污染。

Image

redis中也会利用LRU进行淘汰过期的数据，如果redis将缓存数据都通过一个大的链表进行管理，在每次读写时将最新访问的数据移动到链表队头，那样会严重影响redis的读写性能,此外会增加额外的存储空间，降低整体存储数量。redis是对缓存中的对象增加一个最后访问时间的字段，在对对象进行淘汰的时候，会采用随机采样的方案，随机取5个值，淘汰最近访问时间最久的一个，这样就可以避免每次都移动节点。但是LRU也会存在缓存污染的情况，一次读取大量数据会淘汰热点数据，因此redis可以选择利用LFU进行淘汰数据，是将原来的访问时间字段变更为最近访问时间+访问次数的一个字段，这里需要注意的是访问次数并不是单纯的次数累加，而是根据最近访问时间跟当前时间的差值进行时间衰减的，简单说也就是访问越久以及访问次数越少计算得到的值也越小，越容易被淘汰。

1
2
3
4
5
6
7
8
9
typedef struct redisObject {
 unsigned type:4;
 unsigned encoding:4;
 unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
 * LFU data (least significant 8 bits frequency
 * and most significant 16 bits access time). */
 int refcount;
 void *ptr;
} obj ;

可以看出不同中间件对于传统的LRU淘汰策略都进行了一定优化来保证服务性能，我们也可以参考不同的优化策略在自己的服务中进行缓存key的淘汰。

缓存数据一致性

当数据库中的数据变更时，如何保证缓存跟数据库中的数据一致，通常有以下几种方案：更新缓存再更新DB，更新DB再更新缓存，先更新DB再删除缓存，删除缓存再更新DB。这几种方案都有可能会出现缓存跟数据库中的数据不一致的情况，最常用的还是更新DB再删除缓存，因为这种方案导致数据不一致的概率最小，但是也依然会存在数据不一致的问题。例如在T1时缓存中无数据，数据库中数据为100，线程B查询缓存没有查询到数据，读取到数据库的数据100然后去更新缓存，但是此时线程A将数据库中的数据更新为99，然后在T4时刻删除缓存中的数据，但是此时缓存中还没有数据，在T5的时候线程B才更新缓存数据为100，这时候就会导致缓存跟数据库中的数据不一致。

Image

为保证缓存与数据库数据的一致性。常用的解决方案有两种，一种是延时双删，先删除缓存，后续更新数据库，休眠一会再删除缓存。文章池服务中就是利用这种方案保证数据一致性，如何实现延迟删除，是通过go语言中channel实现简单延时队列，没有引入第三方的消息队列，主要为了防止服务的复杂化；另外一种可以订阅DB的变更binlog，数据更新时只更新DB，通过消费DB的binlog日志，解析变更操作进行缓存变更，更新失败时不进行消息的提交，通过消息队列的重试机制实现最终一致性。

Image

并行化处理

redis在版本6.0之前都是号称单线程模型，主要是利用epllo管理用户海量连接，使用一个线程通过事件循环来处理用户的请求，优点是避免了线程切换和锁的竞争，以及实现简单，但是缺点也比较明显，不能有效的利用cpu的多核资源。随着数据量和并发量的越来越大，I/O成了redis的性能瓶颈点，因此在6.0版本引入了多线程模型。redis的多线程将处理过程最耗时的sockect的读取跟解析写入由多个I/O 并发完成，对于命令的执行过程仍然由单线程完成。

Image

mysql的主从同步过程从数据库通过I/Othread读取住主库的binlog，将日志写入到relay log中，然后由sqlthread执行relaylog进行数据的同步。其中sqlthread就是由多个线程并发执行加快数据的同步，防止主从同步延迟。sqlthread多线程化也经历了多个版本迭代，按表维度分发到同一个线程进行数据同步，再到按行维度分发到同一个线程。

Image

小到线程的并发处理，大到redis的集群，以及kafka的分topic分区都是通过多个client并行处理提高服务的读写性能。在我们的服务设计中可以通过创建多个容器对外服务提高服务的吞吐量，服务内部可以将多个串行的I/O操作改为并行处理，缩短接口的响应时长，提升用户体验。对于I/O存在相互依赖的情况，可以进行多阶段分批并行化处理，另外一种常见的方案就是利用DAG加速执行，但是需要注意的是DAG会存在开发维护成本较高的情况，需要根据自己的业务场景选择合适的方案。并行化也不是只有好处没有坏处的，并行化有可能会导致读扩散严重，以及线程切换频繁存在一定的性能影响。

批量化处理

kafka的消息发送并不是直接写入到broker中的，发送过程是将发送到同一个topic同一个分区的消息通过main函数的partitioner组件发送到同一个队列中，由sender线程不断拉取队列中消息批量发送到broker中。利用批量发送消息处理，节省大量的网络开销，提高发送效率。

Image

redis的持久化方式有RDB跟AOF两种，其中AOF在执行命令写入内存后，会写入到AOF缓冲区，可以选择合适的时机将AOF缓冲区中的数据写入到磁盘中，刷新到磁盘的时间通过参数appendfsync控制，有三个值always、everysec、no。其中always会在每次命令执行完都会刷新到磁盘来保证数据的可靠性；everysec是每秒批量写入到磁盘，no是不进行同步操作，由操作系统决定刷新到写回磁盘，当redis异常退出时存在丢数据的风险。AOF命令刷新到磁盘的时机会影响redis服务写入性能，通常配置为everysec批量写入到磁盘，来平衡写入性能和数据可靠性。

Image

我们读取下游服务或者数据库的时候，可以一次多查询几条数据，节省网络I/O;读取redis的还可以利用pipeline或者lua脚本处理多条命令，提升读写性能；前端请求js文件或者小图片时，可以将多个js文件或者图片合并到一起返回，减少前端的连接数，提升传输性能。同样需要注意的是批量处理多条数据，有可能会降低吞吐量，以及本身下游就不支持过多的批量数据，此时可以将多条数据分批并发请求。对于事件底层页服务中不同组件下配置的不同文章id，会统一批量请求下游内容服务获取文章详情，对于批量的条数也会做限制，防止单批数据量过大。

数据压缩合并

redis的AOF重写是利用bgrewriteaof命令进行AOF文件重写，因为AOF是追加写日志，对于同一个key可能存在多条修改修改命令，导致AOF文件过大，redis重启后加载AOF文件会变得缓慢，导致启动时间过长。可以利用重写命令将对于同一个key的修改只保存一条记录，减小AOF文件体积。

Image

大数据领域的Hbase、cassandra等nosql数据库写入性能都很高，它们的底层存储数据结构就是LSM树(log structured merge tree),这种数据结构的核心思想是追加写，积攒一定的数据后合并成更大的segement，对于数据的删除也只是增加一条删除记录。同样对一个key的修改记录也有多条。这种存储结构的优点是写入性能高，但是缺点也比较明显，数据存在冗余和文件体积大。主要通过线程进行段合并将多个小文件合并成更大的文件来减少存储文件体积，提升查询效率。

Image

对于kafka进行传输数据时，在生产者端和消费者端可以开启数据压缩。生产者端压缩数据后，消费者端收到消息会自动解压，可以有效减小在磁盘的存储空间和网络传输时的带宽消耗，从而降低成本和提升传输效率。需要注意生产者端和消费者端指定相同的压缩算法。

在降本增效的浪潮中，降低redis成本的一种方式，就是对存储到redis中的数据进行压缩，降低存储成本,重构后的内容微服务通过持久化存储全量数据，采用snappy压缩，压缩后只是原来数据的40%-50%；还有一种方式是将服务之间的调用从http的json改为trpc的pb协议，因为pb协议编码后的数据更小，提升传输效率，在服务优化时，将原来请求tab的协议从json转成pb，降低几毫秒的时延，此外内容微服务存储的数据采用flutbuffer编码，相比较于protobuffer有着更高的压缩比跟更快的编解码速度；对于JS/CSS多个文件下发也可以进行混淆和压缩传递；对于存储在es中的数据也可以手动调用api进行段合并，减小存储数据的体积，提高查询速度；在我们工作中还有一个比较常见的问题是接口返回的冗余数据特别多，一个接口服务下发的数据大而全，而不是对于当前场景做定制化下发，不满足接口最小化原则，白白浪费了很多带宽资源和降低传输效率。

无锁化

redis通过单线程避免了锁的竞争，避免了线程之间频繁切换才有这很好的读写性能。

go语言中提供了atomic包，主要用于不同线程之间的数据同步，不需要加锁，本质上就是封装了底层cpu提供的原子操作指令。此外go语言最开始的调度模型时GM模型，所有的内核级线程想要执行goroutine需要加锁从全局队列中获取，所以不同线程之间的竞争很激烈，调度效率很差。

Image

后续引入了P(Processor)，每一个M(thread)要执行G(gorontine)的时候需要绑定一个P，其中P中会有一个待执行G的本地队列，只由当前M可以进行读写（少数情况会存在偷其他协程的G），读取P本地队列时不需要进行加锁，通过降低锁的竞争大幅度提升调度G的效率。

Image

mysql利用mvcc实现多个事务进行读写并发时保证数据的一致性和隔离型，也是解决读写并发的一种无锁化设计方案之一。它主要通过对每一行数据的变更记录维护多个版本链来实现的，通过隐藏列rollptr和undolog来实现快照读。在事务对某一行数据进行操作时，会根据当前事务id以及事务隔离级别判断读取那个版本的数据，对于可重复读就是在事务开始的时候生成readview，在后续整个事务期间都使用这个readview。mysql中除了使用mvcc避免互斥锁外，bufferpool还可以设置多个，通过多个bufferpool降低锁的粒度，提升读写性能，也是一种优化方案。

日常工作 在读多写少的场景下可以利用atomic.value存储数据，减少锁的竞争，提升系统性能，例如配置服务中数据就是利用atomic.value存储的；syncmap为了提升读性能，优先使用atomic进行read操作，然后再进行加互斥锁操作进行dirty的操作，在读多写少的情况下也可以使用syncmap。

秒杀系统的本质就是在高并发下准确的增减商品库存，不出现超卖少卖的问题。因此所有的用户在抢到商品时需要利用互斥锁进行库存数量的变更。互斥锁的存在必然会成为系统瓶颈，但是秒杀系统又是一个高并发的场景，所以如何进行互斥锁优化是提高秒杀系统性能的一个重要优化手段。

Image

无锁化设计方案之一就是利用消息队列，对于秒杀系统的秒杀操作进行异步处理，将秒杀操作发布一个消息到消息队列中，这样所有用户的秒杀行为就形成了一个先进先出的队列，只有前面先添加到消息队列中的用户才能抢购商品成功。从队列中消费消息进行库存变更的线程是个单线程，因此对于db的操作不会存在冲突，不需要加锁操作。

Image

另外一种优化方式可以参考golang的GMP模型，将库存分成多份，分别加载到服务server的本地，这样多机之间在对库存变更的时候就避免了锁的竞争。如果本地server是单进程的，因此也可以形成一种无锁化架构；如果是多进程的，需要对本地库存加锁后在进行变更，但是将库存分散到server本地，降低了锁的粒度，提高整个服务性能。

Image

顺序写

mysql的InnoDB存储引擎在创建主键时通常会建议使用自增主键，而不是使用uuid，最主要的原因是InnoDB底层采用B+树用来存储数据，每个叶子结点是一个数据页，存储多条数据记录，页面内的数据通过链表有序存储，数据页间通过双向链表存储。由于uuid是无序的，有可能会插入到已经空间不足的数据页中间，导致数据页分裂成两个新的数据页以便插入新数据，影响整体写入性能。

此外mysql中的写入过程并不是每次将修改的数据直接写入到磁盘中，而是修改内存中buffer pool内存储的数据页，将数据页的变更记录到undolog和binlog日志中，保证数据变更不丢失，每次记录log都是追加写到日志文件尾部，顺序写入到磁盘。对数据进行变更时通过顺序写log，避免随机写磁盘数据页，提升写入性能，这种将随机写转变为顺序写的思想在很多中间件中都有所体现。

Image

kakfa中的每个分区是一个有序不可变的消息队列，新的消息会不断的添加的partition的尾部，每个partition由多个segment组成，一个segment对应一个物理日志文件，kafka对segment日志文件的写入也是顺序写。顺序写入的好处是避免了磁盘的不断寻道和旋转次数，极大的提高了写入性能。

顺序写主要会应用在存在大量磁盘I/O操作的场景，日常工作中创建mysql表时选择自增主键，或者在进行数据库数据同步时顺序读写数据，避免底层页存储引擎的数据页分裂，也会对写入性能有一定的提升。

分片化

redis对于命令的执行过程是单线程的，单机有着很好的读写性能，但是单机的机器容量跟连接数毕竟有限，因此单机redis必然会存在读写上限跟存储上限。redis集群的出现就是为了解决单机redis的读写性能瓶颈问题，redis集群是将数据自动分片到多个节点上，每个节点负责数据的一部分，每个节点都可以对外提供服务，突破单机redis存储限制跟读写上限，提高整个服务的高并发能力。除了官方推出的集群模式，代理模式codis等也是将数据分片到不同节点，codis将多个完全独立的redis节点组成集群，通过codis转发请求到某一节点，来提高服务存储能力和读写性能。

Image

同样的kafka中每个topic也支持多个partition，partition分布到多个broker上，减轻单台机器的读写压力，通过增加partition数量可以增加消费者并行消费消息，提高kafka的水平扩展能力和吞吐量。

Image

新闻每日会生产大量的图文跟视频数据，底层是通过tdsql存储，可以分采分片化的存储思想，将图文跟视频或者其他介质存储到不同的数据库或者数据表中，同一种介质每日的生产量也会很大，这时候就可以对同一种介质拆分成多个数据表，进一步提高数据库的存储量跟吞吐量。另外一种角度去优化存储还可以将冷热数据分离，最新的数据采用性能好的机器存储，之前老数据访问量低，采用性能差的机器存储，节省成本。

在微服务重构过程中，需要进行数据同步，将总库中存储的全量数据通过kafka同步到内容微服务新的存储中，预期同步qps高达15k。由于kafka的每个partition只能通过一个消费者消费，要达到预期qps，因此需要创建750+partition才能够实现，但是kafka的partition过多会导致rebalance很慢，影响服务性能，成本和可维护行都不高。采用分片化的思想，可以将同一个partition中的数据，通过一个消费者在内存中分片到多个channel上，不同的channel对应的独立协程进行消费，多协程并发处理消息提高消费速度，消费成功后写入到对应的成功channel，由统一的offsetMaker线程消费成功消息进行offset提交，保证消息消费的可靠性。

Image

避免请求

为提升写入性能，mysql在写入数据的时候，对于在bufferpool中的数据页，直接修改bufferpool的数据页并写redolog;对于不在内存中的数据页并不会立刻将磁盘中的数据页加载到bufferpool中，而是仅仅将变更记录在缓冲区，等后续读取磁盘上的数据页到bufferpool中时会进行数据合并，需要注意的是对于非唯一索引才会采用这种方式，对于唯一索引写入的时候需要每次都将磁盘上的数据读取到bufferpool才能判断该数据是否已存在，对于已存在的数据会返回插入失败。

另外mysql查询例如select * from table where name = ‘xiaoming’ 的查询，如果name字段存在二级索引，由于这个查询是*，表示需要所在行的所有字段，需要进行回表操作，如果仅需要id和name字段，可以将查询语句改为select id , name from tabler where name = ‘xiaoming’ ，这样只需要在name这个二级索引上就可以查到所需数据，避免回表操作，减少一次I/O，提升查询速度。

Image

web应用中可以使用缓存、合并css和js文件等，避免或者减少http请求，提升页面加载速度跟用户体验。

在日常移动端开发应用中，对于多tab的数据，可以采用懒加载的方式，只有用户切换到新的tab之后才会发起请求，避免很多无用请求。服务端开发随着版本的迭代，有些功能字段端上已经不展示，但是服务端依然会返回数据字段，对于这些不需要的数据字段可以从数据源获取上就做下线处理，避免无用请求。另外在数据获取时可以对请求参数的合法性做准确的校验，例如请求投票信息时，运营配置的投票ID可能是“” 或者“0”这种不合法参数，如果对请求参数不进行校验，可能会存在很多无用I/O请求。另外在函数入口处通常会请求用户的所有实验参数，只有在实验期间才会用到实验参数，在实验下线后并没有下线ab实验平台的请求，可以在非实验期间下线这部分请求，提升接口响应速度。

池化

golang作为现代原生支持高并发的语言，池化技术在它的GMP模型就存在很大的应用。对于goroutine的销毁就不是用完直接销毁，而是放到P的本地空闲队列中，当下次需要创建G的时候会从空闲队列中直接取一个G复用即可；同样的对于M的创建跟销毁也是优先从全局队列中获取或者释放。此外golang中sync.pool可以用来保存被重复使用的对象，避免反复创建和销毁对象带来的消耗以及减轻gc压力。

mysql等数据库也都提供连接池，可以预先创建一定数量的连接用于处理数据库请求。当请求到来时，可以从连接池中选择空闲连接来处理请求，请求结束后将连接归还到连接池中，避免连接创建和销毁带来的开销，提升数据库性能。

在日常工作中可以创建线程池用来处理请求，在请求到来时同样的从链接池中选择空闲的线程来处理请求，处理结束后归还到线程池中，避免线程创建带来的消耗，在web框架等需要高并发的场景下非常常见。

异步处理

异步处理在数据库中同样应用广泛，例如redis的bgsave，bgrewriteof就是分别用来异步保存RDB跟AOF文件的命令，bgsave执行后会立刻返回成功，主线程fork出一个线程用来将内存中数据生成快照保存到磁盘，而主线程继续执行客户端命令；redis删除key的方式有del跟unlink两种，对于del命令是同步删除，直接释放内存，当遇到大key时，删除操作会让redis出现卡顿的问题，而unlink是异步删除的方式，执行后对于key只做不可达的标识，对于内存的回收由异步线程回收，不阻塞主线程。

mysql的主从同步支持异步复制、同步复制跟半同步复制。异步复制是指主库执行完提交的事务后立刻将结果返回给客户端，并不关心从库是否已经同步了数据；同步复制是指主库执行完提交的事务，所有的从库都执行了该事务才将结果返回给客户端；半同步复制指主库执行完后，至少一个从库接收并执行了事务才返回给客户端。有多种主要是因为异步复制客户端写入性能高，但是存在丢数据的风险，在数据一致性要求不高的场景下可以采用，同步方式写入性能差，适合在数据一致性要求高的场景使用。 此外对于kafka的生产者跟消费者都可以采用异步的方式进行发送跟消费消息，但是采用异步的方式有可能会导致出现丢消息的问题。对于异步发送消息可以采用带有回调函数的方式，当发送失败后通过回调函数进行感知，后续进行消息补偿。

在做服务性能优化中，发现之前的一些监控上报，曝光上报等操作都在主流程中，可以将这部分功能做异步处理，降低接口的时延。此外用户发布新闻后，会将新闻写入到个人页索引，对图片进行加工处理，标题进行审核，或者给用户增加活动积分等操作，都可以采用异步处理，这里的异步处理是将发送消息这个动作发送消息到消息队列中，不同的场景消费消息队列中的消息进行各自逻辑的处理，这种设计保证了写入性能，也解耦不同场景业务逻辑，提高系统可维护性。

Image

总结

本文主要总结进行服务性能优化的几种方式，每一种方式在我们常用的中间件中都有所体现，我想这也是我们常说多学习这些中间件的意义，学习它们不仅仅是学会如何去使用它们，也是学习它们底层优秀的设计思想，理解为什么要这样设计，这种设计有什么好处，后续我们在架构选型或者做服务性能优化时都会有一定的帮助。此外性能优化方式也给出了具体的落地实践，

希望通过实际的应用例子加强对这种优化方式的理解。此外要做服务性能优化，还是要从自身服务架构出发，分析服务调用链耗时分布跟cpu消耗，优化有问题的rpc调用和函数。

架构
#转载 #架构 #性能优化
服务架构性能优化方式与实践
https://blog.longpi1.com/2024/08/20/服务架构性能优化方式与实践/