모두 Redis 분산 클러스터를 위한 솔루션입니다. 방금 정오에 WeChat을 통해 InfoQ에서 게시한 "효율적인 운영 및 유지 관리를 위한 모범 사례(03): Redis 클러스터 기술 및 Codis 사례"라는 기사를 보았는데 꽤 자세합니다. 는 Redis Cluster의 "무거운" 특성을 목표로 하고 이를 개선하며 twemproxy의 단점도 지적합니다. 아쉽게도 이 글은 InfoQ 홈페이지에는 나오지 않아서 제때 업데이트가 안됐는지 모르겠네요.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
모두 Redis 분산 클러스터를 위한 솔루션입니다. 방금 정오에 WeChat을 통해 InfoQ에서 게시한 "효율적인 운영 및 유지 관리를 위한 모범 사례(03): Redis 클러스터 기술 및 Codis 사례"라는 기사를 보았는데 꽤 자세합니다. 는 Redis Cluster의 "무거운" 특성을 목표로 하고 이를 개선하며 twemproxy의 단점도 지적합니다. 아쉽게도 이 글은 InfoQ 홈페이지에는 나오지 않아서 제때 업데이트가 안됐는지 모르겠네요.
twemproxy의 몇 가지 문제점에 대해 이야기해 보면 redis 클러스터의 장점을 알게 될 것입니다
(1) 이해하기 더 복잡한 완전 비동기식 구현
(2) 부정행위 auto_eject_hosts
(3) 서버 동적으로 추가
는 지원되지 않습니다. (4) mget이 자동으로 분할되어 성능에 영향을 미칩니다
Redis 클러스터는 클라이언트와 서버 간, 서버와 서버 간 통신을 통해 클라이언트의 노드 라우팅 규칙을 업데이트하여 클라이언트의 요청이 항상 올바른 서버 노드로 전송되도록 합니다. 서버 단 한번의 통신만 필요합니다.
Twemproxy는 중간에 추가 통신 계층을 두고 요청을 노드에 배포하는 프록시 역할을 합니다.
이론적으로 Redis 클러스터 성능은 효율적입니다.
물론 구현이 더 복잡하므로 실제로 테스트해야 합니다.
개인적으로 앞으로는 redis 클러스터 방식이 주류가 될 것이라고 생각합니다.