1）serializeUser正在过滤数据并将其存储在会话cookie中。如果可以的话，通常在cookie中的存储量较少。无论如何，您都将调用db来获取有关用户的数据，因此您可以仅存储用于检索和重建用户的ID，如在deserializeUser中所示。
客户端将cookie中的请求提供给服务器，服务器将cookie反序列化为数据，解密cookie内容或从数据库中检索用户数据。然后，响应返回到服务器，对客户端数据进行序列化，清除您不会存储在cookie中的内容，并将其放入db中，仅在cookie中保留一个ID。
如果您要进行加密，则可以通过运行多台需要解密数据的机器来扩展规模，这很容易搞砸（不是很困难，但是不必要的复杂性）
最好仅在cookie中放置未加密的数据，并且cookie中的任何内容都可以为用户增加额外的带宽使用量。
2）数据库调用应该非常快，如果不是这样，无论如何，您将在其他地方遇到痛苦的用户体验。换句话说，我的强烈观点是，有一个压倒一切的观点是远离cookie。
考虑到cookie是随每个请求一起发送的；这样会更明智，而不是将数据推送到会话中并使其增加开销，而是在用户发出请求后暂时将用户数据加载（缓存）一会儿，然后既没有数据库调用也没有cookie的开销当用户积极访问您的网站时。
老实说，您一开始应该没有缓存就可以。专注于以最小的复杂度启动您的应用程序。这样，您可以根据用户反馈更快地对其进行修改，并且错误更少。
3）当我玩护照时，我遇到了类似的问题。我会让护照完成其工作，并向用户授予护照级别的验证（是的，他们已经登录），然后分别进行更多的数据收集。如果您担心安全性，请确保此护照级别的验证未完全登录，并且在升级到完全登录之前需要更多数据。
我可能对此一无所知，但这是我的建议。
4）Redis适用于您有多个节点实例并想在内存中存储某些内容（例如计数器或缓存的用户数据）的情况。这样，您就不会在节点代码中保留用于保存有关用户的缓存数据的变量，而当用户回来时，另一个节点实例将无法利用该变量，而负载均衡器会将它们射向另一个实例。
http://www.ourdailypres.com/2013/09/redis-when-should-i-use-
it.html
编辑：我应该添加该会话使用cookie，但只能为用户提供服务器可以理解的唯一令牌，以便在接收到带有会话令牌的连接时服务器可以重新收集用户的会话数据。我的理解是，这通常是Session工作的正确方式…但是，具体取决于实现方式（如果我在这里错了，请纠正我）。
