나는 올바른 길을 가고 있는지 알아 내려고합니다. 나는 (실시간) 통계/분석 서비스를 구축하고 있으며 일부 세트와 해시를 저장하기 위해 redis를 사용합니다.크기를 조정하는 방법으로 일관된 해싱을 사용합니다.
이제 내가 어떤 성공을 거두었다고 가정 해 봅시다. 수평 확장이 필요합니다. 해시 링 기법은 멋지지만 캐시 시나리오에만 적합하다는 인상을받습니다.
노드가 다운되면 어떻게됩니까? 이론 상으로는 키가 다른 노드에 의해 소유됩니다. 실제로는 데이터가 없습니다. 잃어 버렸지, 그렇지? 노드 추가/제거와 동일합니다.
일부 근본적인 것이 누락 되었습니까? 이것은 가난한 사람의 집단 일 수 있습니까?
클러스터의 여러 노드를 사용하는 두 가지 이유가 있습니다 : 데이터없이 제거 할 노드를 읽어 부하를 줄일 수 있도록
두 가지가 근본적으로 다르지만 하나의 노드가 아닌 표준 마스터/슬레이브 설정을 사용하여 일관된 해싱을 사용하여 노드 집합을 가리킬 수 있습니다.
클러스터가 캐시가 아닌 기본 데이터 저장소 인 경우 데이터를 복사하는 것과 같은 다른 재배포 전략이 필요합니다.
내 구현은 클라이언트가 해시에 대해 64k 버킷 중 하나를 선택하고 해당 버킷을 노드에 매핑하는 테이블을 갖는 것을 기반으로합니다. 처음에는 모두 노드 # 1에 매핑됩니다.
노드 # 1이 너무 커지면 슬레이브가 마스터 노드 # 2가되고 노드 # 1 키의 절반을 노드 # 2에 매핑하도록 테이블이 업데이트됩니다. 이 시점에서 모든 읽기 및 쓰기가 새로운 매핑과 함께 작동하므로 잘못된 노드에있는 키를 정리하면됩니다. 성능 요구 사항에 따라 한 번에 모든 키를 확인하거나 만료 시스템 에서처럼 임의의 키 선택을 확인할 수 있습니다.
이것은 똑똑합니다! 통찰력을 주셔서 감사합니다 :-) –