据我了解，使用粘性会话是为了将用户路由到相同的后端，这样他们就不必在每次重新路由时再次登录，或者如果他们有购物车，他们就不会丢失他们的物品等。但我也知道最佳做法是不将状态存储在后端服务器上，在这种情况下，建议将会话存储在数据库或内存数据库中。对吗？如果是这样，那么在将状态存储在数据库中时使用粘性会话有什么意义吗？
答案1
粘性会话的目的通常是为了确保用户始终被引导到同一个后端，前提是后端处于启动状态（并且通常如果后端关闭，您会希望用户转到任何其他后端！）
考虑到这一点，如果后端出现故障、重新启动或消失、正在升级或出现问题，您的用户最终会使用不同的后端，因此如果您仅在后端存储会话数据，那么用户就会丢失他的会话数据（必须重新登录、丢失购物车等）。
因此，在所有情况下，会话都需要在后端之间复制（如果保存在后端的内存中）或者保存在会话存储中，如 Redis、Memcached、RDBMS 等。如果不这样做，那么您的服务水平就会相对较差。
现在，即使您将会话保存在后端外部的会话存储中，是否需要粘性会话？
这实际上取决于您的环境、架构、设计等。它对您来说可能有意义，也可能没有必要。
除了会话之外，可能还有其他事情需要使用粘性会话。假设您有一个处理文件的 Web 服务。用户上传文件，然后由多个后端之一进行处理。在初始调用之后，会进行其他调用来检查文件处理的状态。状态请求需要发送到处理文件的后端。粘性会话会对此有所帮助。如果后端死机，文件处理当然会停止，下一个状态请求会返回类似“您的工作不再存在！”的内容。
当然，您也可以将状态更新存储在数据库中（例如 Redis 或其他类似的东西），然后状态请求可以发送到任何后端。但这更复杂，而且更复杂并不总是必要的。
一般来说，我认为如果您的设置非常小，用户群很小，那么粘性会话通常比带有会话存储的更复杂的基础架构更好。您可能要运行多个后端，以保持较高的正常运行时间。因此，如果您有外部会话存储，您也必须使其具有 HA……现在您的系统的复杂性增加了。
这就是我喜欢 IT 的原因 — — 一切取决于...