요구 사항 수정 시 다운스트림 서비스는 특정 비즈니스 데이터 캐시의 유효 시간에 대한 요구 사항을 추가로 제시합니다.
원래 JVM 설계 계획:
jvm 로컬 캐싱 메커니즘을 사용하여 예약된 작업이 30초마다 새로 고쳐집니다.
이제 Redis 솔루션:
- 이 비즈니스 데이터 캐시는 여러 곳에서 사용되기 때문에 사용량을 크게 변경할 수 없습니다.
- 분산 배포이기 때문에 jvm 캐시만 사용하면 다른 서버에 캐시된 데이터를 업데이트할 수 없으며 즉시 적용되지도 않습니다.
- 2차 캐시를 사용하지 않는 이유 : 2차 캐시와 이유는 동일하다 jvm을 먼저 사용하면 redis가 업데이트 되어도 다른 서버에서는 jvm 캐시를 먼저 사용하게 된다. 사용 여부: jvm 로컬 캐시가 더 빠르기 때문에 그게 아키텍처의 부담을 증가시켜야 한다는 요구 사항일 뿐입니다)
따라서 유지 관리를 위해 jvm 비즈니스 캐시의 유지 관리를 redis로 직접 변경합니다.
그런 다음 활성 새로 고침 및 수동 새로 고침 등의 유효 시간을 고려해야 합니다.
- 수동 새로 고침: jvm 캐시의 예약된 작업 메커니즘을 계속 사용하고 30초마다 업데이트됩니다(변경 사항 없음, 원래 메커니즘 사용).
- 활성 새로 고침: 유효 시간이 1초이므로 수정 및 업데이트 직후 캐시를 적극적으로 새로 고쳐야 합니다. (변경 사항이 거의 없고 유지 관리가 모두 하나의 프로젝트에 있으며 mysql 테이블을 모니터링하기 위해 아무것도 사용할 필요가 없습니다.)
수정으로 인한 이익:
- 도구 클래스 BeanUtil.getBean(RedisTemplate.class)에서 주입을 얻는 데 문제가 있습니다.
- redis 파이프라인 파이프라인 속도 향상 redisTemplate.STRINGS.setEx(redisCacheList,refreshTime);
- 분할 아이디어: redis와 같은 더 작은 입도. 하나의 테이블에 하나의 키로 저장된 데이터가 너무 커서 테이블의 키 키에 따라 분할됩니다.