지속성을 위한 Redis Cache 및 Mongo용 아키텍처

지속성을 위한 Redis Cache 및 Mongo용 아키텍처

설정:
사용자가 게시물을 제출하고, 이 게시물을 수백 명, 수천 명 이상의 사용자가 읽는 '트위터와 같은' 서비스를 상상해 보십시오.

제 질문은 캐시와 데이터베이스를 설계하여 빠른 액세스와 많은 읽기에 최적화하면서도 사용자가 이전 게시물을 볼 수 있도록 기록 데이터를 유지하는 가장 좋은 방법에 대한 것입니다.여기서 가정하는 것은 사용자의 90%가 새로운 것에만 관심이 있고 오래된 것에 가끔 액세스할 수 있다는 것입니다.여기서 또 다른 가정은 90%에 대해 최적화하기를 원한다는 것이며, 오래된 10%는 검색하는 데 조금 더 오래 걸리더라도 괜찮습니다.

이것을 염두에 두고, 제 연구는 90%에 대해 캐시를 사용하는 방향을 강하게 지적하고, 그 다음에는 게시물을 다른 장기 지속 시스템에 저장하는 것으로 보입니다.그래서 지금까지 제 생각은 캐시에 Redis를 사용하는 것입니다.장점은 Redis가 매우 빠르다는 것과 많은 사람들에게 게시물을 게시하기에 완벽한 펍/서브를 내장했다는 것입니다.그리고 저는 MongoDB를 보다 영구적인 데이터 저장소로 사용하여 Redis에서 만료될 때 액세스되는 동일한 게시물을 저장하는 것을 고려하고 있었습니다.

질문:
이 건축물은 물을 담을 수 있습니까?이것을 하는 더 좋은 방법이 있습니까?
레디스 & 몽고DB에 게시물을 저장하는 메커니즘과 관련하여, 저는 앱이 2개의 쓰기(첫 번째 - 레디스에 쓰기)를 하게 하고 구독자가 즉시 사용할 수 있도록 하는 것을 생각하고 있습니다.2번째 - 레디스에 저장이 성공하면 즉시 MongoDB에 글을 씁니다.이게 최선의 방법입니까?대신 Redis가 만료된 게시물을 MongoDB 자체에 푸시해야 합니까?저는 이것에 대해 생각했지만, Redis에서 MongoDB로 직접 푸시하는 것에 대한 많은 정보를 찾을 수 없었습니다.

Redis와 MongoDB를 연관시키는 것은 실제로 합리적입니다. 그들은 좋은 팀 플레이어입니다.자세한 내용은 여기에서 확인할 수 있습니다.

redis가 있는 MongoDB

한 가지 중요한 점은 필요한 복원력 수준입니다.Redis 및 MongoDB는 모두 허용 가능한 수준의 복원력을 달성하도록 구성할 수 있으며, 이러한 고려 사항은 설계 시 논의되어야 합니다.또한 배포 옵션에 제약이 있을 수 있습니다. Redis 및 MongoDB 모두에 대해 마스터/슬레이브 복제를 수행하려면 최소 4개의 상자가 필요합니다(Redis 및 MongoDB를 동일한 시스템에 배포해서는 안 됨).

이제 큐잉, pub/sub 등을 위해 Redis를 유지하고 사용자 데이터를 MongoDB에만 저장하는 것이 조금 더 간단해질 수 있습니다.서로 다른 패러다임을 특징으로 하는 두 스토어에 대해 유사한 데이터 액세스 경로(이 작업의 어려운 부분)를 설계할 필요가 없습니다.또한 MongoDB에는 수평 확장성(복제본 세트, 자동 샤딩 등)이 내장되어 있는 반면 Redis에는 자체 확장성만 있습니다.

두 번째 질문과 관련하여, 두 매장 모두에 글을 쓰는 것이 가장 쉬운 방법일 것입니다.Redis 활동을 MongoDB로 복제하는 내장 기능이 없습니다.하지만 Redis 큐(활동이 게시될 위치)를 듣고 MongoDB에 쓰는 데몬을 설계하는 것은 그리 어렵지 않습니다.

언급URL : https://stackoverflow.com/questions/11218941/architecture-for-redis-cache-mongo-for-persistence