Spring事务原理篇

青旅半醒 2023-01-06 05:45 77阅读 0赞

上一篇讲聊了一下Spring的事务使用，这一篇我们聊聊Spring的事务原理。  
Spring的事务分为编程式事务以及声明式事务。声明式事务就是我们常用的@Transactional注解，关于该注解的使用，可以参考上一篇。说到事务，有经验的朋友就会想到事务的ACID属性，ACID属性是用来描述数据库的事务，Spring的事务和数据库的事务有什么关系呢？实际上，Spring事务实现底层还是依赖数据库的事务，只不过，Spring对常用数据库的事务进行了封装，方便我们使用。先来画一下Spring事务体系的类图，对后面的源码分析会有帮助：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70]

实际上，真正起事务作用的是最底层的DatasourceTransactionManager、hibernateTransactionManager等  
这几个类分别对哪些持久化技术生效呢?  
DatasourceTransactionManager：jdbcTemplate、JPA  
hibernateTransactionManager：hibernate  
下面看一下，以下使用事务的几种场景  
***第一种，事务方法被private修饰***  
![在这里插入图片描述][20210115083312973.png]  
如果对AOP技术了解的话，这种失效场景其实非常容易理解。AOP技术底层依赖的是动态代理技术。动态代理技术分为两种：  
JDK的动态代理以及Cglib动态代理。动态代理的内容，可以参考我前几篇的博客，有过描述。JDK动态代理依赖接口，Cglib动态代理依赖继承。而私有方法，在这两种情况下，肯定是无法被代理的。但凡事无绝对，从极客时间的专栏上听说了一种<AspectJ静态织入>，这种技术据说可以实现私有方法的代理，有了解的大佬，希望分享一下。  
***第二种，类方法自调用***  
看一个例子

//接口
    public interface TransactionTest { 
        void addOrder(String orderId,String orderName);
        void addMessage(String orderId,String orderName);
    }

//实现类
    @Service
    public class TransactionTestImpl implements TransactionTest { 
        @Override
        @Transactional(rollbackFor = RuntimeException.class,propagation = Propagation.REQUIRED)
        public void addOrder(String orderId, String orderName) { 
            JdbcTemplate jdbcTemplate = (JdbcTemplate) BeanUtils.getBean("jdbcTemplate");
            jdbcTemplate.update("insert into trans_order values (?,?)",new Object[]{ orderId,orderName});
            addMessage(orderId,orderName);
            throw new RuntimeException("订单服务出现异常");
        }
    
        @Override
        @Transactional(rollbackFor = RuntimeException.class,propagation = Propagation.REQUIRED)
        public void addMessage(String orderId, String orderName) { 
            JdbcTemplate jdbcTemplate = (JdbcTemplate) BeanUtils.getBean("jdbcTemplate");
            jdbcTemplate.update("insert into trans_message values (?,?)",new Object[]{ orderId,orderName});
        }
    }

//测试类
    	@Test
        void testSimpleLoad() { 
            ApplicationContext applicationContext = new ClassPathXmlApplicationContext("beanFactoryTest.xml");
            TransactionTest transactionTest = (TransactionTest) applicationContext.getBean("transactionTestImpl");
            transactionTest.addOrder("1","订单一个");
        }

新建两张表  
![20210115084653300.png][]  
addOrder方法和addMessage方法都使用了@Transactional注解修饰，addOrder方法内部调用了addMessage方法。  
大家思考一下，这种情况下，哪张表里会有数据呢？  
我们测试一下  
![20210115085346602.png][]![20210115085447639.png][]  
**结果**：两张表都没有数据  
**原因**：我们在addOrder内部直接调用addMessage方法，其实就是this调用。this调用，是不会走代理的，不走代理，是无法实现事务增强的，自然也就没有事务，上面的代码等价于：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 1][]  
看一下Spring日志(***调试事务代码时，建议打开spring的部分debug日志，以便观察事务操作***)  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 2]  
自始至终，只有一个事务存在。所以我们的addMessage方法的事务根本就没有产生。  
所以当出现异常的时候，事务回滚，会将两个数据库操作一起回滚，所以两张表里都没有事务。  
这里，扩展一下，如果我们不想让addMessage方法回滚，应该怎么做呢？比如addMessage是一个记录日志的附属功能。当发生异常时，我们也要向库里插入日志，此时就不能让addMessage方法进行回滚。我们就可以将事务的传播级别改为Propagation.REQUIRES\_NEW。此时，Spring事务就不会回滚。  
![在这里插入图片描述][2021012009185640.png]  
我们测试一下：  
![20210120124948294.png][]![20210120125004236.png][]  
结果显示，成功。主业务回滚，记录日志的事务提交  
我们看一下Spring输出的日志，从源码层级看一下，Spring都做了哪些工作？

//给addOrder方法创建一个新事务
    12:47:35.323 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Creating new transaction with name [com.thinking.bean.test.TransactionTestImpl.addOrder]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT,-java.lang.RuntimeException
    //Druid数据源初始化
    12:47:36.782 [Test worker] INFO  c.a.d.p.DruidDataSource - { dataSource-1} inited
    //从DataSourceTransactionManager实现上获取一个数据库物理连接
    12:47:36.791 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Acquired Connection [com.mysql.jdbc.JDBC4Connection@52757985] for JDBC transaction
    //关闭数据库的自动提交属性，改为手动提交事务
    12:47:36.802 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Switching JDBC Connection [com.mysql.jdbc.JDBC4Connection@52757985] to manual commit
    //开始执行目标SQL语句
    12:47:36.806 [Test worker] DEBUG o.s.j.c.JdbcTemplate - Executing prepared SQL update
    12:47:36.807 [Test worker] DEBUG o.s.j.c.JdbcTemplate - Executing prepared SQL statement [insert into trans_order values (?,?)]
    //关键点。suspend是挂起的意思。这一行日志显示，Spring挂起了主业务的事务。然后又给addMessage方法创建了一个新的事务
    12:47:36.902 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Suspending current transaction, creating new transaction with name [com.thinking.bean.test.TransactionTestImpl.addMessage]
    //从DataSourceTransactionManager实现上获取一个数据库物理连接
    12:47:36.903 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Acquired Connection [com.mysql.jdbc.JDBC4Connection@27212cf] for JDBC transaction
    //关闭数据库的自动提交属性，改为手动提交事务
    12:47:36.904 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Switching JDBC Connection [com.mysql.jdbc.JDBC4Connection@27212cf] to manual commit
    //开始执行目标SQL语句
    12:47:36.905 [Test worker] DEBUG o.s.j.c.JdbcTemplate - Executing prepared SQL update
    12:47:36.905 [Test worker] DEBUG o.s.j.c.JdbcTemplate - Executing prepared SQL statement [insert into trans_message values (?,?)]
    12:47:37.223 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Initiating transaction commit
    //提交addMessage方法的事务
    12:47:37.224 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Committing JDBC transaction on Connection [com.mysql.jdbc.JDBC4Connection@27212cf]
    //释放addMessage方法关联的数据库连接
    12:47:37.270 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Releasing JDBC Connection [com.mysql.jdbc.JDBC4Connection@27212cf] after transaction
    //当内部事务执行完毕后，继续执行挂起的事务。意思是：执行完了addMessage方法的事务，继续执行之前被挂起的addOrder的事务
    12:47:37.271 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Resuming suspended transaction after completion of inner transaction
    12:47:37.272 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Initiating transaction rollback
    //遇到异常，回滚事务
    12:47:37.272 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Rolling back JDBC transaction on Connection [com.mysql.jdbc.JDBC4Connection@52757985]
    //释放addOrder方法关联的数据库连接
    12:47:37.318 [Test worker] DEBUG o.s.j.d.DataSourceTransactionManager - Releasing JDBC Connection [com.mysql.jdbc.JDBC4Connection@52757985] after transaction

我把每一行日志都加上了注释，相信你能够看懂Spring事务的整个处理过程。整个过程，其实很简单。文章的末尾会结合源代码对这部分流程做一个更为详细的分析。有兴趣的同学，可以直接拉到末尾看一下。  
上面的这个例子是主业务流程回滚，记录日志的子流程提交。那如果反过来呢？也就是主流程提交，子流程抛异常回滚，该怎么做呢？这种情况，我这里就不演示了，读者可以自己实验一下。提一点：这种情况，有2个注意点，一个是我们要注意捕获子流程的异常，防止异常传播到主流程中，除此之外，我们还得注意标记子流程的事务传播属性为：REQUIRE\_NEW，和主事务的事务区分开，防止两种事务互相影响。  
***Spring事务，主事务回滚，子事务不回滚的Spring源码实现分析***  
下面接着看Spring事务使用不当导致的事务不生效场景  
***第三种，异常抛出类型不当***  
看一个例子  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 3][]  
这种情况，异常会回滚吗?答案也是否定的，我们看一下日志  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 4][]  
日志中，很清晰的显示了事务的提交。那为什么抛出SqlException没有发生回滚呢？我们从源码里找一下答案。  
我们写的测试类，从Spring容器里获取了一个代理对象，transactionImpl。接着，代理对象执行addOrder方法。我们以JDK动态代理举例，此时会执行JdkDynamicAopProxy的invoke方法，invoke方法里有一行代码，我们要注意一下：  
![20210115091925715.png][]  
这行代码就是获取interceptor链的方法。在执行我们的目标方法前，会遍历这个list集合，把所有符合条件的拦截器执行一下，形成对方法的增强。事务方法执行的时候，也不例外，也会有很多拦截器链，用来对该方法进行增强。其中有一个很重要的拦截器，TransactionInterceptor。该拦截器完成了事务操作，实际业务逻辑在invoke方法中，如下：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 5][]  
我们直接找我们关心的代码，抛出SqlException后，Spring事务做了什么操作？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 6]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 7]  
![在这里插入图片描述][2021012009052215.png]  
答案很明显了，默认情况下，Spring事务只回滚unchecked Exception。SqlException是checkedException，所以不会滚。我们可以在@Transactional注解中添加(rollbackFor = Exception.class)来突破Spring的限制，当程序抛出SqlException也能进行回滚  
***第四种，捕捉了业务异常***  
上面，我们分析SqlException不回滚的原因时，可以看到：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 8]  
Spring事务执行我们写的业务方法时，会捕捉顶层异常Throwable，然后执行回滚操作。所以，如果我们自己捕捉了业务异常，Spring事务捕捉不到异常，此时就不会执行回滚操作。

***Spring事务，主事务回滚，子事务不回滚的Spring源码实现分析***  
首先，我们进入到TransactionInterceptor的invoke方法，这是Spring事务开始的入口。之后进入TransactionAspectSupport的invokeWithinTransaction方法。  
先获取事务的属性，也就是@Transactional注解的属性。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 9]  
紧接着，我们看声明式的事务处理(注解的方式就是声明式)  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 10]  
进入createTransactionIfNecessary方法  
获取事务名称，默认是方法的全路径名  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 11]  
紧接着，开始执行AbstractPlatformTransactionManager的getTransaction方法开始获取数据库的事务  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 12]  
因为我们用的是jdbcTemplate，所以对应的事务管理器实现类是DataSourceTransactionManager。我们进入它的doGetTransaction方法。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 13]  
从当前线程中获取连接持有器。可以看到线程持有一个Map<object,object>对象。  
key是数据源对象，value是连接持有器对象ConnectionHolder  
![在这里插入图片描述][20210126134359639.png]  
如果是新事务，则该持有器对象为null。  
紧接着，开始执行事务，执行startTransaction方法，利用现有参数，创建一个TransactionStatus对象。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 14]  
关闭事务的自动提交  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 15]  
将当前数据库事务连接绑定到当前线程。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 16]  
至此，Spring事务创建成功，主脉络大概就是这个样子。下面聊一下Spring事务的提交和回滚。Spring的数据库事务最终封装到了TransactionStatus对象中，TransactionStatus对象最终又封装到了TransactionInfo对象中。  
我们看一下这两个类的类图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 17]  
事务创建成功之后，开始执行第一个目标方法  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 18]  
之后，获取当前业务类的代理对象，执行addMessage方法。流程同上，因为addMessage方法同样会被@Transactional注解修饰，所以该方法同样会被Spring事务增强。  
当前线程已经有了一个addOrder方法的事务，所以再次创建事务时，Spring事务判断当前线程已经持有了事务，会先将当前事务挂起，然后根据事务的传播属性不同分别对第二个事务进行不同的处理。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 19]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 20]  
挂起的动作比较简单，就是将第一个事务的信息从当前线程移除，但是保留已挂起事务信息的引用，以便后期处理挂起的事务。  
紧接着，addMessage方法执行完毕，开始提交addMessage的事务  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 21]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 22]  
之后具体的事务提交方法是processCommit方法，在这个方法执行之前，Spring预留了很多扩展接口，方便我们在事务提交前进行一系列预处理动作。之后，从TransactionStatus对象中获取到数据库连接，将事务提交  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 23]  
addMessage方法的事务提交完毕后，开始处理挂起的addOrder方法的事务。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 24]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 25]  
处理挂起事务的操作，其实也很简单。就是找到之前挂起的事务资源，重新绑定到当前线程中，然后再把之前的TransactionInfo对象重新设置回ThreadLocal对象中，然后执行正常的操作，如果有异常，回滚，无异常，提交事务。  
我们在addMessage方法执行完毕后，主动抛了一个RuntimeException，所以addOrder事务会回滚。我们看一下回滚的操作。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 26]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 27]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 28]  
本质其实也还是利用数据库的连接进行回滚操作。  
写了这么多，我们来总结一下：  
Spring的声明式事务，利用AOP技术对目标方法进行增强。通过简单的配置@Transactional注解就实现了方法内多个数据库的事务操作。事务的传播属性是Spring事务的重点，我们一定要熟悉传播属性，进而在实际的业务场景中灵活使用。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70]: /images/20221119/488922036d4c482eb21c1196b784ed63.png
[20210115083312973.png]: /images/20221119/5ddc32e42f134caaab5bde5cc381ccbb.png
[20210115084653300.png]: /images/20221119/25eb6ff940d2486994215b3ed8bd9c8b.png
[20210115085346602.png]: https://img-blog.csdnimg.cn/20210115085346602.png
[20210115085447639.png]: /images/20221119/5389a28ec82e43a6b5a5ac16ef4ea2bf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 1]: /images/20221119/b4b693737ecc4803867b0fec41f7de4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 2]: /images/20221119/3344cb3a33e14302851245cb0de954ce.png
[2021012009185640.png]: /images/20221119/f17b96e0417d4f5b9f260f6b25dccc26.png
[20210120124948294.png]: https://img-blog.csdnimg.cn/20210120124948294.png
[20210120125004236.png]: /images/20221119/cca5ead4f04348c7ad94788eaa2bd79b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 3]: /images/20221119/c7bf33711b1e4b1c9d9b957aabc9e0fd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 4]: /images/20221119/abf9df497f6d419d9e36ec004c004f0e.png
[20210115091925715.png]: /images/20221119/5a33ede94b254a7580216871f3c00eb7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 5]: /images/20221119/cc7ae3e9ef124fa1a1994d255cfbfeaf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 6]: /images/20221119/5fcba4dd538a4e1bb442961d077aba02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 7]: /images/20221119/f2a4cd0067e448758116b298e69b32a9.png
[2021012009052215.png]: /images/20221119/295395d44811403f8ccdb682e9183dbe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 8]: /images/20221119/78c06241c9b24ec9bdd4008c48532d09.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 9]: /images/20221119/ebaa0e97b1294a10abb0acde4a0dc47a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 10]: /images/20221119/23159ff819a64f5ea299023142c4cdf5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 11]: /images/20221119/aa175fbb80664dbeb03c2c2caa8612ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 12]: /images/20221119/2e888dd4a3b24ef58cd087258bce8e0e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 13]: /images/20221119/62530877bcda47cba153011489c07cc0.png
[20210126134359639.png]: /images/20221119/9c4e1a529a8c453cbaae5a8bfbc9758d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 14]: /images/20221119/3c2b2dac4d2f49519ae35c69a624dc87.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 15]: /images/20221119/5d956c6e78654d1e943c1de1b1beff5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 16]: /images/20221119/1c6e2f921cf049b5b4b10cf5b9341de4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 17]: /images/20221119/838a1ec1946f4ed0b242e6f2c8048082.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 18]: /images/20221119/5b6f33577d9540559b59df16fb67e621.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 19]: /images/20221119/e18993ec1a404edda98265dba428e082.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 20]: /images/20221119/9d0891ed18594ffa8952b75f885cad5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 21]: /images/20221119/28fe8d9ae2bb4d0ab52d05ff178f19e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 22]: /images/20221119/160e8e055145411ca67981da3b253d3a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 23]: /images/20221119/42bb1454823640fdb7f7403bb34b920f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 24]: /images/20221119/d1754fe1635543789b4b7f7a36e606db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 25]: /images/20221119/d2f48fa703f54f0f9625cdb803ece903.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 26]: /images/20221119/dbdb62582e5a4cb3a9113cc0dd5aab82.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 27]: /images/20221119/dd632e1ca5ba49b781b7c389c68a18c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODM5MDc1_size_16_color_FFFFFF_t_70 28]: /images/20221119/f81a0b206c6042cb8ffc13a825d10820.png