Comment SpringBoot AOP Redis implémente la fonction de double suppression retardée

1. Scénario métier

Dans le cas d'une concurrence multi-thread, supposons qu'il y ait deux demandes de modification de base de données Afin d'assurer la cohérence des données entre la base de données et redis,
La mise en œuvre de la demande de modification nécessite une mise en cascade. modifications après avoir modifié la base de données dans Redis.
Requête 1 : A modifie les données de la base de données B modifie les données Redis
Requête 2 : C modifie les données de la base de données D modifie les données Redis
Dans une situation concurrente, il y aura la situation A —> —> B
(Assurez-vous de comprendre que l'ordre d'exécution de plusieurs ensembles d'opérations atomiques exécutées simultanément par les threads peut se chevaucher)

1. Problèmes en ce moment

A a modifié les données de la base de données et les a finalement enregistrées dans Redis, et C a également modifié la base de données après les données A.

À l'heure actuelle, il existe une incohérence entre les données de Redis et les données de la base de données. Dans le processus de requête ultérieur, Redis sera d'abord vérifié pendant une longue période, ce qui entraînera un problème sérieux : les données interrogées ne sont pas les données réelles. dans la base de données.

2. Solution

Lorsque vous utilisez Redis, vous devez maintenir la cohérence de Redis et des données de la base de données. L'une des solutions les plus populaires est la stratégie de double suppression retardée.
Remarque : vous devez savoir que les tables de données fréquemment modifiées ne conviennent pas à l'utilisation de Redis, car le résultat de la stratégie de double suppression est de supprimer les données enregistrées dans Redis, et les requêtes ultérieures interrogeront la base de données. Par conséquent, Redis utilise un cache de données qui lit bien plus que les modifications.
Étapes d'exécution du plan de double suppression différée

1> Supprimer le cache
2> Mettre à jour la base de données
3> Délai de 500 millisecondes (définir le délai d'exécution en fonction de l'activité spécifique)
4> 500 millisecondes ?

Nous devons terminer l'opération de mise à jour de la base de données avant la deuxième suppression de Redis. Imaginez que s'il n'y a pas de troisième étape, il y a une forte probabilité qu'une fois les deux opérations de suppression Redis terminées, les données de la base de données n'aient pas été mises à jour. À ce moment-là, s'il y a une demande d'accès aux données, le problème est. nous l'avons mentionné au début apparaîtra.

4. Pourquoi devez-vous supprimer le cache deux fois ?

Si nous n'avons pas de deuxième opération de suppression et qu'il y a une demande d'accès aux données à ce moment-là, il se peut qu'il s'agisse des données Redis qui n'ont pas été modifiées auparavant. Une fois l'opération de suppression exécutée, Redis sera vide. La demande arrive, la base de données sera consultée, à ce moment-là, les données de la base de données sont déjà des données mises à jour, garantissant la cohérence des données.

2. Pratique du code

1. Introduire les dépendances Redis et SpringBoot AOP

<!-- redis使用 -->
<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- aop -->
<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

2 Écrire des annotations et des aspects AOP personnalisés

ClearAndReloadCache a retardé la double suppression des annotations

/**
 *延时双删
 **/
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Target(ElementType.METHOD)
public @interface ClearAndReloadCache {
    String name() default "";
}

ClearAndReloadCacheAspect a retardé la double suppression des aspects

@Aspect
@Component
public class ClearAndReloadCacheAspect {

@Autowired
private StringRedisTemplate stringRedisTemplate;

/**
* 切入点
*切入点,基于注解实现的切入点  加上该注解的都是Aop切面的切入点
*
*/

@Pointcut("@annotation(com.pdh.cache.ClearAndReloadCache)")
public void pointCut(){

}
/**
* 环绕通知
* 环绕通知非常强大，可以决定目标方法是否执行，什么时候执行，执行时是否需要替换方法参数，执行完毕是否需要替换返回值。
* 环绕通知第一个参数必须是org.aspectj.lang.ProceedingJoinPoint类型
* @param proceedingJoinPoint
*/
@Around("pointCut()")
public Object aroundAdvice(ProceedingJoinPoint proceedingJoinPoint){
    System.out.println("----------- 环绕通知 -----------");
    System.out.println("环绕通知的目标方法名：" + proceedingJoinPoint.getSignature().getName());

    Signature signature1 = proceedingJoinPoint.getSignature();
    MethodSignature methodSignature = (MethodSignature)signature1;
    Method targetMethod = methodSignature.getMethod();//方法对象
    ClearAndReloadCache annotation = targetMethod.getAnnotation(ClearAndReloadCache.class);//反射得到自定义注解的方法对象

    String name = annotation.name();//获取自定义注解的方法对象的参数即name
    Set<String> keys = stringRedisTemplate.keys("*" + name + "*");//模糊定义key
    stringRedisTemplate.delete(keys);//模糊删除redis的key值

    //执行加入双删注解的改动数据库的业务 即controller中的方法业务
    Object proceed = null;
    try {
        proceed = proceedingJoinPoint.proceed();
    } catch (Throwable throwable) {
        throwable.printStackTrace();
    }

    //开一个线程 延迟1秒（此处是1秒举例，可以改成自己的业务）
    // 在线程中延迟删除  同时将业务代码的结果返回 这样不影响业务代码的执行
    new Thread(() -> {
        try {
            Thread.sleep(1000);
            Set<String> keys1 = stringRedisTemplate.keys("*" + name + "*");//模糊删除
            stringRedisTemplate.delete(keys1);
            System.out.println("-----------1秒钟后，在线程中延迟删除完毕 -----------");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();

    return proceed;//返回业务代码的值
    }
}

.

3. candidature. yml

server:
  port: 8082

spring:
  # redis setting
  redis:
    host: localhost
    port: 6379

  # cache setting
  cache:
    redis:
      time-to-live: 60000 # 60s

  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/test
    username: root
    password: 1234

# mp setting
mybatis-plus:
  mapper-locations: classpath*:com/pdh/mapper/*.xml
  global-config:
    db-config:
      table-prefix:
  configuration:
    # log of sql
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    # hump
    map-underscore-to-camel-case: true

4, script user_db.sql

utilisé pour produire des données de test

DROP TABLE IF EXISTS `user_db`;
CREATE TABLE `user_db`  (
  `id` int(4) NOT NULL AUTO_INCREMENT,
  `username` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 8 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of user_db
-- ----------------------------
INSERT INTO `user_db` VALUES (1, '张三');
INSERT INTO `user_db` VALUES (2, '李四');
INSERT INTO `user_db` VALUES (3, '王二');
INSERT INTO `user_db` VALUES (4, '麻子');
INSERT INTO `user_db` VALUES (5, '王三');
INSERT INTO `user_db` VALUES (6, '李三');

5, UserController

/**
 * 用户控制层
 */
@RequestMapping("/user")
@RestController
public class UserController {
    @Autowired
    private UserService userService;

    @GetMapping("/get/{id}")
    @Cache(name = "get method")
    //@Cacheable(cacheNames = {"get"})
    public Result get(@PathVariable("id") Integer id){
        return userService.get(id);
    }

    @PostMapping("/updateData")
    @ClearAndReloadCache(name = "get method")
    public Result updateData(@RequestBody User user){
        return userService.update(user);
    }

    @PostMapping("/insert")
    public Result insert(@RequestBody User user){
        return userService.insert(user);
    }

    @DeleteMapping("/delete/{id}")
    public Result delete(@PathVariable("id") Integer id){
        return userService.delete(id);
    }
}

6, UserService

/**
 * service层
 */
@Service
public class UserService {

    @Resource
    private UserMapper userMapper;

    public Result get(Integer id){
        LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
        wrapper.eq(User::getId,id);
        User user = userMapper.selectOne(wrapper);
        return Result.success(user);
    }

    public Result insert(User user){
        int line = userMapper.insert(user);
        if(line > 0)
            return Result.success(line);
        return Result.fail(888,"操作数据库失败");
    }

    public Result delete(Integer id) {
        LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
        wrapper.eq(User::getId, id);
        int line = userMapper.delete(wrapper);
        if (line > 0)
            return Result.success(line);
        return Result.fail(888, "操作数据库失败");
    }

    public Result update(User user){
        int i = userMapper.updateById(user);
        if(i > 0)
            return Result.success(i);
        return Result.fail(888,"操作数据库失败");
    }
}

3 Test de vérification

1, ID=10, ajouter une nouvelle donnée.

2 Stocker dans Redis

5, mettre à jour le nom d'utilisateur correspondant à l'ID 10 (vérifier le schéma d'incohérence de la base de données et du cache)

Schéma de vérification des incohérences de la base de données et du cache :

Créer un point d'arrêt, simuler Un thread pour exécuter le premier Après une suppression, avant que A ne termine la mise à jour de la base de données, un autre thread B accède à ID=10 et lit les anciennes données.

Utilisez la deuxième suppression et définissez le délai approprié en fonction du scénario commercial. Une fois le cache supprimé deux fois avec succès, le résultat de sortie de Redis sera vide. Ce qui est lu, ce sont les données réelles de la base de données, et il n'y aura aucune incohérence entre le cache de lecture et la base de données.

4. Ingénierie du code

Le code de base est affiché dans la case rouge

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!