看门狗”机制—分布式锁

爱被打了一巴掌 2024-04-03 11:48 85阅读 0赞

提到分布式锁，大家一般都会想到 Redis。

想到 Redis，一部分同学会说到 Redisson。

那么说到 Redisson，就不得不掰扯掰扯一下它的“看门狗”机制了。

所以你以为这篇文章我要给你讲“看门狗”吗？

不是，我主要是想给你汇报一下我最近研究的由于引入“看门狗”之后，给 Redisson 带来的两个看起来就菊花一紧的 bug ：

*  看门狗不生效的 BUG。
 *  看门狗导致死锁的 BUG。

为了能让你丝滑入戏，我还是先简单的给你铺垫一下，Redisson 的看门狗到底是个啥东西。

### 看门狗描述 ###

你去看 Redisson 的 wiki 文档，在锁的这一部分，开篇就提到了一个单词：watchdog

![125f3cec9a61c11a17bd4fb13bab4028.png][]

watchdog，就是看门狗的意思。

它是干啥用的呢？

好的，如果你回答不上来这个问题。那当你遇到下面这个面试题的时候肯定懵逼。

面试官：请问你用 Redis 做分布式锁的时候，如果指定过期时间到了，把锁给释放了。但是任务还未执行完成，导致任务再次被执行，这种情况你会怎么处理呢？

这个时候，99% 的面试官想得到的回答都是看门狗，或者一种类似于看门狗的机制。

如果你说：这个问题我遇到过，但是我就是把过期时间设置的长一点。

时间到底设置多长，是你一个非常主观的判断，设置的长一点，能一定程度上解决这个问题，但是不能完全解决。

所以，请回去等通知吧。

或者你回答：这个问题我遇到过，我不设置过期时间，由程序调用 unlock 来保证。

好的，程序保证调用 unlock 方法没毛病，这是在程序层面可控、可保证的。但是如果你程序运行的服务器刚好还没来得及执行 unlock 就宕机了呢，这个你不能打包票吧？

这个锁是不是就死锁了？

所以......

![b734624aa1c87e409729fc2d47a79757.png][]

为了解决前面提到的过期时间不好设置，以及一不小心死锁的问题，Redisson 内部基于时间轮，针对每一个锁都搞了一个定时任务，这个定时任务，就是看门狗。

在 Redisson 实例被关闭前，这个狗子可以通过定时任务不断的延长锁的有效期。

因为你根本就不需要设置过期时间，这样就从根本上解决了“过期时间不好设置”的问题。默认情况下，看门狗的检查锁的超时时间是 30 秒钟，也可以通过修改参数来另行指定。

如果很不幸，节点宕机了导致没有执行 unlock，那么在默认的配置下最长 30s 的时间后，这个锁就自动释放了。

那么问题来了，面试官紧接着来一个追问：怎么自动释放呢？

这个时候，你只需要来一个战术后仰：程序都没了，你觉得定时任务还在吗？定时任务都不在了，所以也不会存在死锁的问题。

![db2c70a300c314a27c95cf9f72db6802.png][]

### 搞 Demo ###

前面简单介绍了原理，我也还是给你搞个简单的 Demo 跑一把，这样更加的直观。

引入依赖，启动 Redis 什么的就不说了，直接看代码。

示例代码非常简单，就这么一点内容，非常常规的使用方法：

![1d9c5235de28ca8e5605a338167b543a.png][]

把项目启动起来，触发接口之后，通过工具观察 Redis 里面 whyLock 这个 key 的情况，是这样的：

![67369ec1c67a6c05f122339fac1a270e.png][]

你可以看到在我的截图里面，是有过期时间的，也就是我打箭头的地方。

然后我给你搞个动图，你仔细看过期时间（TTL）这个地方，有一个从 20s 变回 30s 的过程：

![b54f682234dd517d43f51e6f599e216e.gif][]

首先，我们的代码里面并没有设置过期时间的动作，也没有去更新过期时间的这个动作。

那么这个东西是怎么回事呢？

![fe53b1d70a613a81fec1c0d76dbb52f3.png][]

很简单，Redisson 帮我们做了这些事情，开箱即用，当个黑盒就完事了。

接下来我就是带你把黑盒变成白盒，然后引出前面提到的两个 bug。

我的测试用例里面用的是 3.16.0 版本的 Redission，我们先找一下它关于设置过期动作的源码。

首先可以看到，我虽然调用的是无参的 lock 方法，但是它其实也只是一层皮而已，里面还是调用了带入参的 lock 方法，只不过给了几个默认值，其中 leaseTime 给的是 -1：

![056636a073e93e9a304b6540986824f6.png][]

而有参的 lock 的源码是这样的，主要把注意力放到我框起来的这一行代码中：

![e1e716735619bb6ddf0c0c873959dd42.png][]

tryAcquire 方法是它的核心逻辑，那么这个方法是在干啥事儿呢？

点进去看看，这部分源码又是这样的：

![7690b1b39224ab7e60e7019bb75c9a85.png][]

其中 tryLockInnerAsync 方法就是执行 Redis 的 Lua 脚本来加锁。

既然是加锁了，过期时间肯定就是在这里设置的，也就是这里的 leaseTime：

![f8f826b823fdbf9b96fa5fe858333de6.png][]

而这里的 leaseTime 是在构造方法里面初始化的，在我的 Demo 里面，用的是配置中的默认值，也就是 30s :

![05d1647b39adec5ee0085168f3627504.png][]

所以，为什么我们的代码里面并没有设置过期时间的动作，但是对应的 key 却有过期时间呢？

这里的源码回答了这个问题。

额外提一句，这个时间是从配置中获取的，所以肯定是可以自定义的，不一定非得是 30s。

另外需要注意的是，到这里，我们出现了两个不同的 leaseTime。

分别是这样的：

*  tryAcquireOnceAsync 方法的入参 leaseTime，我们的示例中是 -1。
 *  tryLockInnerAsync 方法的入参 leaseTime，我们的示例中是默认值 30 \* 1000。

![43a3649506116d5efd49b8e6f860f70e.png][]

在前面加完锁之后，紧接着就轮到看门狗工作了：

![3b97d59a7a9461f756a474bb0870ecc7.png][]

前面我说了，这里的 leaseTime 是 -1，所以触发的是 else 分支中的 scheduleExpirationRenewal 代码。

而这个代码就是启动看门狗的代码。

换句话说，如果这里的 leaseTime 不是 -1，那么就不会启动看门狗。

那么怎么让 leaseTime 不是 -1 呢？

自己指定加锁时间：

![6dd2de15994a117f23ec4c967554450a.png][]

说人话就是如果加锁的时候指定了过期时间，那么 Redission 不会给你开启看门狗的机制。

这个点是无数人对看门狗机制不清楚的人都会记错的一个点，我曾经在一个群里面据理力争，后来被别人拿着源码一顿乱捶。

![fdf653cf5ddaa3f50a749737b39afa57.png][]

是的，我就是那个以为指定了过期时间之后，看门狗还会继续工作的人。

打脸老疼了，希望你不要步后尘。

接着来看一下 scheduleExpirationRenewal 的代码：

![725fe633de2623eb082e52ee5850fe53.png][]

里面就是把当前线程封装成了一个对象，然后维护到一个 MAP 中。

**这个 MAP 很重要，我先把它放到这里，混个眼熟，一会再说它：**

![0e217d0b343930ed92d106b3fbec45c7.png][]

你只要记住这个 MAP 的 key 是当前线程，value 是 ExpirationEntry 对象，这个对象维护的是当前线程的加锁次数。

![d73a138a36cff629dce464013101b414.png][]

然后，我们先看 scheduleExpirationRenewal 方法里面，调用 MAP 的 putIfAbsent 方法后，返回的 oldEntry 为空的情况。

这种情况说明是第一次加锁，会触发 renewExpiration 方法，这个方法里面就是看门狗的核心逻辑。

而在 scheduleExpirationRenewal 方法里面，不管前面提到的 oldEntry 是否为空，都会触发 addThreadId 方法：

![a0ca71f83a730e923084877c055d1137.png][]

从源码中可以看出来，这里仅仅对当前线程的加锁次数进行一个维护。

这个维护很好理解，因为要支持锁的重入嘛，就得记录到底重入了几次。

加锁一次，次数加一。解锁一次，次数减一。

接着看 renewExpiration 方法，这就是看门狗的真面目了：

![3c3538f04726184d0c19245e2a121944.png][]

首先这一坨逻辑主要就是一个基于时间轮的定时任务。

标号为 ④ 的地方，就是这个定时任务触发的时间条件：internalLockLeaseTime / 3。

前面我说了，internalLockLeaseTime 默认情况下是 30\* 1000，所以这里默认就是每 10 秒执行一次续命的任务，这个从我前面给到的动态里面也可以看出，ttl 的时间先从 30 变成了 20 ，然后一下又从 20 变成了 30。

标号为 ①、② 的地方干的是同一件事，就是检查当前线程是否还有效。

怎么判断是否有效呢？

就是看前面提到的 MAP 中是否还有当前线程对应的 ExpirationEntry 对象。

没有，就说明是被 remove 了。

那么问题就来了，你看源码的时候非常自然而然的就应该想到这个问题：什么时候调用这个 MAP 的 remove 方法呢？

很快，在接下来讲释放锁的地方，你就可以看到对应的 remove。这里先提一下，后面就能呼应上了。

核心逻辑是标号为 ③ 的地方。我带你仔细看看，主要关注我加了下划线的地方。

能走到 ③ 这里说明当前线程的业务逻辑还未执行完成，还需要继续持有锁。

首先看 renewExpirationAsync 方法，从方法命名上我们也可以看出来，这是在重置过期时间：

![10e36041d70568be7503d85b4184849d.png][]

上面的源码主要是一个 lua 脚本，而这个脚本的逻辑非常简单。就是判断锁是否还存在，且持有锁的线程是否是当前线程。如果是当前线程，重置锁的过期时间，并返回 1，即返回 true。

如果锁不存在，或者持有锁的不是当前线程，那么则返回 0，即返回 false。

接着标号为 ③ 的地方，里面首先判断了执行 renewExpirationAsync 方法是否有异常。

那么问题就来了，会有什么异常呢？

这个地方的异常，主要是因为要到 Redis 执行命令嘛，所以如果 Redis 出问题了，比如卡住了，或者掉线了，或者连接池没有连接了等等各种情况，都可能会执行不了命令，导致异常。

如果出现异常了，则执行下面这行代码：

然后就 return ，这个定时任务就结束了。

**好，记住这个 remove 的操作，非常重要，先混个眼熟，一会会讲。**

如果执行 renewExpirationAsync 方法的时候没有异常。这个时候的返回值就是 true 或者 false。

如果是 true，说明续命成功，则再次调用 renewExporation 方法，等待着时间轮触发下一次。

如果是 false，说明这把锁已经没有了，或者易主了。那么也就没有当前线程什么事情了，啥都不用做，默默的结束就行了。

上锁和看门狗的一些基本原理就是前面说到这么多。

接着简单看看 unlock 方法里面是怎么回事儿的。

![263718aedcd6a06466c6c800e81bf8c0.png][]

首先是 unlockInnerAsync 方法，这里面就是 lua 脚本释放锁的逻辑：

![59aa7e7cab976f1ef67c3fb326d7f624.png][]

这个方法返回的是 Boolean，有三种情况。

*  返回为 null，说明锁不存在，或者锁存在，但是 value 不匹配，表示锁已经被其他线程占用。
 *  返回为 true，说明锁存在，线程也是对的，重入次数已经减为零，锁可以被释放。
 *  返回为 false，说明锁存在，线程也是对的，但是重入次数还不为零，锁还不能被释放。

但是你看 unlockInnerAsync 是怎么处理这个返回值的：

![afdc580c0bf0455f3858fce2dcc477cb.png][]

返回值，也就是 opStatus，仅仅是判断了返回为 null 的情况，抛出异常表明这个锁不是被当前线程持有的，完事。

它并不关心返回为 true 或者为 false 的情况。

然后再看我框起来的 `cancelExpirationRenewal(threadId);` 方法：

![7ae58cad4456f54c57637c69cd6cec68.png][]

这里面就有 remove 方法。

而前面铺垫了这么多其实就是为了引出这个 cancelExpirationRenewal 方法。

纵观一下加锁和解锁，针对 MAP 的操作，看一下下面的这个图片：

![9c11113e2cf9c157ed3218aa88dcf0d4.png][]

标号为 ① 的地方是加锁，调用 MAP 的 put 方法。

标号为 ② 的地方是放锁，调用 MAP 的 remove 方法。

记住上面这一段分析，和操作这个 MAP 的时机，下面说的 BUG 都是由于对这个 MAP 的操作不恰当导致的。

### 看门狗不生效的BUG ###

前面找了一个版本给大家看源码，主要是为了让大家把 Demo 跑起来，毕竟引入 maven 依赖的成本是小很多的。

但是真的要研究源码，还是得把先把源码拉下来，慢慢的啃起来。

直接拉项目源码的好处我在之前的文章里面已经说很多次了，对我而言，无外乎就三个目的：

*  可以保证是最新的源码
 *  可以看到代码的提交记录
 *  可以找到官方的测试用例

好，话不多说，首先我们看看开篇说的第一个 BUG：看门狗不生效的问题。

从这个 issues 说起：

![bfd33c36f1a6d3eaecb38f1eff8b9b7f.png][]

在这个 issues 里面，他给到了一段代码，然后说他预期的结果是在看门狗续命期间，如果出现程序和 Redis 的连接问题，导致锁自动过期了，那么我再次申请同一把锁，应该是让看门狗再次工作才对。

但是实际的情况是，即使前一把锁由于连接异常导致过期了，程序再成功申请到一把新锁，但是这个新的锁，30s 后就自动过期了，即看门狗不会工作。

这个 issues 对应的 pr 是这个：

![6512db3c16901600e8c26f6a805aad57.png][]

在这个 pr 里面，提供了一个测试用例，我们可以直接在源码里面找到：

这就是拉源码的好处。

在这个测试用例里面，核心逻辑是这样的：

![267299b7f2b564a439d7797ee51bd462.png][]

首先需要说明的是，在这个测试用例里面，把看门狗的 `lockWatchdogTimeout`参数修改为 1000 ms：

![b28c25d7be1a264078f7a28b2a80ff51.png][]

也就是说看门狗这个定时任务，每 333ms 就会触发一次。

![9fec120e574ca517588b08b3a8f0a89e.png][]

然后我们看标号为 ① 的地方，先申请了一把锁，然后 Redis 发生了一次重启，重启导致这把锁失效了，比如还没来得及持久化，或者持久化了，但是重启的时间超过了 1s，这锁就没了。

所以，在调用 unlock 方法的时候，肯定会抛出 IllegalMonitorStateException 异常，表示这把锁没了。

到这里一切正常，还能理解。

但是看标号为 ② 的地方。

加锁之后，业务逻辑会执行 2s，肯定会触发看门狗续命的操作。

在这个 bug 修复之前，在这里调用 unlock 方法也会抛出 IllegalMonitorStateException 异常，表示这把锁没了：

![a319fdde949f54d062ab5e1171703bef.png][]

先不说为啥吧，至少这妥妥的是一个 Bug 了。

![51f378a63cf92207ed0f84620ea0acee.png][]

因为按照正常的逻辑，这个锁应该一直被续命，然后直到调用 unlock 才应该被释放。

好，bug 的演示你也看到了，也可以复现了。你猜是什么原因？

答案其实我在前面应该给你写出来了，就看这波前后呼应你能不能反应过来了。

首先前提是两次加锁的线程是同一个，然后我前面不是特意强调了 oldEntry 这个玩意吗：

![60ecda4f932a2dfb871fe26348580380.png][]

上面这个 bug 能出现，说明第二次 lock 的时候 oldEntry 在 MAP 里面是存在的，因此误以为当前看门狗正在工作，直接进入重入锁的逻辑即可。

为什么第二次 lock 的时候 oldEntry 在 MAP 里面是存在的呢？

因为第一次 unlock 的时候，没有从 MAP 里面把当前线程的 ExpirationEntry 对象移走。

为什么没有移走呢？

看一下这个哥们测试的 Redisson 版本：

![a391729c14c7114c8e3425ce510d7998.png][]

在这个版本里面，释放锁的逻辑是这样的：

![66084d3ea60ebcf5b5c146cd022458d9.png][]

诶，不对呀，这不是有 `cancelExpirationRenewal(threadId)` 的逻辑吗？

没错，确实有。

但是你看什么情况下会执行这个逻辑。

首先是出现异常的情况，但是在我们的测试用例中，两次调用 unlock 的时候 Redis 是正常的，不会抛出异常。

然后是 opStatus 不为 null 的时候会执行该逻辑。

也就是说 opStatus 为 null 的时候，即当前锁没有了，或者易主了的时候，不会触发 `cancelExpirationRenewal(threadId)` 的逻辑。

巧了，在我们的场景里面，第一次调用 unlock 方法的时候，就是因为 Redis 重启导致锁没有了，因此这里返回的 opStatus 为 null，没有触发 cancelExpirationRenewal 方法的逻辑。

导致我第二次在当前线程中调用 lock 的时候，走到下面这里的时候，oldEntry 不为空：

![60ecda4f932a2dfb871fe26348580380.png][]

所以，走了重入的逻辑，并没有启动看门狗。

由于没有启动看门狗，导致这个锁在 1000ms 之后就自动释放了，可以被别的线程抢走拿去用。

随后当前线程业务逻辑执行完成，第二次调用 unlock，当然就会抛出异常了。

这就是 BUG 的根因。

找到问题就好了，一行代码就能解决：

![c81c5c4789b498ec41f062cc19a3c0af.png][]

只要调用了 unlock 方法，不管怎么样，先调用 `cancelExpirationRenewal(threadId)` 方法，准没错。

这就是由于没有及时从 MAP 里面移走当前线程对应的对象，导致的一个 BUG。

再看看另外一个的 issue：

![2e20e4cb678982314777ed0e129f8db8.png][]

这个问题是说如果我的锁由于某些原因没了，当我在程序里面再次获取到它之后，看门狗应该继续工作。

听起来，说的是同一个问题对不对？

是的，就是说的同一个问题。

但是这个问题，提交的代码是这样的：

![8f246752f957148cdfc8d7562e7d8d47.png][]

在看门狗这里，如果看门狗续命失败，说明锁不存在了，即 res 返回为 false，那么也主动执行一下 cancelExpirationRenewal 方法，方便为后面的加锁成功的线程让路，以免耽误别人开启看门狗机制。

这样就能有双重保障了，在 unlock 和看门狗里面都会触发 cancelExpirationRenewal 的逻辑，而且这两个逻辑也并不会冲突。

![9b887b2aa00db0ffed72801cab2d4473.png][]

另外，我提醒一下，最终提交的代码是这样的，两个方法入参是不一样的：

![605a80b820a5412b8bf03bc827d9235c.png][]

为什么从 threadId 修改为 null 呢？

留个思考题吧，就是从重入的角度考虑的，可以自己去研究一下，很简单的。

### 看门狗导致死锁的BUG ###

这个 BUG 解释起来就很简单了。

看看这个 issue：

![3ad0593865dedb9471db4bcbfa3b076a.png][]

在这里把复现的步骤都写的清清楚楚的。

测试程序是这样的，通过定时任务 1s 触发一次，但是任务会执行 2s，这样就会导致锁的重入：

![b3ca1cb0d363ac46f98645f66a439a80.png][]

他这里提到一个命令：

主要还是模拟 Redis 处理请求超时的情况，就是让 Redis 假死 5s，这样程序发过来的请求就会超时。

这样，重入的逻辑就会发生混乱。

看一下这个 bug 修复的对应的关键代码之一：

![bf5fbf1250364f63c34984632be12be1.png][]

不管 opStatus 返回为 false 还是 true，都执行 cancelExpirationRenewal 逻辑。

问题的解决之道，还是在于对 MAP 的操作。

另外，多提一句。

也是在这次提交中，把维护重入的逻辑封装到了 ExpirationEntry 这个对象里面，比起之前的写法优雅了很多，有兴趣的可以把源码拉下来进行一下对比，感受一下什么叫做优雅的重构：

![1ca9ad8f47a0e3499c4202233bac1221.png][]

### 线程中断 ###

在写文章的时候，我还发现一个有意思的，但对于 Redisson 无解的 bug。

就是这里：

![855303211134b7e96afed63a1b04b26c.png][]

我第一眼看到这一段代码就很奇怪，这样奇怪的写法，背后肯定是有故事的。

这背后对应的故事，藏在这个 issue 里面：

![ea81472d9b653791e3868c3016ecdfcb.png][]

翻译过来，说的是当 tryLock 方法被中断时，看门狗还是会不断地更新锁，这就造成了无限锁，也就是死锁。

我们看一下对应的测试用例：

![dbd8ebd47bbc055180a9fcba332bb219.png][]

开启了一个子线程，在子线程里面执行了 tryLock 的方法，然后主线程里面调用了子线程的 interrupt 方法。

你说这个时候子线程应该怎么办？

按理来说，线程被中断了，是不是看门狗也不应该工作呢？

是的，所以这样的代码就出现了：

![980372b493228fb6a9bd7ecabbb241fc.png][]

但是，你细品，这几行代码并没有完全解决看门狗的问题。只能在一定概率上解决第一次调用后 renewExpiration 方法后，还没来得及启动定时任务之前的这一小段时间。

所以，测试案例里面的 sleep 时间，只有 5ms：

![492f442d4399b704f45cb3b741d59568.png][]

这时间要是再长一点，就会触发看门狗机制。

一旦触发看门狗机制，触发 renewExpiration 方法的线程就会变成定时任务的线程。

你外面的子线程 interrupt 了，和我定时任务的线程有什么关系？

比如，我把这几行代码移动到这里：

![aeeccfccb37c0f0359204d2275df186d.png][]

其实没有任何卵用:

![12cfc0ac723dd68ab4f773f15aa45dc0.png][]

因为线程变了。

对于这个问题，官方的回答是这样的：

![0e5c4ec2b63f04e8225827952adf7105.png][]

大概意思就是说：嗯，你说的很有道理，但是 Redisson 的看门狗工作范围是整个实例，而不是某个指定的线程。

### 意外收获 ###

最后，再来一个意外收获：

![f85d1d96c9f1c37c7dabfcdabe9f414f.png][]

你看 addThreadId 这个方法重构了一次。

但是这次重构就出现问题了。

原来的逻辑是当 counter 是 null 的时候，初始化为 1。不为 null 的时候，就执行 counter++，即重入。

重构之后的逻辑是当 counter 是 null 的时候，先初始化为 1，然后紧接着执行 counter++。

那岂不是 counter 直接就变成了 2，和原来的逻辑不一样了？

是的，不一样了。

搞的我 Debug 的时候一脸懵逼，后来才发现这个地方出现问题了。

![bb15ec339f7de3319829817289edbced.png][]

那就不好意思了，意外收获，混个 pr 吧：

![a07f984dd9b0826810512bf78c087ec3.png][]

[125f3cec9a61c11a17bd4fb13bab4028.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/1ae97518dc80412a89f1e479a6da4f46.png
[b734624aa1c87e409729fc2d47a79757.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/54c02d19cce74b7e9f0a1dd12d4fa3f4.png
[db2c70a300c314a27c95cf9f72db6802.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/8fbf123ce8054d84af8037a4962fa61b.png
[1d9c5235de28ca8e5605a338167b543a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/1e60ff6b18f7404dbc6bf7e9db603a1e.png
[67369ec1c67a6c05f122339fac1a270e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/6b941af653724248b13b578967df8689.png
[b54f682234dd517d43f51e6f599e216e.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/dd5794d8d1a544ceaa2564f3a09f3cfc.gif
[fe53b1d70a613a81fec1c0d76dbb52f3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/b9f9753f28e14bcc9ce49235561ff45b.png
[056636a073e93e9a304b6540986824f6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/36dc7fc6e610470786dbd38a7813a59f.png
[e1e716735619bb6ddf0c0c873959dd42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/4371dd77f50c4735afb8975cd1d0c229.png
[7690b1b39224ab7e60e7019bb75c9a85.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/14dfe0609a4a4125ab2e99e5e87dc9ab.png
[f8f826b823fdbf9b96fa5fe858333de6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/b784b0392345402e8195d58cfb690521.png
[05d1647b39adec5ee0085168f3627504.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/9e1642ed1f60464ea2b5d7f68b2f5048.png
[43a3649506116d5efd49b8e6f860f70e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/8f1e25f5437041bf9070399bbf23139e.png
[3b97d59a7a9461f756a474bb0870ecc7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/a622bb2a7e78469291c417b865267567.png
[6dd2de15994a117f23ec4c967554450a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/10b4f4bea50b45d3ab5af32be1dea082.png
[fdf653cf5ddaa3f50a749737b39afa57.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/681802db1e034e06b6475cc147674d3b.png
[725fe633de2623eb082e52ee5850fe53.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/f4af8bb7a36c49fbbabe5062a432072c.png
[0e217d0b343930ed92d106b3fbec45c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/4dea77252d6e49a19b291ab898bfe3d7.png
[d73a138a36cff629dce464013101b414.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/1fc2df4d914e472bb77d9baded74e63e.png
[a0ca71f83a730e923084877c055d1137.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/3df0f3e36f2847269225adec7a8b901b.png
[3c3538f04726184d0c19245e2a121944.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/d3a9351f9e6743b49877b8a732284f0e.png
[10e36041d70568be7503d85b4184849d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/791fb2a2f1d543d5af312f5be25483c7.png
[263718aedcd6a06466c6c800e81bf8c0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/9ade6971cb4f4c87a22f331af3e2477f.png
[59aa7e7cab976f1ef67c3fb326d7f624.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/02ab414a443f457f8090964213f70871.png
[afdc580c0bf0455f3858fce2dcc477cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/5307db09e5784d119b0542ca6a485397.png
[7ae58cad4456f54c57637c69cd6cec68.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/4a2b9302f00b4ed781f6e24a9b0702d7.png
[9c11113e2cf9c157ed3218aa88dcf0d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/e436a83b29c14dd5ac6982e4650c025e.png
[bfd33c36f1a6d3eaecb38f1eff8b9b7f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/dd2a264551964c1381d1937f9e8422a5.png
[6512db3c16901600e8c26f6a805aad57.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/63ff4917e14c448b8433d4d652ab8163.png
[267299b7f2b564a439d7797ee51bd462.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/c2b8be533a554c87a6473862f3197c53.png
[b28c25d7be1a264078f7a28b2a80ff51.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/09ddfff5e3ce4fb491e23b1f9390e698.png
[9fec120e574ca517588b08b3a8f0a89e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/dcddf50817e645099f5908ac96a6848c.png
[a319fdde949f54d062ab5e1171703bef.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/f6ce787405be4acc8c26920d2f50acb4.png
[51f378a63cf92207ed0f84620ea0acee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/8684f3cb900749729a99b9cafad5637a.png
[60ecda4f932a2dfb871fe26348580380.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/68e90f58b97e41cd88dd137a21267012.png
[a391729c14c7114c8e3425ce510d7998.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/550afca42235488db2a6888ec093931f.png
[66084d3ea60ebcf5b5c146cd022458d9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/5b9f3f1453de4d0db52a36aa5b7c424e.png
[c81c5c4789b498ec41f062cc19a3c0af.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/d0afc29f214e413092421fc5a0b89687.png
[2e20e4cb678982314777ed0e129f8db8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/8f1e1e125284415f82506103e8b6303e.png
[8f246752f957148cdfc8d7562e7d8d47.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/2a4eb9950ab545b68785da8f1a810651.png
[9b887b2aa00db0ffed72801cab2d4473.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/be451cc7c1fe41e49b462c0db4a0c13b.png
[605a80b820a5412b8bf03bc827d9235c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/6195bcac86aa473f86e01ca70adc3d34.png
[3ad0593865dedb9471db4bcbfa3b076a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/3a28b5485edc4198854c0c666b96f968.png
[b3ca1cb0d363ac46f98645f66a439a80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/ed1e7ca6cd4d499ca14f3d0b1e7d2e72.png
[bf5fbf1250364f63c34984632be12be1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/4faf34d722174207b37425bf02ecf51d.png
[1ca9ad8f47a0e3499c4202233bac1221.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/beab67de97844fada711e65932fdcdbf.png
[855303211134b7e96afed63a1b04b26c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/f7710252a0754ee0bb11d1593fd7a9d3.png
[ea81472d9b653791e3868c3016ecdfcb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/e7febaade5454ebe9af8c9b23af19cd4.png
[dbd8ebd47bbc055180a9fcba332bb219.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/01f639eadb904fcb9e26b8d7ed13aeeb.png
[980372b493228fb6a9bd7ecabbb241fc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/d418eb8abf954ec0b94a24ccf4a6ef71.png
[492f442d4399b704f45cb3b741d59568.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/0d5b220d7e964d18831f8f1b5f7cf5d4.png
[aeeccfccb37c0f0359204d2275df186d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/47e22ebf4e294d5f92de722a7344564e.png
[12cfc0ac723dd68ab4f773f15aa45dc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/35bfacb71db84b398b112ea076d7dd95.png
[0e5c4ec2b63f04e8225827952adf7105.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/b8bcfbd5b1084353a307b9ba93a68db0.png
[f85d1d96c9f1c37c7dabfcdabe9f414f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/11e16a387dd342f2a794c2cd9a312546.png
[bb15ec339f7de3319829817289edbced.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/956b360b95424d9092af0ef78acf213b.png
[a07f984dd9b0826810512bf78c087ec3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/1fe9b9212a614559850b375d63ad2e6f.png