First, the introduction of the Session problem
During the evolution of the website, when our single application server can no longer handle many requests and responses, we will consider whether to build a server cluster. We have added a load balancing device to distribute requests and responses with a certain weight. We thought it was perfect! However, just like fixing bugs, if one bug is fixed, it is very likely that new bugs will be created.
When the new middle tier was introduced, we seemed to have solved the server's inability to handle more requests and responses due to its own performance issues. However, there is a very detailed problem here. Take the above figure as an example, every time the client opens a session, a session will be generated, representing a session between the current client and the application server, and a unique identifier - sessionId will be generated.
now imagine when you are surfing with your chrome, you open a tab , enter a url: at this time you generate a request object, this object carries your sessionid (identifying the session), along the blue line on the way, to the server on the left Go up, after the server on the left has finished processing, I will give you a response, and then your client (your chrome) will show you a result, you say: (⊙o⊙) Oh, the price of the mini skirt that I collected two days ago has dropped! buy buy buy! ! !
Then you submit the order, your request first arrives on the load balancing device, then it sends your request to a server in the application server cluster, now, the problem occurs here, the last time I had a session with the server When the first application server is used, but since I have not specified how the load balancing device should distribute the request, if the load balancing device sends your request to the second application server, but I am in this session The session is still on the first application server, (⊙o⊙)... Find something. . .
After typing so many words, I actually want to explain a problem. You have introduced a load balancing device, and you have to configure the load balancing device so that my same session falls on the same application server.
Second, how to ensure my Session
1,session sticky
在没有负载均衡设备之前，因为我们只有一台应用服务器，我们的每次请求都是落在同一个服务器上，session也是都在这个服务器，我们的每一次会话请求都在这一个服务器上进行处理。
沿用这个简单思路，如果我们在负载均衡设备上，设置这样的规章：让每次请求响应均被负载均衡设备发送到相同的服务器进行处理，这样，我们的session就能得到保证了。
缺点：
1，在应用服务器集群中，如果有一台web服务器宕机或者重启，那么这台机器上的会话就会丢失，例如：如果会话中有用户的登录状态，那么用户再次发出请求，就会提示用户重新登录。
2，会话标识是应用层的信息，那么负载均衡设备要将同一个会话请求都保存到同一个web服务器上，就要进行应用层的解析，这个开销比在传输层大。
3，此时，负载均衡器变成了一个有状态的节点，要将会话保存到具体web服务器的映射，和无状态的节点相比，内存更大，容灾更麻烦。
2，session replication
如果做过数据库读写分离的都该知道，读写分离的时候，其实读的是从库，写的是主库，但是主库的信息会更新到从库，不考虑读写时间，我们可以任务从库和主库的数据是一致的，这个一致性主要靠同步来实现的。
在处理session的时候，我们同样可以采用这样的策略，在负载均衡设备上，无需动任何手脚，只进行无状态分发，反正分发到哪个服务器上，我之前的session都有，木事。
缺点：
1，同步session造成了网络带宽的开销，只要session数据有变化，就需要将数据同步到其他服务器上，机器越多，同步带来的网络开销就越大。
2，每台web服务器都要保存所有的session信息，如果整个集群的session数据很多，每台应用服务器就会保存非常多的session数据，严重占用内存。
3，session数据集中存储
Since you don’t like synchronization, you should take out all session data and put it in a separate place, which can be a separate database or other distributed storage system. The front load balancer is still stateless forwarding, and the application server reads and writes the session every time. , all to the same place to pick up.
A recent project is like this. The load balancing uses nginx. Every time a user accesses, a sessionid is generated, and then the information in the session is serialized and stored in the Redis library. The application uses it through my redis . Access the module to access, after the session ends, delete session.
shortcoming:
1. Network operations are introduced to read and write session data. Compared with local data reading, the problem lies in the existence of delay and instability. However, considering that the communication between the application server and the session storage device occurs in the content, so, take it easy!
2. If the session storage is centralized, it is necessary to consider that when the session server has a problem, it will affect the use of our entire chain.
4，Cookie Based
If you don't want to introduce additional nodes to process the session, we can consider putting the session data in cookies, and carry it with each request and response. Every time the server needs to read and write the session, it only needs to be generated from the cookie.
shortcoming:
1. Cookie length limit: Because the length of data that a cookie can carry is limited, it also limits the length of the session to a certain extent.
2. Security: The session data is originally server data, and this solution allows the session data to go to the external network and the client, so there is a security problem. In actual operation, the session needs to be encrypted.
3. Bandwidth consumption
4. Performance: Each HTTP request and response carries session data. For the web server, under the same circumstances, the less the result output of the response, the more concurrent requests it supports.