Shulou(Shulou.com)06/01 Report--

This article mainly talks about "session processing method of load balancing cluster". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the session processing method of load balancing cluster.

Common problems

From the user side, it means that when a user visits and logs in to the back-end server A by load balancer for the first time, the user's login information is retained on server A; when the user sends the request again

According to the load balancing policy, it may be proxied to different servers at the back end, such as server B. because this server B does not have the login information of the user, the user needs to log in again. This is intolerable for users. Therefore, when implementing load balancing, we must consider the problem of Session.

In general, there are the following methods to deal with Session in load balancer:

1) Session session persistence (case: Nginx, Haproxy) 2) Session session replication (case: Tomcat) 3) Session session sharing (case: Memcached, Redis) 1. Session session persistence Session persistence (session persistence) is one of the most common nouns we see. Through session persistence, load balancer ensures that each client has fixed access to the same application server at the back end when distributing requests. Session persistence schemes are implemented in all load balancers. And this can solve the Session problem at the load balancing layer. = Nginx for Session maintenance of load balancer = for Nginx, you can choose the method of Session retention for load balancer. Nginx's upstream currently supports five allocation methods, among which there are two general Session solutions, ip_hash and url_hash. Note: the latter is not an official module and requires additional installation. Ip_hash

Each request is allocated according to the hash result of accessing the ip, so that each guest accesses a back-end server on a fixed basis, which achieves the method of Session retention.

Example:

Upstream bakend {ip_hash; server192.168.0.11:80; server192.168.0.12:80 } = Session maintenance of Haproxy load balancing = Haproxy, as an excellent reverse proxy and load balancing software, also provides a variety of Session maintenance methods The two most commonly used ones are listed below: 1) the source address Hashharoxy assigns the user IP to a fixed real server (similar to nginx's ip hash instruction) configuration instruction: balancesource2) use cookie for identification, that is, Haproxy inserts a Cookie into the user's browser after the user's first visit, and the browser will bring this Cookie to the Haproxy,Haproxy for identification the next time the user visits. Configuration instruction: cookie SESSION_COOKIE insert indirect nocache

Examples of configurations are as follows:

Cookie SERVERID insert indirect nocacheserver web01 192.168.56.11:8080 check cookie web01server web02 192.168.56.12:8080 check cookie web02

Disadvantages of session persistence:

1) session persistence seems to solve the problem of Session synchronization, but it brings some other problems: 2) load imbalance: due to the use of Session persistence, it is obviously impossible to guarantee absolute load balancing. 3) the problem has not been completely solved: if the backend server is down, the Session of the server is lost, and the user assigned to the service request still needs to log in again. II. Session session persistence

Since our goal is to maintain the user's Session on all servers, is it possible to copy the Session information from each application server to the other server nodes? This is the second treatment of Session: session replication.

Session replication is supported on Tomcat. It is based on IP Multicast (multicast) to complete Session replication. There are two types of Tomcat session replication:

1) Global session replication: use the change information in the Delta Manager replication session to all other nodes in the cluster. 2) non-global replication: replicates using Backup Manager, which replicates Session to a specified backup node.

However, we are not going to explain the Tomcat configuration of session replication. If you need it, you can refer to the official Tomcat documentation, mainly because session replication is not suitable for large clusters. According to the practical case of production, all kinds of problems will occur after the cluster has more than 6 nodes, and production use is not recommended.

3. Session session sharing since session persistence and session replication are not perfect, why don't we put Session in a unified place, so that all nodes in the cluster are in one place for Session Session storage? For Session, it must be used frequently, although you can store it in a database, but in a real production environment, I prefer to store it in faster distributed KV data, such as Memcached and Redis.

PHP sets up Session sharing

If you are using PHP, then congratulations, the configuration is very simple. PHP can store Session in Memcached or Redis through two-line configuration, of course, you have to configure them in advance. Modify php.ini:

Using Memcache to store Session

Session.save_handler = memcachesession.save_path = "tcp://192.168.56.11:11211"

Using Redis to store Session

Session.save_handler = redissession.save_path = "tcp://localhost:6379"

Reminder: don't forget to install the memcache or redis plug-ins for PHP.

Tomcat sets up Session sharing

You can use MSM (Memcached Session Manager) to also store Session in Memcache.

Django sets up Session sharing

In Django, Session is managed through a middleware. If you want to use Session in your application, you need to add 'django.contrib.sessions.middleware.SessionMiddleware' to the MIDDLEWARE_CLASSES variable in settings.py. Django's Session engine can store Session in three places: database, cache, and file.

If you want to use database-supported sessions, you need to add 'django.contrib.sessions' to your INSTALLED_APPS settings. After the configuration is complete, run manage.py migrate to install a database table that holds the session data.

Use caching to maintain Session

For simple caching sessions: you can set SESSION_ENGINE to "django.contrib.sessions.backends.cache". At this point, the session data is stored directly in your cache. However, cached data may not last: if the cache fills up or the cache server restarts, the cached data may be cleaned up. To persist cached data: you can set SESSION_ENGINE to "django.contrib.sessions.backends.cached_db". Its write operations use caching, and each write to the cache is rewritten to the database. For read sessions, if the data is not in the cache, it is read from the database. Both sessions are stored very fast, but the simple cache is faster because it gives up persistence. In most cases, the cached_db backend is fast enough, but if you need to drain the last bit of performance and accept the risk of session data loss, you can use cache instead of cached_db

Using file to save Session is no longer our discussion, because it is difficult to share, and PHP also stores Session in the / tmp directory by default.

At this point, I believe you have a deeper understanding of the "session processing method of load balancing cluster". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.