Rails Session工作原理

How Rails Sessions Work
如果你的Rails应用不知道谁在访问它？如果同一个人请求两个不同的页面你不知道怎么处理？如果接到回应后所有保存的数据都消失？

对于大部分静态站点来说这没什么大不了的。但是大部分应用需要储存一些关于用户的信息。可能是user id，偏好语言或者类似于是否在ipad上呈现应用的桌面版本这样的设置。

Session是储存这类信息的完美方案。为多个请求保留的小数据量信息。

Session使用起来很简单：

session[:current_user_id] = @user.id

但是这其中蕴藏着一些魔法。什么是Session？Rails怎么知道向不同的用户呈现其对应的信息？以及如何决定存放Session信息的位置？

Session是什么？

Session是一个可以存储请求信息，使后续请求可以读取该信息的地方。

可以在一个action中设置数据：

    #app/controllers/sessions_controller.rb
    def create
    # ...
        session[:current_user_id] = @user.id
    # ...
    end

在另一个action中读取数据：

    #app/controllers/users_controller.rb
    def index
        current_user = User.find_by_id(session[:current_user_id])
    # ...
    end

Session在客户端浏览器和你的Rails应用之间进行了协调，将两者联系在了一起。而且是基于Cookie实现的。

当客户端请求页面时，服务器会在响应中设置一个Cookie

~ jweiss$ curl -I http://www.google.com | grep Set-Cookie
Set-Cookie: NID=67=J2xeyegolV0SSneukSOANOCoeuDQs7G1FDAK2j-nVyaoejz-4K6aouUQtyp5B_rK3Z7G-EwTIzDm7XQ3_ZUVNnFmlGfIHMAnZQNd4kM89VLzCsM0fZnr_N8-idASAfBEdS; expires=Wed, 16-Sep-2015 05:44:42 GMT; path=/; domain=.google.com; HttpOnly

浏览器会存储Cookie信息。在Cookie过期之前，每次发出请求时，浏览器都会将Cookie信息回传给服务器：

    ...
    > GET / HTTP/1.1
    > User-Agent: curl/7.37.1
    > Host: www.google.com
    > Accept: */*
    > Cookie: NID=67=J2xeyegolV0SSneukSOANOCoeuDQs7G1FDAK2j-    nVyaoejz-4K6aouUQtyp5B_rK3Z7G-      EwTIzDm7XQ3_ZUVNnFmlGfIHMAnZQNd4kM89VLzCsM0fZnr_N8-idASAfBEdS; expires=Wed, 16-Sep-2015 05:44:42 GMT; path=/; domain=.google.com; HttpOnly
    ...

Cookie看起来像一堆乱码，这是正常的，毕竟Cookie信息并不是给用户看的。Rails应用可以从Cookie中读取信息。Rails应用设置了它，当然也能读取它。

和Session有什么关系?

现在我们有了Cookie。在某次请求中设置了该值，在后续请求中得到同样的值。那么Cookie和Session的区别是什么呢？
默认情况下，在Rails中两者并没有很大的不同。Rails对Cookie做了处理来提高安全性，除此之外，像你预期的一样：在Rails应用中将数据存入Cookie，也可以将其取出来。从这一点来说，Session和Cookie确实没有任何区别。
(译注：这里指在Rails中的用法没有任何区别，而非概念上没有任何区别)

但是Cookie不总是存储Session数据的理想方案：

只能在Cookie中存储4kb的数据。
通常情况下够了，但有时不满足
Cookie在你每次发出的请求中携带。
大的Cookie信息意味着更大数据量的请求(request)响应(reponse)，意味着更慢的网站。
如果不小心暴露了secret_key_base，用户可以修改Cookie中的信息。
当Cookie中包含类似current_user_id这样的信息时，每个人都可能进行身份冒充。
在Cookie中保存错误类型的数据是不安全的。
如果小心一点，没有什么大问题。

当你因为以上一些原因不能选用Cookie来保存Sessio信息时，Rails还提供了其他一些方式来保存Session信息。
(译注：通常使用cookie来保存session_id)

可选择的Session存储方案

其他的Session存储方案和使用Cookie储存Session的方式类似。我们来举一个真实的例子帮助理解。
如果使用ActiveRecord纪录Session
1. 当调用session[:current_session_id] = 1时，Session实际上还没有存在。
2. Rails会在session表中使用随机的Session id(例如：09497d46978bf6f32265fefb5cc52264)插入一条新纪录。
3. 保存{current_user_id: 1}（base64编码）在该记录的data属性中。
4. 将生成的session id（09497d46978bf6f32265fefb5cc52264）使用set-cookie返回给浏览器。

下次发出请求时，
1. 浏览器使用Cookie头向服务器发送同样的Cookie信息（Cookie: _my_app_session=09497d46978bf6f32265fefb5cc52264;
path=/; HttpOnly）
2. 当调用session[:current_user_id]时
3. 服务器取出cookie头中的session id，并在sessions表中找到这条纪录。
4. 然后，返回该记录data属性的包含的current_user_id信息。

不管你将Session存储在数据库，memcached，redis或者其他的地方，几乎都遵循以上的过程。Cookie只存储session id，Rails应用使用session id在Session存储中查找相应的数据。

cookie存储，缓存存储还是数据库存储？

如果满足需求的话，将Session信息存储在Cookie中是最简单的方法。不需要额外的构造或者设置。
但是如果需要将Session从Cookie存储中移出的话，你有两个选项。
存储在数据库或存储在缓存。

在缓存中存储session信息

你可能已经使用了类似于memcache之类的来缓存你的局部页面或数据。考虑到缓存相关信息已经配置过了，缓存存储是存储Session数据第二简单的方式

不用担心Session存储增长过快，因为当缓存信息过大时，旧的Session信息会被自动清除。而且因为数据存储在缓存中类似于在内存中，访问速度是很快的。

但是这也不完美

如果需要保存旧的Session信息，你可能不想让它们在缓存信息过多时被清除。
Session和缓存数据争夺空间。如果没有足够的空间，你可能面临缓存缺失和Session过早过期的问题。
如果需要重置缓存时（例如升级rails，旧的缓存数据不再可用），只能将所有的Session信息过期。

在数据库中存储session信息

如果想存储Session信息直到它真正失效，应该考虑将其存储在数据库中。无论是Redis，AcitiveRecord或者是其他的形势。

但是数据库存储也存在短板：
- Session不能被自动清除（只能亲自清除过期的Session）
- 需要了解Session数据满溢时，数据库如何表现
- 创建Session是更加小心，否在会在数据库中填满无用的Session信息

应该怎样存储Session信息？

如果不在意Cookie存储带来的限制，那就用它。毕竟它不需要过多配置，并且维护简单。

存储在缓存中还是在数据库中，取决于怎样看待Session过早失效的问题。我认为Session信息本来就应该是暂时的，所以更倾向于将其存在缓存中。

所以我的选择顺序一般是优先cookie,其他缓存，最后考虑数据库。

秒客网