Tomcat 上的会话复制有哪些缺点？
我试图确定 Tomcat+Apache 反向代理模式中会话复制哪个更好。部署中更常见的是什么？会话复制还是会话保持？会话复制有什么缺点吗？
谢谢
I was trying to decide what is better in a Tomcat+Apache reverse proxy mode for session replication. What is more common on deployments? session replication or stick session? Are there any drawbacks for session replication?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您进行会话复制，我可以指出以下注意事项。
性能
主要缺点是性能。复制会话涉及将会话数据复制到集群中的所有服务器。集群中的服务器越多，涉及的额外开销就越多。
Tomcat 通过定义两种会话复制模式来帮助解决此开销。
DeltaManager（默认）和 BackupManager
来自此 URL http://tomcat.apache。 org/tomcat-6.0-doc/cluster-howto.html
阅读此 URL 了解良好的设计技巧集群（如果启用会话复制）。
内存
有多少并发用户将访问该应用程序？用户越多，会话中存储的数据就越多，因此会话复制就会过载。
代码注意事项
此外，您需要确保应用程序放入会话的数据是可序列化的。序列化会话数据会产生一些复制会话状态的开销。保持会话大小相当小是个好主意，因此开发人员需要检查放入会话中的数据量。
粘性会话
考虑到这些因素，它实际上取决于用例的关键性。如果您单独进行粘性会话，则在关键旅程中可能会丢失用户数据。
您是否有办法从中恢复 - 例如：通过在订单或付款过程的每个步骤将关键数据保存到数据库中？如果没有，用户必须登录并重新开始。这对于非交易性网站来说很好，但浏览小册子类型的数据或填写表格以捕获非付款等数据。
I can point out the following considerations if you go for session replication.
Performance
The main drawback will be on performance. Replicated sessions involve copying of session data over to all the servers in the cluster. The more servers you have in the cluster, the additional overheads involved.
Tomcat helps with this overhead by definining two modes for session replication.
DeltaManager (default) and BackupManager
From this URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Read this URL for good design tips for the cluster if enabling session replication.
Memory
How many concurrent users will be hitting the application? the more users, the more data gets stored into sessions, and hence an overload for session replication.
Code considerations
Additionally you need to ensure the data being put into the session by the application is serializable. Serializing session data has some overhead for replicating the session state. It's a good idea to keep the session size reasonably small, so the developers need to check the amount of data being put into the session.
Sticky Sessions
Given these considerations, it actually depends on the criticality of the use cases. If you go for sticky sessions alone, then there is a chance of loss of user data during a critical journey.
Do you have means to recover from that - eg: by persisiting critical data into database at each step of a order or payment journey? If not the user has to login and start again. This is fine for websites which are not transactional, but browse brochureware type of data or filling out forms to capture data which is not payment etc.