我在发送响应后开始更新会话，这似乎是获得更快速度的好方法，因为它现在是一个非阻塞任务。
但是我担心数据库中的最小速度减慢会在以这种方式更新会话时引起问题。
想象一下，我想为下一个请求设置会话闪存消息，但下一个请求/响应在会话更新之前发生。用户不会看到它，或者他会在不同的请求中看到它。
最糟糕的情况是您需要重新生成会话ID。如果更新速度很慢并且下一个请求比这更快，则用户将被注销，因为他将要求不存在或过期的会话（他在cookie中收到新的会话ID作为响应的一部分）。
所以我想知道的是，这是否已经被研究过，人们是否使用它，我应该什么时候做，什么时候不应该，如果有解决方法等等。
答案 0 :(得分：1)
如果您已经发送了一些输出，则无法重新生成session_id。正如你所说，他需要在cookie中接收new_id，这是必须先发送的http头的一部分。如果用户有多个具有相同会话ID的请求并且您更改了session_id，则重新生成session_id会导致您提到的问题。例如一个html页面和一些很常见的图像。如果需要重新生成session_id，则应该在没有其他需要会话的资源的页面中“单独”执行此操作，以使其成为原子操作。
现在我不确定你使用的是哪种语言，但是php例如在内存中收集会话信息并在进程结束时保留它们。从而使这种非阻塞......
如果必须通过多个进程同步会话信息，您必须要小心。然而，这对于大多数网页/应用程序来说并不常见。您很少在这么短的时间内（页面外+资源下载）有多个请求。
基本上，在发送响应后更新会话信息通常是个好主意。可以这样想：如果数据库很慢，可能很难给出过时的会话信息。所以无论如何你写的可能会在那时完成吗？ ;）