Comparison of several session synchronization solutions in the Cluster

Session Security and synchronization are the biggest problems in the cluster. The following are several session synchronization solutions collected. We hope to find out the applicable scenarios by analyzing their respective advantages and disadvantages.

1. Client cookie Encryption

Simple and efficient. A better way is to use the cookie mechanism to implement a session and use this session in the application.

Problem: there cannot be too much data in the session. It is best to have only one user ID.

Reference implementation:Http://rollerweblogger.org/

2. Application Server session replication

Most application servers may provide session replication for clusters, tomcat, JBoss, and was.

Problem:

Performance decreases sharply with the increase of servers and is prone to broadcast storms;

Session data needs to be serialized, affecting performance.

For more information about serialization, see
Object serialization and deserialization.

References:

Copy Session 1 in Tomcat 5 cluster

Session replication 2 in Tomcat 5 cluster

Application Server-JBoss 4.0.2 cluster Guide

3. Use the database to save the session

The database is used to save the session. Even if the server goes down, the session will remain unchanged.

Problem:

ProgramCustomization required;

The database read/write overhead for each request is not small (the memory database can improve the performance, and data will be lost when the server goes down. Available memory databases include the berkeleydb and MySQL memory tables );

The database is a single point of failure. Of course, the database ha can be used to solve this problem.

4. Use shared storage to save the session

Similar to databases, even if the server goes down, the session is still there. You can use NFS or Windows file sharing, or use a dedicated shared storage device.

Problem:

The program needs to be customized;

Frequent data serialization and deserialization, whether the performance is affected;

Shared storage is a single point, which can be solved through raid.

5. Use memcached to save the session

This method is similar to the database, but because it is memory access, the performance is naturally much better than the database.

Problem:

The program needs to be customized, increasing the workload;

Data stored in memcached must be serialized, with low efficiency;

When the memcached server dies, all sessions are lost. Can memchached Do Ha? I don't know. I didn't mention it on the website.

References:

Apply memcached to save session information

Correct understanding of memcached cache failure

Extended Tomcat 6.xand used memcached to store session information

6. Use terracotta to save the session

Similar to memcached, but the data does not need to be serialized, And it is find-grained changes, which provides better performance. The configuration is completely transparent to the original application, and there is almost no need to modify the original program. In addition, terracotta itself supports HA.

Q: What is the performance of terracotta's ha for Data Replication?

References:

JVM-level Clustering

Terracotta cluster Tomcat for session Synchronization

Use terracotta and tomcat to create a cluster in active-Passive Mode

Use spring web flow and Terracotta to build Web Applications

Terracotta practical example -- cluster rife

Terracotta: Open Source, acceptance, and hibernate support

Appendix: terracotta Introduction

Open terracotta is an enterprise-class, open-source, JVM-level clustering solution. JVM-level clustering simplifies Enterprise Java by enabling applications to be deployed on multiple JVMs, yet interact with each other as if they were running on the same
JVM. terracotta extends the Java Memory Model of a single JVM to include a cluster of virtual machines such that threads on one virtual machine can interact with threads on another virtual machine as if they were all on the same virtual Machine with an unlimited
Amount of heap.

Reprinted please indicate the sourceHttp: // blog.Csdn.net/shimiso 

Welcome to our technical exchange group: 173711587