会话状态和粘性会话

HELLO大家好，当我们使用弹性负载均衡器时，负载均衡器后面的EC2 实例上的应用程序通常是无状态的，无状态意味着应用程序不会在EC2实例上存储信息，即便有的场景会暂时将数据存储在实例的缓存中，但那些也不是持久化的数据。这是最佳实践。

为什么一般不会在EC2上存储信息呢？因为在弹性负载均衡器后面的EC2实例，通常会因为某些情况终止，并启动新的实例替代。所以终止实例上存储的信息就会丢失；另外用户访问ELB后的实例时，也要有某种技术能够保证，同一个用户访问的是同一个实例，不然用户在实例A生成了一些数据，下次访问如果被ELB轮询访问到实例B了那也会有问题。

存储会话状态

因此，我们就会使用到某些技术特性，比如如果我们确实需要存储一些会话数据，我们通常将其存储在 EC2 实例的外部，这样的话如果一个用户访问时被重定向到另一个新实例，那么这个用户也不会重新进行认证。我们还会用到粘性会话的特性，来解决上述的问题。

我们来看下前面提到的几种技术特性，主要是使用在有弹性负载均衡器的场景。

第一种方式是在外部存储我们的会话状态数据，我们来一起看一下。

假设我们有一个负载均衡器，在其后面我们有一些实例，用户连接到其中一个实例，然后，用户会进行身份验证并获得一些可用于访问应用程序的身份验证凭据,或者用于运行在EC2实例上的WEB应用程序连接其他服务的验证凭据。那在这种情况下，这类的数据就可以存储在某些外部的服务中，比如DynamoDB就是其中之一。

在这种情况下，身份验证详细信息存储在 DynamoDB 表中，如果该实例出现问题，用户会被定向到另一个实例，然后就可以在DynamoDB表中检索那些身份验证凭据并继续正常访问，而不需要再次登录，从可用性的角度来看，这也是非常好的事情。

这类的数据，我们称之为会话状态数据，它通常用于身份验证凭据和其他各种与特定会话相关的信息。通过这种方式，该数据不会丢失或需要重新生成。

ElastiCache 是另一种用于存储会话状态数据的解决方案。因此，对于会话状态数据的存储，AWS 解决方案通常是 DynamoDB 表、ElastiCache，以及在某些情况下会使用Amazon S3。

粘性会话

另一种技术是所谓的粘性会话，我们一起来看一下。

同样，假设我们有一个负载均衡器，在其后面我们有一些实例，开启粘性会话的情况下，用户连接到其中一个实例，然后生成了一个 cookie。

客户端的访问在cookie的整个生命周期内都会绑定到这个特定的 EC2 实例。因此，如果他们的连接由于某种原因被断开并且他们重新连接，则 cookie 将继续告诉负载均衡器将该客户端的会话发送到哪个 EC2 实例。这样的话就保证了即便在使用负载均衡器的情况下，每个客户端和EC2的连接即便中断重连，也会连接到相同的实例。

那如果不使用粘性会话功能呢？客户端和EC2的连接中断后，重新连接后，那就非常有可能就连接到其他的实例了，大家理解吧？

在这种情况下，诸如身份验证详细信息之类的会话状态数据，如果存储在EC2 实例本地，因为开启了粘性会话，会话状态在下次客户端重新连接时也不会丢失，不需要重新登录；但是，如果这个实例出现问题，那么这个用户访问就会被重新分配到其他的实例，这也就意味着这些会话状态数据将丢失。

因此，这不是一个完美的解决方案，但在许多场景上也会经常用到粘性会话这个特性。

您也可以将粘性会话与外部存储一起用于会话状态数据。通常，它们会单独使用，但您可以一起使用它们。

什么场景下需要同时使用两者？比如有一些数据可能会存储在实例本地，而可能有其他的一些数据可能更适合外部存储。

当然，对于外部存储，与其通信肯定会有一点点延迟，因此，您必须考虑这是否适合您的特定场景。

好的，以上就是本课时的内容，希望能给大家带来帮助。