1. Ask questions:
In order to satisfy large enough applications and satisfy more customers, we set up N web servers (N>=2). In the case of multiple web servers, we will involve a problem: after users log in to one server , If you can continue to use the client's Session when crossing to another server?
Second, the solution:
Session security and synchronization in the cluster are the biggest problems. The following are several solutions for session synchronization that have been collected. We hope to find out the suitable scenarios by analyzing their respective advantages and disadvantages.
1. Client-side cookie encryption
This is the way I used to do it, simple and efficient. A better way is to use the cookie mechanism to implement a session, and use this session implementation in the application.
Problem: There cannot be too much data in the session, preferably only one user id.
Reference implementation: http://rollerweblogger.org/
After the user logs in successfully, the website domain name, user name, password, token, and session valid time are all written into the client's cookie in the form of a cookie. If the user crosses from one web server to another server, we The program actively detects the cookie information of the client, makes a judgment, and then provides the corresponding service. Of course, if the cookie expires or is invalid, the user will not be allowed to continue the service. Of course, the disadvantages of this method are self-evident. For example, if the client disables cookies or the cookies are stolen by hackers? All these can be solved. At present, the Taobao session framework is developed based on client cookies, so they may not have a big problem? Perhaps the most feasible way, it can be implemented with memcached
2. Application server session replication
Most of the application servers may provide the function of session replication to achieve clustering, and tomcat, jboss, and was all provide such a function.
question:
The performance drops sharply as the server increases, and it is easy to cause broadcast storms;
Session data needs to be serialized, which affects performance.
For how to serialize, you can refer to serialization and deserialization of objects .
References:
SESSION replication in Tomcat 5 cluster one
3. Use the database to save the session
Use the database to save the session, even if the server is down, it's fine, the session is still there.
question:
The program needs to be customized;
The overhead of reading and writing the database for each request is not small (using an in-memory database can improve performance, and data will be lost when downtime. The available in-memory databases include BerkeleyDB, Mysql memory tables);
The database is a single point, of course you can do the ha of the database to solve this problem.
This method is similar to the NFS method. It also uses a Mysql server as a shared server, saves all session data to the Mysql server, and all Web servers come to this Mysql server to obtain session data. The disadvantage is that the dependency is too strong, and Mysql cannot work and affects all Web servers. Of course, you can consider too many Mysql databases to share sessions and use the method of synchronizing Mysql data. This method is similar to method 3. It can also be done with memcached and nosql. These are not problems.
4. Use shared storage to save sessions
Similar to the database, even if the server is down, it's fine, the session is still there. You can use nfs or windows file sharing, or a dedicated shared storage device.
question:
The program needs to be customized;
Frequent serialization and deserialization of data, whether performance has an impact;
Shared storage is a single point, which can be solved by raid.
其实这个方案和上面的Mysql方案类似，只是存储方式不一 样。大致就是有一台公共的NFS服务器（Network File Server）做共享服务器，所有的Web服务器登陆的时候把session数据写到这台服务器上，那么所有的session数据其实都是保存在这台 NFS服务器上的，不论用户访问哪台Web服务器，都要来这台服务器获取session数据，那么就能够实现共享session数据了。缺点是依赖性太强，如果NFS服务器down掉了，那么大家都无法工作了，当然，可以考虑多台NFS服务器同步的形式。这个方案都可以解决，目前zookeeper可以实现，当然memcached也可以实现session共享。
5. 使用memcached来保存session
这种方式跟数据库类似，不过因为是内存存取的，性能自然要比数据库好多了。
问题：
程序需要定制,增加了工作量；
存入memcached中的数据都需要序列化，效率较低；
memcached服务器一死，所有session全丢。memchached能不能做HA? 我也不知道，网站上没提。
参考资料:
6. 使用terracotta来保存session
跟memcached类似，但是数据不需要序列化，并且是Find-Grained Changes，性能更好。配置对原来的应用完全透明，原有程序几乎不用做任何修改。而且terracotta本身支持HA。
问题：terracotta的HA本身进行数据复制性能如何？
参考资料：
使用Terracotta和Tomcat建立ACTIVE-PASSIVE模式的集群
7. Session data synchronization method between servers
Assuming that Web server A is the server where all users log in, then when the user authenticates and logs in, the session data will be written to the A server, then you can write your own script or daemon process to automatically The session data is synchronized to other web servers, so when the user jumps to other servers, the session data is consistent, and the service can be directly performed without logging in again. The disadvantage is that it may be slow and unstable. If it is a one-way synchronization, if there is a problem with the login server, then other servers will not be able to serve. Of course, the problem of two-way synchronization can also be considered. This solution can be solved, and currently zookeeper can achieve it.
8. Use hardware devices
This is a relatively mature solution. If you use load devices like BIG-IP to achieve resource sharing, you can share sessions stably and reasonably. Many portals currently use this approach. The disadvantage is obvious, that is, there is a fee, and the hardware equipment must be purchased, but for professional or large-scale applications, it is more reasonable and worthwhile, this method can be considered at the end