个人猜想的方案

우선 세션과 쿠키의 차이점을 명확히 해야 합니다. 브라우저 측은 쿠키를 저장합니다. 브라우저가 서버에 요청을 보낼 때마다 HTTP 헤더가 자동으로 쿠키 정보를 추가합니다. 서버는 사용자의 쿠키를 키로 사용하여 저장소에서 해당 값(세션)을 찾습니다.

동일한 도메인 이름의 웹사이트는 모두 동일한 쿠키를 가지고 있습니다. 따라서 서버가 아무리 많아도 경로 없는 요청이 배포되는 서버의 동일한 사용자의 쿠키는
변경되지 않습니다. 즉, 쿠키에 해당하는 세션도 고유합니다.

여러 비즈니스 서버가 동일한 Redis 서버(또는 클러스터)에 액세스하는지 확인하세요. 이것은 당신의 목표를 달성할 것입니다. 그럼 당신의 계획 2가 맞습니다

공유되므로 당연히 동일한 Redis에 저장해야 하며 이는 두 번째 옵션입니다.

Redis를 사용하여 세션을 공유합니다. 핵심은 세션이 Redis에 배포되고 파일 세션이 더 이상 로컬로 배포되지 않는다는 것입니다.

redis를 사용하여 세션을 공유한다는 것은 본질적으로 Redis 인스턴스가 하나만 있다는 것을 의미하지만 이 인스턴스가 Redis 서비스만 시작하는지 아니면 여러 서버에 Redis 클러스터를 배포하는지 여부는 애플리케이션 계층에 따라 다릅니다.

신뢰도가 높은 애플리케이션의 경우 언급한 솔루션 1과 유사하게 Redis를 클러스터에 배포해야 하지만 이러한 Redis는 샤딩 및 중복성을 달성하기 위해 해당 통신 메커니즘이 격리되어 있지 않습니다. 예를 들어, 서버 A의 B에 있는 Redis에 액세스할 수 있고 B에 있는 Redis의 실제 데이터 저장소는 서버 C에 있을 수 있습니다. 이 모든 것이 매우 중요합니다. 애플리케이션(클라이언트)은 모두 블랙박스이므로 신경 쓸 필요가 없습니다.

php.ini에 세션 구성이 있습니다. 구성을 redis 또는 memcache로 변경하고 다른 것은 걱정하지 마세요

개인적으로 세션 공유란 원래 세션에 저장해야 하는 데이터를 Redis로 마이그레이션하여 저장하는 개념일 뿐이라고 생각합니다. 물론, . 세션을 전달한 다음 이를 클라이언트에 전달하고 쿠키에 저장하면 클라이언트는 요청할 때마다 수정된 쿠키를 함께 보낸 다음 Redis에서 해당 데이터를 가져와야 합니다.
사실 공유 세션의 경우 실제로는 공유 캐시일 뿐입니다.

물론 개념을 이야기하는 것입니다. 서버의 실제 세션을 Redis에 직접 저장할 수 있는 도구가 있을 수도 있겠지만 개념은 이런 것 같아요.

실제로 위의 두 가지 솔루션 모두 실현 가능합니다. 우선, 첫 번째 솔루션은 Redis 클러스터를 구축하여 서비스의 안정성과 성능을 향상하고 세션 손실로 이어질 수 있는 단일 실패 지점을 방지할 수 있습니다. 캐시 데이터. 두 번째 옵션은 추가 시스템에서 Redis 서비스를 여는 것입니다. 서비스의 안정성을 향상시키기 위해 마스터-슬레이브 서비스를 구축할 수 있습니다. 쿠키와 세션은 Redis의 키-값과 유사합니다