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
- 当调用session[:current_session_id] = 1时，Session实际上还没有存在。
- Rails会在session表中使用随机的Session id(例如：09497d46978bf6f32265fefb5cc52264)插入一条新纪录。
- 保存{current_user_id: 1}（base64编码）在该记录的data属性中。
- 将生成的session id（09497d46978bf6f32265fefb5cc52264）使用set-cookie返回给浏览器。
下次发出请求时，
- 浏览器使用Cookie头向服务器发送同样的Cookie信息（Cookie: _my_app_session=09497d46978bf6f32265fefb5cc52264;
path=/; HttpOnly） - 当调用session[:current_user_id]时
- 服务器取出cookie头中的session id，并在sessions表中找到这条纪录。
- 然后，返回该记录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,其他缓存，最后考虑数据库。
