您应该使用会话管理来处理客户端和服务器之间的信息传输。

会话管理本质上涉及对用户进行身份验证以最初执行特权操作，所有后续活动都通过“共享”信息进行身份验证，例如：cookie。

要求用户对每项操作进行身份验证可能被认为更安全，但会因此严重降低平台可用性和整体用户满意度。

关于数据库负载，如果没有看到特定的应用程序，我不能 100% 做到，但是我建议只要您记录上次使用会话的时间，就不需要向数据库写入太多其他信息。

基于声明的身份是减少验证用户负载的好方法。

实现这一点的最简单方法是使用第一个身份验证门户生成包含用户必要声明的签名令牌，然后让后续调用需要该令牌，验证签名并信任声明。

有关实际实现，请参阅JWT。

这真的有点跑题了。我们不知道您的应用程序是/做什么/看起来像什么 - 所以我们无法回答您提出的问题，只是说功能相关性通常会覆盖性能考虑。但是，由于其他人已经开始回答......

传统上，http 会话使用发送到客户端的随机标识符，这是服务器上数据的关键。每次请求需要会话数据时，都会从存储中读取。并且在大多数实现中，它随后会在请求完成时或之前写回存储。后者对于更新会话上的时间戳很重要，以便以后可以进行垃圾收集。现在，您肯定希望在数据发生更改时将数据写回存储，但写入的成本至少是读取的 3 倍。因此，即使您可以在不影响向客户端交付内容的情况下实现这一点，但不随每个请求将未更改的会话数据写回存储可能会对容量产生很大影响。

使用更快的存储基板也有帮助。

然后是缓存内容的可能性。每次访问时都需要重新生成一些内容。对于给定用户，一些内容将接近静态，而对于所有用户，一些内容将是相同的。HTTP 提供了向客户端和反向代理通告这一事实的机制。例如，对于特定用户可缓存的内容，您可以将用户 ID 合并到 Etag 中 - 但请记住在它离开反向代理的位置添加一个 cache-control:private 标头。

虽然您通常不能信任从客户端发送的内容，但您可以加密 cookie 中的数据并使用客户端进行存储 - 并在解密时检查是否被篡改。同样，这是关于容量而不是性能。并且需要对客户端上的数据的持久性应用一些想法，即使它是加密的。

但是，除了在极少数情况下，会话的性能开销相对于网页中发生的所有其他事情来说非常非常小。

看起来您正在滚动自己的身份验证或至少其中的一部分。

我想知道每次用户请求内容时是否应该点击 Redis，

是的，您必须针对每个 http 请求的后端存储检查用户会话，这是 Web 服务器和 Web 框架处理用户会话的方式，其中一些使用文件系统来存储像 Apache 这样的会话，而另一些使用像 Django 框架这样的关系数据库默认。

像 Redis 和 Memcached 这样的内存存储实际上是这种情况下的正确选择。

但是，您仍然可以通过减少客户端和服务器之间的往返次数来提高性能，这可以通过将数据聚合到较少数量的请求来实现，这将降低 Redis 上的命中频率。