Four solutions of distributed session

Server storage

Realization ：session Copy （session Sync ）

 Is to synchronize these two servers session, For example, the server on the left saved a 1, The server on the right saved a 2, The two of them are synchronized , Then the server on the left saves 1,2, The server on the right also saves 1,2.

advantage ：

1. tomcat Native support , Just modify the configuration file , Many tomcat Can be copied between session

shortcoming

1. session Synchronization requires data transmission through the network , There is a delay problem , At the same time, it will occupy a lot of bandwidth , This will compress the bandwidth of our entire business , It will reduce our processing capacity

If it is a large distributed cluster environment , Because of all web-server Save all data , So we don't use this scheme . And if it's a small system , Just 3/5 individual tomcat, If we want to use , It's OK to simply configure it

Client storage

Realization ：

 We let the client store it by itself session, What data does our server want to use , Read from the browser cookie that will do . This saves server resources 

shortcoming

1. Every time http request , Carry users in cookie Complete information in , Wasting network bandwidth
2. session The data is placed in the browser cookie in , Some browsers follow different standards , Its length limit is different , Such as length limit 4k, Therefore, a large amount of information cannot be saved
3. session The data is in cookie in , There is a leak 、 Tampering 、 Security risks such as theft

HASH Uniformity （ recommend ）

principle ：

Using our load balancing mechanism , We can use ip Hash consistency of , As long as it comes from the same ip Of , Then we will always locate it to the same server , We won't run it to the second server , Such as things stored in the green marked browser and the green marked server , No matter how many times you ask to come , Will fall on the green server , We can get

advantage

1. Just change load balancing nginx Configuration of , Let it make a ip hash, Without modifying the application code
2. The load is balanced ： as long as hash The values of attributes are evenly distributed , More than one web-server The load is balanced
3. Support web-server Horizontal expansion （ and session Copying the scheme is not enough , Limited by memory ）

shortcoming

1. session There is still web-server in , therefore web-server Suddenly flash off or restart , It may lead to part of session The loss of , These users only need to come back next time , All the data is gone , He needs to log in again , Everything has to be redone
2. If our server wants to expand horizontally , If we fix it , But if it turns out to be 2 Servers , Now add 4 Servers , Now if you want to do hashing , It's equivalent to recalculating , Suppose we used to calculate hash in the simplest way , according to ip The address gets an integer hash , If only 2 Servers , Then it's OK to 2 Surplus operation , Find the remainder , If the remainder is 1, It fell to the first server , If there is no remainder , It will fall to the second server . But if it becomes 4 Servers , We are equivalent to being right 4 Carry out the remainder operation , If yu 1, Fall to the first server , more than 2 Fall to the second server , more than 3 To the third server , There is no remainder, we fall to the fourth server .（ After horizontal expansion ,rehash after session Redistribute , Some users will not be able to route to the correct server ）

Unified storage （ recommend ）

Realization ：

Then we can make session Unified storage , No matter which server you have , Which one? tomcat, Yours session Don't store it in your memory , All , Everyone can save to the database , perhaps redis Something faster nosql Middleware and so on , therefore , We can use this scheme

advantage

1. No potential safety hazard , It doesn't let the browser store it in cookie in , All data is stored in our background , The browser must be inaccessible , As long as we guarantee our backstage redis The safety of the , No one can tamper with the relevant data

2. Horizontal expansion is also easy , Whether we web How many servers ,10 individual ,100 individual ,1000 individual , Anyway, everyone goes redis Do access , Even if redis It's not enough , We do redis colony , Save a little in each , Save a little in each

3. Even if our server restarts 、 Downtime , Start again next time , We session It won't lose , because session All are redis There is , It has nothing to do with whether our business server is down

shortcoming

1. Getting data from memory is very fast , There is no need for network interaction , And if we store it redis Inside , We want to session Get data inside , We have to connect redis, Another network interaction

2. We need to modify the application code ： If all the getSession Method is replaced by from Redis How to check the data

Link to the original text ：https://mp.weixin.qq.com/s/wX5wmn8Wykxt4_bxzZrJ6Q