会话是否可以在Heroku上使用多个web dynos?

如果您在Heroku上运行带有多个Web dynos的Rails 3应用程序,

  1. 每次你点击应用程序,你通常会连接不同的网络动态?
  2. 会话可以在不同的网络动态中工作吗?
  3. 它适用于不同的Rails会话存储(ActionDispatch :: Session :: CookieStore,ActiveRecord :: SessionStore和ActionDispatch :: Session :: CacheStore)

简而言之 – 会话将适用于多个网络动态。

Sessions可以在Web dynos上运行 – 因为Rail的会话支持设计允许它。 如果有的话,web dyno模型正是Rail的横向扩展方式。

1.每次点击应用程序时,您是否通常使用不同的网络dyno连接?

基于heroku文档:

路由网格负责确定应用程序在dyno流形中的web dynos的位置,并将HTTP请求转发给其中一个dynos。 使用随机选择算法执行Dyno选择。

所以dyno选择是随机的……但是dyno必须安装你的应用程序。 因此,如果您有多个dyno,那么您最终可能会连接到不同的dyno(这很重要,因为这有助于实现负载平衡和高可用性)

2.会话可以跨越不同的网络动态吗?

是。 大多数Web堆栈通过执行以下操作来支持会话:

  1. 分配会话ID – 这是一个唯一的ID,通常将其设置为会话cookie,以便浏览器始终将带有任何HTTP请求的id发送给原始主机
  2. 提供将会话ID映射到实际会话数据的存储

因此,通过此过程,可以支持会话,因为每个入站HTTP请求都具有会话ID,当处理您的请求时,Web dyno可以访问该会话ID。

3.它适用于不同的Rails会话存储(ActionDispatch :: Session :: CookieStore,ActiveRecord :: SessionStore和ActionDispatch :: Session :: CacheStore)

ActionDispatch :: Session :: CookieStore是的。 cookie存储将加密的会话数据存储为cookie。 因此,您的浏览器会将所有会话数据(加密)发送回主机,然后解密,以便在您的应用中使用。

ActiveRecord :: SessionStore是的。 cookie存储将加密的会话数据存储在数据库表中。 然后将ID指定为cookie。 因此,您的浏览器将ID发送到主机,然后用于从数据库加载会话数据。 由于所有Web dynos都与DB连接,这意味着它也受支持。

ActionDispatch :: Session :: CacheStore是的但您需要一个缓存存储服务(例如MemCache插件)。 Cookie存储将加密的会话数据存储在缓存存储(memcache)中,缓存存储是所有Web dynos中的共享服务。 然后将ID指定为cookie。 因此,您的浏览器将ID发送到主机,然后用于从缓存存储(memcache)加载会话数据。

我不相信Heroku会努力将连续的请求发送到同一个web dyno。 我可能错了,他们付出了一些努力,但即使他们这样做,也不可能有足够的可靠性来指望会话管理。

但是,ActionDispatch :: Session :: CookieStore肯定会起作用,因为数据存储在加密的客户端cookie中。 ActiveRecord :: SessionStore将起作用,因为数据存储在数据库中,数据库可能由所有Web dynos共享。 如果您使用在所有客户端或类似共享缓存之间共享的MemCached服务器,则ActiveDispatch :: Session :: CacheStore应该可以正常工作。

唯一不起作用的是本地文件系统上的某种基于文件的会话存储,而像多个Heroku dynos这样的情况正是这种类型的会话存储在现代Web应用程序中不常见的原因。