Comparison of several session synchronization solutions in the cluster

1. Client-side Cookie Encryption

。 The better way is to use the cookie mechanism to implement a session, which is implemented using this session in the application.

Problem: There is not too much data in the session, preferably a user ID.

The session is another mechanism for recording the state of a customer, but the cookie is stored in the client browser and the session is stored on the server. When the client browser accesses the server, the server logs the client information to the server in some way. This is the session. When the client browser accesses it again, it only needs to find the customer's status from that session.

If the cookie mechanism is to determine the customer's identity by checking the "pass" on the client, then the session mechanism verifies the customer's identity by checking the "customer schedule" on the server. Session is equivalent to a program on the server set up a customer profile, when customers visit only need to query the customer file table on it.

Session is saved on the server side. In order to obtain higher access speed, the server usually puts the session in memory. Each user will have a separate session. If the session content is too complex, a large number of clients accessing the server can cause memory overflow. Therefore, the information in the session should be as concise as possible.

2. Session replication for Application server

It is possible that most application servers provide the function of session replication to implement the cluster, which is provided by Tomcat,jboss,was.

Problem:

Performance decreases with the increase of server, and it is easy to cause broadcast storm;

Session data needs to be serialized, affecting performance.

How to serialize, you can refer to the serialization and deserialization of objects.

Resources:

The session in the Tomcat 5 cluster replicates a

Session replication two in the Tomcat 5 cluster

Application Server-jboss 4.0.2 Cluster Guide

3. Save session with Database

Use the database to save the session, even if the server is down, it's OK, the session is still there.

Problem:

Procedures need to be customized;

Database read-write overhead is not small per request (using a memory database can improve performance, and downtime loses data.) Available memory database with berkeleydb,mysql memory table);

Database is a single point, of course, you can do the database ha to solve this problem.

4. Use shared storage to save session

Similar to the database, even if the server is down and nothing, the session is still in. You can use either NFS or Windows file sharing, or a dedicated shared storage device.

Problem:

Procedures need to be customized;

Frequent data serialization and deserialization, performance is not affected;

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

5. Use memcached to save session

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

Problem:

Procedures need to be customized, increase the workload;

The data stored in the memcached need to be serialized and less efficient;

Memcached server dead, all session lost. Can memchached do ha? I don't know, I didn't mention it on the website.

Resources:

Apply memcached to save session information

Correct understanding of memcached cache Invalidation

Expand Tomcat 6.x and use memcached to store session information

6. Use Terracotta to save session

Similar to memcached, but the data does not need to be serialized and is find-grained changes for better performance. The configuration is completely transparent to the original application, with almost no changes to the original program. and terracotta itself supports ha.

Question: How does the terracotta ha itself perform data replication performance?

Resources:

Jvm-level Clustering

Terracotta cluster Tomcat for session synchronization

Using terracotta and Tomcat to build active-passive-mode clusters

Build Web Apps with spring Web flow and terracotta

Terracotta practical example--cluster rife

Terracotta: Turning to open source, acceptance, hibernate support

Attached: Terracotta Introduction

Open Terracotta is an enterprise-class, Open-source, jvm-level clustering solution. Jvm-level Clustering simplifies enterprise Java by enabling applications to is deployed on multiple JVMs, yet interact wit h each of the 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 this threads on one Virtual machine can interact with threads on another vsan as if they were all on the same vsan with An unlimited amount of heap.

Comparison of several session synchronization solutions in the cluster