What to do if distributed session is inconsistent? The following article will introduce to you the solution to distributed session inconsistency in redis. I hope it will be helpful to you!
1. What is the role of Session?
Session is a communication session tracking technology between the client and the server. The server and the client maintain the basic session information of the entire communication. [Related recommendations: Redis Video Tutorial]
When the client accesses the server for the first time, the server will respond with a sessionId and store it locally. In the cookie, subsequent visits will put the sessionId in the cookie into the request header to access the server.
If the corresponding data is not found through this sessionId, then the server will create a New sessionId and responded to the client.
2. What are the problems with distributed Session?
In a single-server web application, session information only needs to be stored in the server. This is the most common way we came into contact with it in the past few years
But in recent years, with the With the popularity of distributed systems, a single system can no longer meet the growing needs of millions of users. Servers deployed in clusters have been used in many companies
When high-concurrency requests arrive at the server, load balancing is used distributed to a server in the cluster, which may cause multiple requests from the same user to be distributed to different servers in the cluster, and session data cannot be obtained, so session sharing becomes one question.
3. How is the clustering of services generally done?
4. The difference between nginx load balancing and ribbon load balancing
5. Session consistency solution
1. Session replication (synchronization)
Idea: Multiple servers synchronize sessions with each other, so that each server contains all sessions
Advantages: Functions supported by the server, the application does not need to modify the code
Disadvantages:
2. Client storage method
Idea: The server stores the sessions of all users, which takes up a lot of memory. You can store the sessions in browser cookies. Each client only needs to store the data of one user.
Advantages: The server does not need to store
Disadvantages:
Note: Although this solution is not commonly used, it is It is indeed a way of thinking.
3. Reverse proxy hash consistency
Idea: In order to ensure high availability, the server has multiple redundant reverse proxies Can the layer do something to ensure that requests from the same user fall on the same server?
The reverse proxy layer uses the user’s IP for hashing to ensure the same IP requests fall on the same server
The reverse proxy uses certain business attributes in the http protocol for hashing, such as sid, city_id, user_id, etc., which can implement the hash strategy more flexibly to ensure that requests from the same browser user fall on the same server.
Advantages:
Disadvantages:
Session generally has a validity period. The two shortcomings can be considered to be equivalent to partial session failure. Generally, the problem is not big.
Regarding four-layer hashing or seven-layer hashing, I personally recommend the former: let professional software do professional things, and the reverse proxy is responsible for forwarding. Try not to introduce application layer business attributes unless you have to (such as , sometimes multiple computer rooms and multiple servers need to be routed to servers in different computer rooms according to business attributes).
The difference between four-layer and seven-layer load balancing
4. Back-end unified centralized storage
Advantages:
Shortcomings: A network call is added, and the application code needs to be modified
Regarding db storage or cache, I personally recommend the latter: session The frequency of reading will be very high, and the database pressure will be relatively high. If there is a need for session high availability, the cache can be made highly available, but in most cases the session can be lost, and generally there is no need to consider high availability.
Summary
Common methods of architectural design to ensure session consistency:
6. Case practice: SpringSession redis solves the problem of distributed session inconsistency
##Step 1: Add the dependency packages of SpringSession and redis
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-redis</artifactId>
<version>1.4.7.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
</dependency>Step 2: Configuration file
# 为某个包目录下 设置日志 logging.level.com.ljw=debug # 设置session的存储方式，采用redis存储 spring.session.store-type=redis # session有效时长为10分钟 server.servlet.session.timeout=PT10M ## Redis 配置 ## Redis数据库索引（默认为0） spring.redis.database=0 ## Redis服务器地址 spring.redis.host=127.0.0.1 ## Redis服务器连接端口 spring.redis.port=6379 ## Redis服务器连接密码（默认为空） spring.redis.password=
Step 3: Configure interceptor
@Configuration
public class SessionConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new SecurityInterceptor())
//排除拦截的2个路径
.excludePathPatterns("/user/login")
.excludePathPatterns("/user/logout")
//拦截所有URL路径
.addPathPatterns("/**");
}
}@Configuration
public class SecurityInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException {
HttpSession session = request.getSession();
//验证当前session是否存在，存在返回true true代表能正常处理业务逻辑
if (session.getAttribute(session.getId()) != null){
log.info("session拦截器，session={}，验证通过",session.getId());
return true;
}
//session不存在，返回false，并提示请重新登录。
response.setCharacterEncoding("UTF-8");
response.setContentType("application/json; charset=utf-8");
response.getWriter().write("请登录！！！！！");
log.info("session拦截器，session={}，验证失败",session.getId());
return false;
}
}Step 4: Controller
@RestController
@RequestMapping(value = "/user")
public class UserController {
Map<String, User> userMap = new HashMap<>();
public UserController() {
//初始化2个用户，用于模拟登录
User u1=new User(1,"user1","user1");
userMap.put("user1",u1);
User u2=new User(2,"user2","user2");
userMap.put("user2",u2);
}
@GetMapping(value = "/login")
public String login(String username, String password, HttpSession session) {
//模拟数据库的查找
User user = this.userMap.get(username);
if (user != null) {
if (!password.equals(user.getPassword())) {
return "用户名或密码错误！！！";
} else {
session.setAttribute(session.getId(), user);
log.info("登录成功{}",user);
}
} else {
return "用户名或密码错误！！！";
}
return "登录成功！！！";
}
/**
* 通过用户名查找用户
*/
@GetMapping(value = "/find/{username}")
public User find(@PathVariable String username) {
User user=this.userMap.get(username);
log.info("通过用户名={},查找出用户{}",username,user);
return user;
}
/**
*拿当前用户的session
*/
@GetMapping(value = "/session")
public String session(HttpSession session) {
log.info("当前用户的session={}",session.getId());
return session.getId();
}
/**
* 退出登录
*/
@GetMapping(value = "/logout")
public String logout(HttpSession session) {
log.info("退出登录session={}",session.getId());
session.removeAttribute(session.getId());
return "成功退出！！";
}
}Step 5: Entity class
@Data
public class User implements Serializable{
private int id;
private String username;
private String password;
public User(int id, String username, String password) {
this.id = id;
this.username = username;
this.password = password;
}
}Step 6: Access test
Log in first:http://127.0.0.1:8080/user/login?username=user1&password=user1
Check againhttp://127.0.0.1:8080/user/find/user1
7. Analyze the redis principle of SpringSession
Step 1: Analyze the redis data structure of SpringSession
127.0.0.1:6379> keys * 1) "spring:session:sessions:9889ccfd-f4c9-41e5-b9ab-a77649a7bb6a" 2) "spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b" 3) "spring:session:expirations:1635413520000" 4) "spring:session:sessions:expires:9889ccfd-f4c9-41e5-b9ab-a77649a7bb6a" 5) "spring:session:expirations:1635412980000" 6) "spring:session:sessions:d3434f61-4d0a-4687-9070-610bd7790f3b"
127.0.0.1:6379> type spring:session:sessions:d3434f61-4d0a-4687-9070-610bd7790f3b hash
127.0.0.1:6379> hgetall spring:session:sessions:d3434f61-4d0a-4687-9070-610bd7790f3b // session的创建时间 1) "creationTime" 2) "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01|\xc5\xdb\xecu" // sesson的属性，存储了user对象 3) "sessionAttr:d3434f61-4d0a-4687-9070-610bd7790f3b" 4) "\xac\xed\x00\x05sr\x00\x1ecom.ljw.redis.controller.User\x16\"_m\x1b\xa0W\x7f\x02\x00\x03I\x00\x02idL\x00\bpasswordt\x00\x12Ljava/lang/String;L\x00\busernameq\x00~\x00\x01xp\x00\x00\x00\x01t\x00\x05user1q\x00~\x00\x03" //最后的访问时间 5) "lastAccessedTime" 6) "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01|\xc5\xe1\xc7\xed" //失效时间 100分钟 7) "maxInactiveInterval" 8) "\xac\xed\x00\x05sr\x00\x11java.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x17p"
Step 2: Analyze SpringSession’s redis expiration strategy
There are generally three types of deletion for expired data Strategy:定期删除，即每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。
redis删除过期数据采用的是懒性删除+定期删除组合策略，也就是数据过期了并不会及时被删除。
但由于redis是单线程，并且redis对删除过期的key优先级很低；如果有大量的过期key，就会出现key已经过期但是未删除。
为了实现 session 过期的及时性，spring session 采用了定时删除+惰性删除的策略。
定时删除
127.0.0.1:6379> type spring:session:expirations:1635413520000 set 127.0.0.1:6379> smembers spring:session:expirations:1635413520000 1) "\xac\xed\x00\x05t\x00,expires:d3434f61-4d0a-4687-9070-610bd7790f3b"
2) "spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b" 3) "spring:session:expirations:1635413520000" 6) "spring:session:sessions:d3434f61-4d0a-4687-9070-610bd7790f3b"
惰性删除
127.0.0.1:6379> type spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b string 127.0.0.1:6379> get spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b "" 127.0.0.1:6379> ttl spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b (integer) 3143 127.0.0.1:6379>
2) "spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b" 3) "spring:session:expirations:1635413520000" 6) "spring:session:sessions:d3434f61-4d0a-4687-9070-610bd7790f3b"
更多编程相关知识，请访问：编程视频！！
The above is the detailed content of What to do about distributed session inconsistency in redis. For more information, please follow other related articles on the PHP Chinese website!
What is distributed
The difference between distributed and microservices
Commonly used database software
What are the in-memory databases?
Which one has faster reading speed, mongodb or redis?
How to use redis as a cache server
How redis solves data consistency
How do mysql and redis ensure double-write consistency?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
