springboot는 어떻게 redis를 통합하여 파티션을 수정합니까?

springboot는 Redis를 통합하여 파티션을 수정합니다

문제의 원인

최근에는 Redis를 통합하는 데 springboot가 사용됩니다. 시스템 동적 데이터 소스는 다른 데이터베이스에 연결하고 사용된 Redis를 캐시해야 합니다. 다른 Redis 파티션, 즉 라이브러리에서 다릅니다.

이전 버전 솔루션

여기서 이전 버전은 2.0 이전 버전을 의미합니다. 제가 사용한 1.5.9는 괜찮습니다.

redis의 구성 클래스는 여기에 게시되지 않으며 온라인에 많이 있습니다.

1. JedisConnectionFactory를 사용하여

@Autowired
JedisConnectionFactory jedisConnectionFactory;
jedisConnectionFactory.setDatabase(database);

2. redisTemplate을 사용하여

redisTemplate.getConnectionFactory().getConnection().select(database);

를 수정합니다. 위 두 가지 방법은 Redis 구성 클래스에 Bean을 특별히 추가할 필요가 없습니다.

새 버전 솔루션

새 버전 여기서는 2.0 이후를 의미합니다. 예, 저는 2.0.3을 사용하고 있습니다

다음 빈을 Redis 구성 클래스에 추가해야 합니다

@Bean
    RedisStandaloneConfiguration redisStandaloneConfiguration() {
        RedisStandaloneConfiguration redisStandaloneConfiguration = new RedisStandaloneConfiguration();
        redisStandaloneConfiguration.setHostName("localhost");
        redisStandaloneConfiguration.setPort(6379);
        redisStandaloneConfiguration.setDatabase(0);
        return redisStandaloneConfiguration;
    }
    @Bean
    JedisConnectionFactory jedisConnectionFactory(RedisStandaloneConfiguration redisStandaloneConfiguration) {
        //redisStandaloneConfiguration.setPassword(RedisPassword.of(password));
        JedisClientConfiguration.JedisClientConfigurationBuilder jedisClientConfiguration = JedisClientConfiguration.builder();
        jedisClientConfiguration.connectTimeout(Duration.ofMillis(0));//  connection timeout
        JedisConnectionFactory factory = new JedisConnectionFactory(redisStandaloneConfiguration,
                jedisClientConfiguration.build());
        return factory;
    }

RedisStandaloneConfiguration을 사용하여

@Autowired
RedisStandaloneConfiguration redisStandaloneConfiguration;
redisStandaloneConfiguration.setDatabase(database);

redis 파티션

데이터가 여러 Redis 인스턴스에 배포되는 방식

파티셔닝은 귀하의 것입니다. 데이터는 여러 Redis 인스턴스에 분산되어 각 인스턴스에는 데이터의 일부만 포함됩니다.

파티션이 유용한 이유

Redis 파티셔닝에는 두 가지 주요 목표가 있습니다.

1. 많은 컴퓨터의 결합된 메모리를 사용하여 더 큰 데이터베이스를 사용할 수 있습니다. 파티션을 나누지 않으면 단일 컴퓨터의 메모리로 제한됩니다.

2. 컴퓨팅 성능을 여러 코어와 여러 컴퓨터로 확장하고 네트워크 대역폭을 여러 컴퓨터와 네트워크 어댑터로 확장할 수 있습니다.

4개의 Redis 인스턴스(R0, R1, R2, R3)가 있고 여기에 user:1, user:2 등과 같이 사용자를 나타내는 많은 키가 있다고 가정하고 키를 저장할 때 이를 수행할 수 있는 방법은 여러 가지가 있습니다.

가장 간단한 방법은 범위별로 분할하는 것, 즉 객체의 매핑 범위에 따라 지정된 Redis 인스턴스에 데이터를 할당하는 것입니다. 예를 들어, 0부터 10000까지의 ID를 가진 것은 R0에 할당되고, 10001부터 20000은 R1에 할당되도록 규정합니다. 이 방법도 가능하지만, 이 매핑 관계를 유지하려면 테이블이 필요하다는 단점이 있습니다. 이 테이블은 관리되어야 하며 각 키에는 그러한 테이블이 하나씩 필요하므로 Redis의 범위 파티셔닝은 다른 파티셔닝 방법보다 훨씬 덜 효율적이기 때문에 일반적으로 눈살을 찌푸리게 됩니다.

범위 분할 외에 또 다른 방법은 해시 분할입니다.

1단계. 키를 가져와 해시 함수를 적용하여 숫자로 변환합니다. 예를 들어, 키가 foobar이고 해시 함수가 crc32인 경우 crc32(foobar)는 93024922를 출력합니다.

2단계. 이 숫자에 모듈로 산술(modulo)을 사용하여 0에서 3까지의 직접 숫자로 변환하면 이 숫자가 내 Redis 인스턴스 4개 중 하나에 매핑될 수 있습니다. 예를 들어 93024922 % 4 = 2이므로 foobar는 R2 인스턴스에 저장되어야 합니다.

(PS: 먼저 키에 대해 해시 연산을 수행하여 숫자를 얻은 다음 이 숫자의 모듈로를 취하여 최종 데이터를 저장할 인스턴스를 결정합니다.)

분할 방법에는 여러 가지가 있습니다. 위의 두 가지 예를 이해하실 수 있을 것입니다. 고급 형태의 해시 파티셔닝을 일관된 해싱이라고 하며 여러 Redis 클라이언트 및 브로커에 의해 구현됩니다.

다양한 파티션 구현

클라이언트 파티셔닝: 주어진 키에 대해 클라이언트는 읽고 쓰기 위한 올바른 노드를 직접 선택합니다. 많은 Redis 클라이언트는 클라이언트 측 파티셔닝을 구현합니다.

프록시 파티션: 클라이언트가 프록시에 요청을 보내고 프록시는 Redis와 통신합니다. 구성에 따라 올바른 Redis 인스턴스를 선택합니다.

쿼리 라우팅: 쿼리를 Redis 인스턴스로 보낼 수 있으며 인스턴스는 쿼리를 올바른 서버로 리디렉션합니다.

(PS: 특정 키에 대해 파티셔닝 작업은 올바른 Redis 인스턴스를 선택하는 것이며, 이 선택 프로세스는 클라이언트, 에이전트 또는 Redis 인스턴스에서 수행할 수 있습니다.)

파티셔닝의 단점

1, 여러 작업이 관련된 작업 키는 일반적으로 지원되지 않습니다. 두 개의 서로 다른 Redis 인스턴스에 매핑된 키의 경우 삽입 작업을 수행할 수 없습니다.

2. Redis 트랜잭션은 여러 키를 포함하는 작업에 사용할 수 없습니다

3. 파티션 세분성이 중요하므로 매우 큰 단일 키(예: 매우 큰 정렬 세트)로 데이터를 분할하는 것은 불가능합니다. 4, 파티션을 사용하면 데이터 처리가 더 복잡해집니다. 인스턴스의 경우 여러 RDB/AOF 파일을 처리해야 합니다. 데이터를 백업하려면 여러 인스턴스와 호스트에서 영구 파일을 집계해야 합니다.

5. 용량(공간) 추가 및 삭제가 더 복잡해집니다. 예를 들어 Redis 클러스터는 런타임에 노드를 추가하고 제거하는 투명한 데이터 재조정을 지원하지만 클라이언트 파티션 및 브로커와 같은 다른 시스템은 이 기능을 지원하지 않습니다. 그러나 사전 샤딩이라는 기술이 이와 관련하여 도움이 됩니다.

데이터 저장 또는 캐시?

Redis를 데이터 저장소로 사용하는 경우 지정된 키는 항상 동일한 Redis 인스턴스에 매핑되어야 합니다. 캐시로 사용될 때 특정 노드를 사용할 수 없게 되어도 큰 문제는 아닙니다.

일관적인 해싱 구현은 일반적으로 특정 키에 대해 선호하는 노드를 사용할 수 없는 경우 다른 노드로 전환할 수 있습니다. 마찬가지로, 새 노드가 추가되면 새 키 중 일부가 새 노드에 저장되기 시작합니다.

• Redis를 캐시로 사용하는 경우 일관된 해싱을 사용하여 확장하기 쉽습니다.

• Redis를 스토리지로 사용하는 경우 고정된 키-노드 매핑이 사용되므로 노드 수는 고정되어야 하며 변경할 수 없습니다. Redis 클러스터는 노드 간에 키의 균형을 재조정해야 하는 경우 실행 가능한 시스템입니다.

위 내용은 springboot는 어떻게 redis를 통합하여 파티션을 수정합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!