SpringCloud（28. 分布式会话与分布式事务）_springcloud会话管理

上一篇：27. Redis 和 ZK 分布式锁

1. 集群部署时的分布式 session 如何实现？

1. 完全不用 session

• 使用 JWT Token 储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓。

2. tomcat + redis
- 使用 Tomcat RedisSessionManager ，让所有我们部署的 tomcat 都将 session 数据存储到 redis 即可。
- 该方法与 Tomcat 高耦合，较少使用

3. spring session + redis

• 现在比较好的还是基于 Java 一站式解决方案，也就是 spring。人家 spring 基本上承包了大部分我们需要使用的框架，spirng cloud 做微服务，spring boot 做脚手架，所以用 sping session 是一个很好的选择。
• 给 sping session 配置基于 redis 来存储 session 数据，然后配置了一个 spring session 的过滤器，这样的话，session 相关操作都会交给 spring session 来管了。接着在代码中，就用原生的 session 操作，就是直接基于 spring sesion 从 redis 中获取数据了。
• 下面是配置与代码示例:

  • 在 pom.xml 中配置：

    <dependency>
      <groupId>org.springframework.session</groupId>
      <artifactId>spring-session-data-redis</artifactId>
      <version>1.2.1.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>redis.clients</groupId>
      <artifactId>jedis</artifactId>
      <version>2.8.1</version>
    </dependency>
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10

  • 在 spring 配置文件中配置：

    <bean id="redisHttpSessionConfiguration"
         class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
        <property name="maxInactiveIntervalInSeconds" value="600"/>
    </bean>
    
    <bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
        <property name="maxTotal" value="100" />
        <property name="maxIdle" value="10" />
    </bean>
    
    <bean id="jedisConnectionFactory"
          class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" destroy-method="destroy">
        <property name="hostName" value="${redis_hostname}"/>
        <property name="port" value="${redis_port}"/>
        <property name="password" value="${redis_pwd}" />
        <property name="timeout" value="3000"/>
        <property name="usePool" value="true"/>
        <property name="poolConfig" ref="jedisPoolConfig"/>
    </bean>
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19

  • 在 web.xml 中配置：

    <filter>
        <filter-name>springSessionRepositoryFilter</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>springSessionRepositoryFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    1
    2
    3
    4
    5
    6
    7
    8

  • 示例代码：

    @RestController
    @RequestMapping("/test")
    public class TestController {
    
        @RequestMapping("/putIntoSession")
        public String putIntoSession(HttpServletRequest request, String username) {
            request.getSession().setAttribute("name",  "leo");
            return "ok";
        }
    
        @RequestMapping("/getFromSession")
        public String getFromSession(HttpServletRequest request, Model model){
            String name = request.getSession().getAttribute("name");
            return name;
        }
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16

2. 分布式事务方案

2.1 两阶段提交方案/XA方案

• 所谓的 XA 方案，即：两阶段提交
• 有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。
• 这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。
• 其次，该方法现在很少用到，因为一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。
  

2.2 TCC 方案

• TCC 的全称是：Try、Confirm、Cancel。

  • Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留
  • Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
  • Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）

• 这种方案说实话几乎很少人使用，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。

• 比如，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，会用 TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，保证在资金上不会出现问题。而且最好是你的各个业务执行的时间都比较短。

• 但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码是很难维护的
  

2.3 本地消息表

• 这个大概意思是这样的：

  • A 系统在自己本地一个事务里操作同时，插入一条数据到消息表（业务表和消息表同时插入）；
  • 接着 A 系统将这个消息发送到 MQ 中去；
  • B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，然后执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
  • B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
  • 如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；

• 这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。

• 这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的，如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。
  

2.4 可靠消息最终一致性方案

• 这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。

• 大概的流程就是：

  • A 系统发送一个HalfMsg到消息中间件。此时 B 系统无法立刻消费HalfMsg，只有当Commit了HalfMsg后， B 系统才能消费到这条消息。
  • A 系统执行本地事务。
  • 如果A 系统执行本地事务成功，就向消息中间件发送一个Commit消息，将HalfMsg的状态修改为【已提交】，然后通知 B 系统执行事务；
  • 如果A 系统执行本地事务失败，就向消息中间件发送一个Rollback消息，将 HalfMsg 的状态修改为【已取消】。
  • 并且消息中间件会定期去向 A 系统 询问，是否可以Commit或者Rollback那些由于错误没有被终结的HalfMsg，以此来结束它们的生命周期，以达成事务最终的一致。之所以需要这个询问机制，是因为A 系统 可能提交完本地事务，还没来得及对HalfMsg进行Commit或者Rollback，就挂掉了，这样就会处于一种不一致状态。
  • B 系统消费完消息后，可能因为自身异常，导致业务执行失败，此时就必须要能够重复消费消息。RocketMQ提供了ACK机制，即RocketMQ只有收到 B 系统 的ack message后才认为消费成功。所以， B 系统 可以在自身业务员逻辑执行成功后，向RocketMQ发送ack message，保证消费逻辑执行成功。

2.5 最大努力通知方案

• 这个方案的大致意思就是：
  • 系统 A 本地事务执行完之后，发送个消息到 MQ；
  • 这里会有个专门消费 MQ 的最大努力通知服务，这个服务会消费 MQ 然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统 B 的接口
  • 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。