【Java】记录一次服务性能问题定位、调优完整过程

谁践踏了优雅 2023-10-10 18:24 34阅读 0赞

#### 文章目录 ####

*  背景
 *   *  压测准备
     *  初步压测结论
 *  排查过程记录
 *   *  排除中间件及网络因素
     *  借助Arthas及Skywalking
     *  暴露prometheus指标
     *  修改数据库最大连接池数
     *   *  场景一
         *  场景二
         *  场景三
         *  场景四
         *  场景五
         *  场景六
         *  场景七
         *  场景八
         *  结论
     *  Consumer消费能力优化
     *   *  增加消费者
         *  增加Topic Queue数量
         *   *  Queue总数：96
             *  Queue总数：192
             *  Queue总数：900
         *  调整消费程序http最大连接池数
         *  Consumer参数微调
 *  总结
 *   *  优化总结
     *  经验总结

## 背景 ##

事件中心服务新增定时消息功能：

1.  基于 RocketMQ 5.0 的 TimerMessage 特性，作为触发定时消息的机制；
2.  事件中心API（pubsub）提供新的定时消息接口，作为定时消息的提交入口；
3.  定时消息元数据保存至 TiDB，RocketMQ 内只保存定时消息对应的主键ID；
4.  定时消息执行服务消费 RocketMQ 指定 Topic ，调用事件中心回调接口，发送消息至Kafka；
5.  为消息保证顺序性，RocketMQ Consumer 使用顺序消费。

![ab5ac605f694ad8a735777544e4a5068.png][]

定时消息的链路为：定时消息接口（pubsub） --> TiDB、RocketMQ --> 定时消息执行服务(Consumer) --> 定时消息回调接口 --> Kafka

本次压测及调优，只针对定时消息接口、定时消息执行服务(Consumer)、定时消息回调接口。

### 压测准备 ###

**压测意图**：

*  测试提交定时消息接口在不同 QPS 时的 RT 情况
 *  观测pubsub服务在负载情况下的资源使用情况
 *  测试consumer的消费能力、得出消息积压与Consumer数量的比例
 *  测试定时消息回调接口的QPS峰值

**场景描述**：

*  pubsub单实例，最终调整配置和生产环境一致
    
     *  limit：8c-8g
     *  \-Xms4G -Xmx4G
 *  模拟固定QPS对提交定时消息接口进行压测：
    
     *  QPS 1000
     *  QPS 3000
     *  QPS 5000
 *  堆积一定数量的定时消息：
    
     *  观察Consumer消费速度
     *  观察定时消息回调接口RT情况
     *  观察pubsub服务资源使用情况

**观测指标**：

pubsub服务器：

*  机器CPU使用情况
    
     *  top -Hp \{jvm\_pid\}
 *  查看线程级别 user, system 情况
    
     *  火焰图
 *  主机 load
 *  GC 情况
    
     *  若没有 gc 日志，用 jstat 临时输出一下
 *  内存增长情况
 *  线程情况
 *  接口耗时（通过压测平台监控查看）
    
     *  99.99% RT
     *  平均 RT

定时消息执行服务：

*  consumer TPS
 *  consumer 服务监控
    
     *  jvm监控
     *  httpclient监控
        
         *  QPS
         *  RT
 *  consumer 主机监控
    
     *  cpu
     *  load
     *  memory
 *  pubsub服务器：
    
     *  机器CPU使用情况
     *  内存增长情况
 *  消息延迟情况
    
     *  对比数据库期望发送时间和实际发送时间

### 初步压测结论 ###

*  pubsub服务2c-6g，单实例；Consumer服务2c-6g，单实例
 *  定时消息提交接口并发数1000，思考时间为1000ms，模拟QPS为1000的场景，平均RT在好几秒，吞吐量只有200左右
 *  单个消费者TPS只有60左右
 *  pubsub服务及Consumer服务资源使用率均保持在很低水平
 *  pubsub服务young GC频繁

离预期相距甚远，预期是可以承受上万条消息积压仍能保持毫秒级别的误差，所以优化目标为：

*  提升pubsub定时消息接口单实例QPS至3000+，99.99% RT 在200ms内；
 *  提升Consumer消费TPS至10000+

## 排查过程记录 ##

### 排除中间件及网络因素 ###

在pubsub服务实例上ping TiDB、RocketMQ服务地址，延迟均为5ms内，先排除网络原因。

使用相同的压测脚本，尝试压了测试环境的pubsub服务，测试环境的压测结果很正常，QPS达到预期设置的1000，平均RT在10ms内，测试环境使用的是MySQL，生产环境使用的是新申请的阿里云服务器搭建的TiDB，怀疑是TiDB服务端配置或者其他原因导致影响性能。

将生产环境上pubsub使用的TiDB换为同网络环境的MySQL，压测情况并无变化，排除。

RocketMQ服务在相同网段进行过压测，压测结果正常，排除。

由于测试环境和生产环境压测结果大相径庭，很长一段时间的排查方向都指向了生产环境k8s的网络、组件间的延迟等，于是又把pubsub部署至生产环境的一台物理机上，结果任然保持不变。

客观测试了一下测试环境和生产环境的网络差异：

**并发数 1，思考时间 1000ms**

测试环境：

![ed397590e79d7a8ed5210ed3105889c0.jpeg][]

生产环境：

![7eafb7567b31c8a877b9a295052770aa.jpeg][]

![39a4ae79672da5257bc1df89d65c61f5.jpeg][]

分析

每次接口提交，大致产生的跨进程交互如下：

<table> 
 <thead> 
  <tr> 
   <th>内容</th> 
   <th></th> 
   <th>测试环境耗时</th> 
   <th>生产环境耗时</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>施压机到pubsub主机</td> 
   <td></td> 
   <td>0.18</td> 
   <td>0.6</td> 
  </tr> 
  <tr> 
   <td>pubsub主机到tidb，开启事务</td> 
   <td></td> 
   <td>0.06</td> 
   <td>4.9</td> 
  </tr> 
  <tr> 
   <td>pubsub主机到tidb，运行 sql</td> 
   <td></td> 
   <td>0.06</td> 
   <td>4.9</td> 
  </tr> 
  <tr> 
   <td>pubsub主机到rocketMQ，生产消息</td> 
   <td></td> 
   <td>0.3</td> 
   <td>4</td> 
  </tr> 
  <tr> 
   <td>pubsub主机到tidb，提交事务</td> 
   <td></td> 
   <td>0.06</td> 
   <td>4.9</td> 
  </tr> 
  <tr> 
   <td>总计</td> 
   <td></td> 
   <td>0.66</td> 
   <td>19.3</td> 
  </tr> 
  <tr> 
   <td>本场景压测RT平均值</td> 
   <td></td> 
   <td>7.98</td> 
   <td>40.93</td> 
  </tr> 
 </tbody> 
</table>

结论：

由于测试环境的物理距离问题，天然有至少5倍左右的性能差异，所以测试环境的压测结果超出预期的理想，得益于各组件的网络低延迟，但是生产环境的网络延迟属于正常范围，还需进一步排查。

### 借助Arthas及Skywalking ###

使用 Arthas 的 trace 命令，对接口的主要逻辑方法进行耗时追踪：

![46667573d0ebd8743c6f8f7c19753076.png][]

发现真正执行逻辑的代码只耗时13ms左右，但是执行方法之前，有一个500多ms的耗时。

使用skywalking观察耗时很长的请求，结果如下：

![24085f21575ff5c2a2d0212e8ed7c6d8.png][]

结论相同，在执行SQL前，有一个很长的等待时间，初步定位到问题，怀疑是数据库连接池的问题。

### 暴露prometheus指标 ###

pom文件中添加：

<dependency>
                <groupId>io.micrometer</groupId>
                <artifactId>micrometer-registry-prometheus</artifactId>
                <scope>runtime</scope>
            </dependency>

添加配置：

# 对外暴露所有监控指标
    management:
      endpoints:
        web:
          exposure:
            include: "*"
      endpoint:
        prometheus:
          enabled: true # 激活普罗米修斯
        health:
          show-details: always # 健康值总是展示细节
      metrics:
        export:
          prometheus:
            enabled: true # 指标允许被导出

启动服务后，访问：/actuator/prometheus

![ddbfa362e912243c71488b684accd53b.png][]

![fcf92bcbd4d0337a18824db07ec572d6.png][]

可以看到默认连接池最大数量是10，大量并发情况下，获取连接池时，耗费了大量的时间。

### 修改数据库最大连接池数 ###

场景一至场景四：并发数 500，思考时间 400 ms

#### 场景一 ####

pubbsub 调整内容：

1.  tomcat 线程数改为 64
2.  connection 连接池数量改为 10

![65f5af58438c63c15ebfc4a8f7b6df28.jpeg][]

![ef56aa9546aa2c397142743202ec7fa7.jpeg][]

![58262c654e41a7da80ed6f3744222fc8.jpeg][]

分析

1.  cpu 使用率不高，execute 前执行时间较长，怀疑是获取 jdbc connection 时间较长，更改 hikari 连接池数量为 32
2.  压测平台与 sk 查看不同，是因为存在请求积压，即等待了一段时间后，才开始被执行

#### 场景二 ####

pubsub 调整内容：

1.  tomcat 线程数改为 64
2.  connection 连接池数量改为 32

![c5bbf4b761e3a606fd143cfb9ee309d0.jpeg][]

第一次压测：

![47f8d5bea1f8eedf5059f52a26315779.jpeg][]

第二次压测：

![b6a4a6449ebb35b5b50333e937b3b2d3.jpeg][]

![dd7329045ab55f0db5bf01682456882a.jpeg][]

分析：

1.  从 skywalking 看执行时间已经明显缩短，应该是增大了 connection 连接数导致
2.  第二次执行压测时，性能已明显上升，应该是第一次压测时连接池还没有达到指定数量，都要重新建立连接，导致耗时较长
3.  cpu 使用率升高，说明线程使用 cpu 的时间多了起来，是正确的优化方向

#### 场景三 ####

pubsub 调整内容：

1.  tomcat 线程数改为 64
2.  connection 连接池数量改为 64

![60c85863b96100cf62d2c73159ba10c1.jpeg][]

![23a34a5be2036fae475a38c5c3f37c50.jpeg][]

![14446d930d170bbbf02b8fffd6ae2f98.jpeg][]

分析：

1.  用在等待连接方面的耗时几乎已经没有
2.  cpu 还有一定空闲资源，进一步增大线程数和对应的连接数

#### 场景四 ####

pubsub 调整内容：

1.  tomcat 线程数改为 128
2.  connection 连接池数量改为 128

![3d7db8b34d9eba67922d29bbfa2fbb0d.jpeg][]

![91006fc1a3b6b2d5aa21dca2b3af029c.jpeg][]

分析：

1.  cpu 已到达瓶颈，调整线程数量收益应该不太明显了
2.  这时调整 gc 相关参数应该会有些收益

#### 场景五 ####

尝试提升压力，观察 RT 情况：并发数 500，思考时间 400 ms

![0a4b6c8b1d3b8e0ca0479f51ba452115.jpeg][]

![666d2f95d2d873de46b9762637b3ea07.jpeg][]

分析：

1.  CPU 使用率下降，可能是 c2 代码优化已经完成
2.  TPS 上涨，RT 没有明显变化，继续加压

#### 场景六 ####

并发数 500，思考时间 300 ms

![504e8fe2f22abe5a009f198b6e458563.jpeg][]

![5657c563615bffaec1ad76e5edff05a8.jpeg][]

分析

1.  cpu 没有到达瓶颈，继续加压

#### 场景七 ####

并发数 500，思考时间 200 ms

![799e793f3103767b248d47ad1c413557.jpeg][]

![9fe2a0127e92a354a0dd9839933129dd.jpeg][]

#### 场景八 ####

pubsub 调整内容：

1.  tomcat 线程数改为 200
2.  connection 连接池数量改为 200

![1f20e4726fcca4673f767e8900ef63be.jpeg][]

![040204e2d19f5ed357e8c566e580733e.jpeg][]

分析：

CPU已打满，继续增加线程数无提升，线程数已接近理想状态值。

#### 结论 ####

CPU核数、Tomcat线程数、数据库连接池数比例约为：

**1：100：100**

将pubsub服务CPU核数修改为：8c，Tomcat线程数、数据库连接池数修改为：800

![df31bc6ab23ac26c3f1f684c2c019ddf.jpeg][]

### Consumer消费能力优化 ###

初始状态：

*  Consumer服务：2c-6g，启动一个消费者
 *  RocketMQ Topic读写队列总数均为48
 *  pubsub服务：8c-6g，单实例
 *  消费者TPS：60左右

#### 增加消费者 ####

将消费者增加至20个：

消费服务资源使用情况：

![24d0b4e142a5a51cdc967913d9dd181f.jpeg][]

![189b9f817912551c6e8e9c836c88eb34.jpeg][]

定时消息回调接口：

![1d66a209addb42afeafcaf6366f1836f.jpeg][]

![1d700f784af36eebe19cfbc5bbf7ae07.jpeg][]

消费者TPS：

![4efdcb1b65d01c515517700fc50b6429.jpeg][]

可以看到增加消费者后，消费能力明显提升，但是个服务资源使用率都未达到上限。

继续增加Consumer数量，TPS并没有提升。

#### 增加Topic Queue数量 ####

##### Queue总数：96 #####

（这里测试消费能力，可以只修改读队列数）

<table> 
 <thead> 
  <tr> 
   <th>消费服务实例数</th> 
   <th>单个服务消费者数量</th> 
   <th>消费者总数</th> 
   <th>消费TPS</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>20</td> 
   <td></td> 
   <td>3000左右</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>40</td> 
   <td>40</td> 
   <td>3000左右</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>20</td> 
   <td>40</td> 
   <td>5000左右</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>40</td> 
   <td>80</td> 
   <td>5000左右</td> 
  </tr> 
 </tbody> 
</table>

以上压测过程中，pubsub服务和消费者服务的资源使用率都只维持在中等水平，单个消费者实例上消费者数量达到40时，出现个别报错：

![41c87ebc8ea1aff41c0439e6f79c15ce.png][]

第一次出现这个异常，刚开始没仔细看异常信息，以为是pubsub回调接口处理不过来了，没有在意，造成了一个排查疏漏，走了一些弯路。

##### Queue总数：192 #####

<table> 
 <thead> 
  <tr> 
   <th>消费服务实例数</th> 
   <th>单个服务消费者数量</th> 
   <th>消费者总数</th> 
   <th>消费TPS</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>20</td> 
   <td>20</td> 
   <td>3000左右</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>40</td> 
   <td>40</td> 
   <td>3000左右</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>20</td> 
   <td>40</td> 
   <td>5000左右</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>20</td> 
   <td>80</td> 
   <td>8500左右</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>20</td> 
   <td>100</td> 
   <td>9500左右</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>20</td> 
   <td>120</td> 
   <td>9500左右</td> 
  </tr> 
 </tbody> 
</table>

##### Queue总数：900 #####

<table> 
 <thead> 
  <tr> 
   <th>消费服务实例数</th> 
   <th>单个服务消费者数量</th> 
   <th>消费者总数</th> 
   <th>消费TPS</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>4</td> 
   <td>30</td> 
   <td>120</td> 
   <td>9000左右</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>30</td> 
   <td>150</td> 
   <td>12000左右</td> 
  </tr> 
 </tbody> 
</table>

由于每一轮压测成本过高，已经达到预期，没有继续进行后续压测。

消费者在30\*4时，再次出现大量异常：ConnectionPoolTimeoutException

![6b080a99c53b34e3589f9190fa4d66e5.jpeg][]

初步结论：

*  增加消费者数量和 Topic队列数，可以有效提升消费者TPS
 *  目前单个消费服务配置20~30个消费者达到消费峰值，但是消费服务和pubsub服务的资源使用还远远没到瓶颈。
 *  消费服务内有http客户端，怀疑是瓶颈在http连接池上，而之前出现的异常：ConnectionPoolTimeoutException，正式由于http客户端使用了连接池，从连接池内获取http连接超时导致的。

#### 调整消费程序http最大连接池数 ####

消费程序中的http客户端使用的是apache提供的CloseableHttpClient，有两个线程池核心参数：

*  maxTotal：连接池最大连接数
 *  defaultMaxPerRoute：每路由最大连接数

maxTotal默认是200，defaultMaxPerRoute默认是50，而消费程序中只会调用一个接口，所以实际只有50个连接是可用的，将defaultMaxPerRoute修改为200。

![59d19934ee3d016a75aee111fca13eb3.jpeg][]

消费者TPS有提升，不再有报错信息，消费者服务CPU消耗有提升。

#### Consumer参数微调 ####

对Consumer进行了几个参数的调试，包括：consumeThreadMax、consumeThreadMin、consumeMessageBatchMaxSize、pullBatchSize，其中consumeThreadMax、consumeThreadMin两个参数修改后对消费能力有较明显提升，其余两个对于顺序消费场景无明显提升。

consumeThreadMax、consumeThreadMin默认为20，修改为40：

![1e276fbf969a4be7f8c5ec2aa63dd087.jpeg][]

CPU消耗有提升，加大consumeThreadMin后，消费者TPS可以瞬间达到消费峰值

继续加大consumeThreadMin后，消费TPS出现下滑。

Tips：Consumer客户端会根据消费线程的压力，动态增加消费线程：

![d3fe22d3ea5f31e7ff3a39304bc083da.jpeg][]

![a2a300b2f681c19499ac67c785d6849f.jpeg][]

## 总结 ##

### 优化总结 ###

*  pubsub服务资源为8c-6g，核数和Tomcat线程数比例为1:100、Tomcat线程数和数据库连接池数比例为1:1；
 *  基于以上配置，pubsub单实例定时消息接口QPS理想值为4500左右、回调接口QPS高于此；
 *  目前Consumer最佳配置为单实例30个消费者，每个消费者配置consumeThreadMin=40，按理说可以通过增加资源，来增加单实例上的消费者数量，减少实例数，但是通过测试发现不可行，由于时间原因没有继续探索。
 *  增加Topic 读队列数和消费者数量可以提升消费能力，本次测试过程中，消费者和队列数比例达到1:2时，获得最大消费TPS；
 *  pubsub程序初始时没设置xmn，导致young GC比较频繁，后续根据观察各区域内存的变化情况，将xmn设置为总堆大小的3/4。

### 经验总结 ###

*  压测时间需要尽量长一点，需要等编译优化完成后，程序的性能才能达到一个稳定值，尤其是对刚启动的项目；
 *  优化过程中要注意小细节，对任何出现的异常都需要精确定位后再继续，避免大方向错误；
 *  借助Trace工具、prometheus指标暴露插件能更快定位问题；
 *  若性能达到瓶颈时，资源使用率没有提升，需要考虑各环节中使用到的线程池、连接池的限制；
 *  注意版本不同时，一些配置的变化，如：Tomcat线程数配置，spring 2.3版本之前：server.tomcat.max-threads，spring 2.3版本之后：server.tomcat.threads.max
 *  做优化前，需要有一个整体的规划，对整体的性能瓶颈点有一个预先的认知，包括服务本身、使用到的各中间件配置、客户端配置等，逐个进行排除

[ab5ac605f694ad8a735777544e4a5068.png]: https://img-blog.csdnimg.cn/img_convert/ab5ac605f694ad8a735777544e4a5068.png
[ed397590e79d7a8ed5210ed3105889c0.jpeg]: https://img-blog.csdnimg.cn/img_convert/ed397590e79d7a8ed5210ed3105889c0.jpeg
[7eafb7567b31c8a877b9a295052770aa.jpeg]: https://img-blog.csdnimg.cn/img_convert/7eafb7567b31c8a877b9a295052770aa.jpeg
[39a4ae79672da5257bc1df89d65c61f5.jpeg]: https://img-blog.csdnimg.cn/img_convert/39a4ae79672da5257bc1df89d65c61f5.jpeg
[46667573d0ebd8743c6f8f7c19753076.png]: https://img-blog.csdnimg.cn/img_convert/46667573d0ebd8743c6f8f7c19753076.png
[24085f21575ff5c2a2d0212e8ed7c6d8.png]: https://img-blog.csdnimg.cn/img_convert/24085f21575ff5c2a2d0212e8ed7c6d8.png
[ddbfa362e912243c71488b684accd53b.png]: https://img-blog.csdnimg.cn/img_convert/ddbfa362e912243c71488b684accd53b.png
[fcf92bcbd4d0337a18824db07ec572d6.png]: https://img-blog.csdnimg.cn/img_convert/fcf92bcbd4d0337a18824db07ec572d6.png
[65f5af58438c63c15ebfc4a8f7b6df28.jpeg]: https://img-blog.csdnimg.cn/img_convert/65f5af58438c63c15ebfc4a8f7b6df28.jpeg
[ef56aa9546aa2c397142743202ec7fa7.jpeg]: https://img-blog.csdnimg.cn/img_convert/ef56aa9546aa2c397142743202ec7fa7.jpeg
[58262c654e41a7da80ed6f3744222fc8.jpeg]: https://img-blog.csdnimg.cn/img_convert/58262c654e41a7da80ed6f3744222fc8.jpeg
[c5bbf4b761e3a606fd143cfb9ee309d0.jpeg]: https://img-blog.csdnimg.cn/img_convert/c5bbf4b761e3a606fd143cfb9ee309d0.jpeg
[47f8d5bea1f8eedf5059f52a26315779.jpeg]: https://img-blog.csdnimg.cn/img_convert/47f8d5bea1f8eedf5059f52a26315779.jpeg
[b6a4a6449ebb35b5b50333e937b3b2d3.jpeg]: https://img-blog.csdnimg.cn/img_convert/b6a4a6449ebb35b5b50333e937b3b2d3.jpeg
[dd7329045ab55f0db5bf01682456882a.jpeg]: https://img-blog.csdnimg.cn/img_convert/dd7329045ab55f0db5bf01682456882a.jpeg
[60c85863b96100cf62d2c73159ba10c1.jpeg]: https://img-blog.csdnimg.cn/img_convert/60c85863b96100cf62d2c73159ba10c1.jpeg
[23a34a5be2036fae475a38c5c3f37c50.jpeg]: https://img-blog.csdnimg.cn/img_convert/23a34a5be2036fae475a38c5c3f37c50.jpeg
[14446d930d170bbbf02b8fffd6ae2f98.jpeg]: https://img-blog.csdnimg.cn/img_convert/14446d930d170bbbf02b8fffd6ae2f98.jpeg
[3d7db8b34d9eba67922d29bbfa2fbb0d.jpeg]: https://img-blog.csdnimg.cn/img_convert/3d7db8b34d9eba67922d29bbfa2fbb0d.jpeg
[91006fc1a3b6b2d5aa21dca2b3af029c.jpeg]: https://img-blog.csdnimg.cn/img_convert/91006fc1a3b6b2d5aa21dca2b3af029c.jpeg
[0a4b6c8b1d3b8e0ca0479f51ba452115.jpeg]: https://img-blog.csdnimg.cn/img_convert/0a4b6c8b1d3b8e0ca0479f51ba452115.jpeg
[666d2f95d2d873de46b9762637b3ea07.jpeg]: https://img-blog.csdnimg.cn/img_convert/666d2f95d2d873de46b9762637b3ea07.jpeg
[504e8fe2f22abe5a009f198b6e458563.jpeg]: https://img-blog.csdnimg.cn/img_convert/504e8fe2f22abe5a009f198b6e458563.jpeg
[5657c563615bffaec1ad76e5edff05a8.jpeg]: https://img-blog.csdnimg.cn/img_convert/5657c563615bffaec1ad76e5edff05a8.jpeg
[799e793f3103767b248d47ad1c413557.jpeg]: https://img-blog.csdnimg.cn/img_convert/799e793f3103767b248d47ad1c413557.jpeg
[9fe2a0127e92a354a0dd9839933129dd.jpeg]: https://img-blog.csdnimg.cn/img_convert/9fe2a0127e92a354a0dd9839933129dd.jpeg
[1f20e4726fcca4673f767e8900ef63be.jpeg]: https://img-blog.csdnimg.cn/img_convert/1f20e4726fcca4673f767e8900ef63be.jpeg
[040204e2d19f5ed357e8c566e580733e.jpeg]: https://img-blog.csdnimg.cn/img_convert/040204e2d19f5ed357e8c566e580733e.jpeg
[df31bc6ab23ac26c3f1f684c2c019ddf.jpeg]: https://img-blog.csdnimg.cn/img_convert/df31bc6ab23ac26c3f1f684c2c019ddf.jpeg
[24d0b4e142a5a51cdc967913d9dd181f.jpeg]: https://img-blog.csdnimg.cn/img_convert/24d0b4e142a5a51cdc967913d9dd181f.jpeg
[189b9f817912551c6e8e9c836c88eb34.jpeg]: https://img-blog.csdnimg.cn/img_convert/189b9f817912551c6e8e9c836c88eb34.jpeg
[1d66a209addb42afeafcaf6366f1836f.jpeg]: https://img-blog.csdnimg.cn/img_convert/1d66a209addb42afeafcaf6366f1836f.jpeg
[1d700f784af36eebe19cfbc5bbf7ae07.jpeg]: https://img-blog.csdnimg.cn/img_convert/1d700f784af36eebe19cfbc5bbf7ae07.jpeg
[4efdcb1b65d01c515517700fc50b6429.jpeg]: https://img-blog.csdnimg.cn/img_convert/4efdcb1b65d01c515517700fc50b6429.jpeg
[41c87ebc8ea1aff41c0439e6f79c15ce.png]: https://img-blog.csdnimg.cn/img_convert/41c87ebc8ea1aff41c0439e6f79c15ce.png
[6b080a99c53b34e3589f9190fa4d66e5.jpeg]: https://img-blog.csdnimg.cn/img_convert/6b080a99c53b34e3589f9190fa4d66e5.jpeg
[59d19934ee3d016a75aee111fca13eb3.jpeg]: https://img-blog.csdnimg.cn/img_convert/59d19934ee3d016a75aee111fca13eb3.jpeg
[1e276fbf969a4be7f8c5ec2aa63dd087.jpeg]: https://img-blog.csdnimg.cn/img_convert/1e276fbf969a4be7f8c5ec2aa63dd087.jpeg
[d3fe22d3ea5f31e7ff3a39304bc083da.jpeg]: https://img-blog.csdnimg.cn/img_convert/d3fe22d3ea5f31e7ff3a39304bc083da.jpeg
[a2a300b2f681c19499ac67c785d6849f.jpeg]: https://img-blog.csdnimg.cn/img_convert/a2a300b2f681c19499ac67c785d6849f.jpeg