Sessions: FilesystemStore의 경쟁 조건

잠금 대신 트랜잭션 기반 시스템은 어떻습니까? Session 개체는 lastModified 필드를 전달할 수 있습니다. 세션을 세션 저장소에 다시 저장하려고하면 마지막으로 읽은 이후 수정되었음을 나타내는 오류가 반환됩니다. 프로그래머는 세션을 다시 가져 와서 재 시도하도록 선택할 수 있습니다.

작동 할 수 있으며 정리해야하는 잠금이없고 교착 상태가 발생할 가능성이 없다는 장점이 있습니다. 요청이 이미 수행 한 작업에 따라 개발자가 의미있는 재 시도를 수행하는 것이 항상 가능한지 확실하지 않습니다. 잠금이 확실히 더 안전한 옵션이라고 생각하지만 API가 실패 가능성을 명확하게 문서화하고 개발자가 이러한 오류를 부지런히 처리하면 트랜잭션이 확실히 작동 할 수 있습니다.

즉, FilesystemStore 트랜잭션을 사용하더라도 잠금을 사용하는 스토리지 백엔드에 대해 API를 준비해야한다고 생각하지만 session.Save() 두 번 이상 호출하는 것을 허용하지 않거나 새로운 session.Release() 도입하는 것을 의미합니다

RediStore에 영향을 미치기 때문에이 문제를 따릅니다. @cless 정보를 주셔서 감사합니다

현재로서는 장기적으로 옳은 일을하는 것 외에는 어떤 선호도 없습니다. :) 물론 기존 API도 유지하고 싶습니다. 또한 사방에 잠금을 추가하면 많은 추가 복잡성과 오버 헤드가 발생하므로 피하는 것도 좋습니다.

이 문제를 해결하는 다른 세션 프레임 워크의 예가 있습니까? 나는 그들이 무엇을하는지 궁금합니다.

기본 PHP 세션 핸들러가 파일 시스템 기반 잠금을 사용한다는 것을 알고 있습니다 (PHP 5.4 tarball에서 방금 확인한 파일이 ext/session/mod_files.c 입니다. ext/standard/flock_compat.c 제공하는 무리를 사용합니다).

php가 명성을 감안할 때 좋은 예인지 확실하지 않지만 현재 내가 아는 유일한 것입니다. 다른 프레임 워크를 찾을 수 있는지 확인하고 문제를 해결하는 방법을 살펴 보겠습니다.

Flask, Pyramid 또는 Django가 이러한 작업을 어떻게 처리하는지 궁금합니다. 시간이 있으면 살펴 보겠습니다. 누구든지 그 코드베이스에 익숙하다면 Rails도 흥미로울 것입니다.

피라미드 와 플라스크 모두 데이터를 저장하기 위해 쿠키를 사용하는 것 같습니다. 나는 문서를 간략히 읽었으므로 내가 틀릴 수 있습니다.

Django는 서버 측 세션 데이터를 지원하므로 해당 코드를 잠시 살펴 보겠습니다.

기본 Django 세션 백엔드는 데이터베이스이며 이것은 내가 익숙하지 않은 Django 데이터베이스 추상화 계층을 사용하므로 해석하기가 어렵습니다. 그러나 파일 시스템 백엔드에서이 주석을 찾았습니다.

        # Write the session file without interfering with other threads
        # or processes.  By writing to an atomically generated temporary
        # file and then using the atomic os.rename() to make the complete
        # file visible, we avoid having to lock the session file, while
        # still maintaining its integrity.
        #
        # Note: Locking the session file was explored, but rejected in part
        # because in order to be atomic and cross-platform, it required a
        # long-lived lock file for each session, doubling the number of
        # files in the session storage directory at any given time.  This
        # rename solution is cleaner and avoids any additional overhead
        # when reading the session data, which is the more common case
        # unless SESSION_SAVE_EVERY_REQUEST = True.
        #
        # See ticket #8616.

이것은 세션 파일 내용이 절대 엉망이되지 않도록 보장하지만 경쟁 조건이 발생할 수 없다는 것을 의미하는 것 같습니다. 장고 경험이 있다면 cless / session @ f84abed 와 같은 테스트 케이스를 보는 것이 좋을 것입니다.
Stackoverflow는 또한 Django가 세션에서 경쟁 조건을 가질 수 있음을 나타내는 것 같습니다. http://stackoverflow.com/search?q=django+session+race+condition

좋습니다. FileSystemStore에는 세션 저장소의 손상을 방지하기 위해 이미 거친 뮤텍스가 있습니다. 일부 요청에 대해 일관성을 유지하기 위해 모든 요청에 ​​대해 많은 오버 헤드를 추가하기 때문에 라이브러리에 추가로 보호 할 가치가 얼마나 있는지 잘 모르겠습니다. 확실히 여기 시나리오는 실현 가능하지만 일반적인 의미에서 다루기에는 아마도 너무 복잡하다고 생각합니다. 지금 일어나는 일이 완전히 괜찮은 경우가 많지만 일부 응용 프로그램에서는 문제가 될 수 있습니다. 어쨌든 주어진 세션에 대해 기내 요청이 하나만있을 것이라고 생각합니다.

실제로 모든 웹 리소스에 존재하는 문제입니다. GET 다음에 정보를 기반으로 한 PUT가있는 경우 동일한 일이 발생하며 그 동안 상황이 변경되었을 수 있습니다.

어쨌든 그게 지금 제 생각이지만 더 논의하게되어 기쁩니다.

장기적으로 이것은 애플리케이션 도메인 문제에 가깝습니다.

cless 시나리오가 게시 된 경우 요청 1이 요청 2가 병렬로 발생할 수있을만큼 충분히 오래 실행될 것으로 예상되는 경우 (예 : Angular.js로 작성된 단일 페이지 애플리케이션 또는 일부 API를 사용하는 비동기 Node.js 앱) 장기 실행 요청은 세션에서 분리되어야하며 그 시점에서 독립적 인 작업자 프로세스로 간주되어야합니다.

물론 이것 중 어느 것도 문제를 직접 해결하지는 않지만 kisielk가 언급했듯이 모든 종류의 잠금을 수행하면 한계에 가까운 경우에 많은 오버 헤드가 추가됩니다.

다음은 세션 경쟁 조건의 영향에 대한 실제 사례입니다. 버그는 디버그하기 어렵고 무작위로 표시되며 개발자와 사용자 모두에게 성가시다. ajax를 광범위하게 사용하는 충분히 큰 응용 프로그램이 주어지면 이러한 경쟁 조건이 조만간 나타날 것입니다.
http://www.hiretheworld.com/blog/tech-blog/codeigniter-session-race-conditions
http://www.chipmunkninja.com/Troubles-with-Asynchronous-Ajax-Requests-g@

비슷한 문제를 다루는 EllisLab / CodeIgniter # 1746에서 전체 스레드를 읽었지만 CodeIgniter가 가끔씩 세션 ID를 강제로 재생성하고 대부분의 논의가이 사실을 중심으로 진행된다는 사실로 인해 문제가 복잡합니다. .

호환되지 않는 방식으로 세션을 변경하거나 기존 애플리케이션을 중단시킬 수있는 API에 미묘한 차이를 도입하는 것을 꺼리는 것을 이해합니다. 그러나 여전히 몇 가지 선택적 잠금이 필요하다고 생각합니다. 다음과 같이 상점 API에 두 가지 기능을 추가하는 것은 어떻습니까?

type Store interface {
    Get(r *http.Request, name string) (*Session, error)
    New(r *http.Request, name string) (*Session, error)
    Save(r *http.Request, w http.ResponseWriter, s *Session) error
    Lock(r *http.Request, name string) error
    Release(r *http.Request, name string) error
}

이러한 기능의 사용은 전적으로 선택 사항이며 (개인적으로 세션에 쓸 모든 요청을 잠그는 것을 권장하지만) 기존 응용 프로그램에 영향을주지 않습니다.

제안 된 잠금 인터페이스에 문제가 있습니다. 잠금이 MySQL과 같은 데이터베이스에 유지되고 잠금을 획득 한 후 데이터베이스 연결이 끊어지면 잠금을 해제 할 수 없으며 세션이 효과적으로 교착 상태가됩니다. 잠금은 어떤 식 으로든 만료되어야하지만 개발자에게 어떻게 노출되어야하는지 잘 모르겠습니다.

내 게시물을 올릴 때 Boj의 답장을 놓쳐서 미안합니다.
장기 실행 요청은 경쟁 조건을 트리거하기위한 요구 사항이 아니라는 점을 기억하는 것이 중요합니다. 내 테스트 케이스의 500ms 절전은 경쟁 조건이 트리거되었는지 확인하기위한 것입니다. 현실 세계에서 이러한 경합 조건은 "짧은"요청에 대해서도 발생하며, 그 빈도는 적습니다. 이것이 바로 디버깅을 어렵게 만드는 원인입니다.

또한 부하가 높으면 짧은 요청도 실행하는 데 시간이 걸릴 수 있다는 점을 염두에 두어야합니다.

@cless 좋은 포인트.

제안 된 인터페이스 변경이 마음에 듭니다.

잠금 만료는 RediStore에 대해 비교적 쉽게 구현할 수 있으며 Redis에는 키에 TTL을 설정할 수있는 EXPIRE 명령이 있습니다.

이러한 종류의 세분화 된 잠금은 많은 유형의 세션 저장소에 대해 여전히 상당히 비효율적이지 않을까요? 그리고 만료도 문제입니다.

문제의 일부는 세션이 더 오래 존재하더라도 저장이 성공할 수 있다는 것입니다. 그렇지 않은 경우 문제를 해결하는 데 큰 도움이되지 않을까요?

@kisielk , 비효율적 인 상점의 예를 들어 줄 수 있습니까? 대부분의 키-값 데이터베이스에는 잠금을 생성 할 수있는 일종의 원자 적 작업이 있습니다. SQL 데이터베이스는 일반적으로 행 기반 잠금에 액세스 할 수 있습니다 (여기에서 세부 사항에 익숙하지 않다고 말해야합니다).
redis와 같은 키-값 저장소의 잠금 방법에는 데이터베이스에 대한 여러 번의 왕복이 필요합니다.
go는 파일 잠금에 액세스하는 교차 플랫폼 방법을 제공하지 않기 때문에 파일 시스템 저장소에 문제가 있습니다. cgo를 사용하면 기본 플랫폼을 지원하는 플랫폼을 만들 수 있다고 생각하지만 아마도 피할 솔루션 일 것입니다.

세션 고정을 방지하기 위해 현재 세션을 제거하고 새 세션으로 바꾸는 것에 대해 이야기하지 않는 한 세션이 더 이상 존재하지 않을 때 저장하는 것이 실제 문제라고 생각하지 않지만 솔직히 이것은 완전히 다른 문제입니다.

@boj , 문제는 프로그래머가 저장을 시도하기 전에 잠금이 아직 만료되지 않았는지 확인할 방법이 필요하다는 것입니다. 잠금 만료 시간은 얼마입니까?

이것은 그것에 대해 가능한 한 가지 방법이지만 내가 그것을 많이 좋아하는지 확신하지 못합니다. 당신은 시계가 갑자기 앞으로 뛰지 않거나 뒤로 물러나지 않는 것에 의존하고 있으며 이것은 안전한 가정이 아닙니다.

func Lock(expiration time.Duration) time.Time {
    // Block here until the lock becomes your. Set the lock to expire after
    // dur+50ms. This extra 50 ms ensures that you never assume you own an
    // expired lock
    return time.Now().Add(expiration)
}

func main() {
    end := Lock(1000 * time.Millisecond)

    // Do your thing here ...
    // time.Sleep(1100 * time.Millisecond)

    if time.Now().After(end) {
        fmt.Println("Lock expired, throw an error")
    } else {
        fmt.Println("Good to go, save the session")
    }
}

@cless 귀하의 전체 댓글은 @kisielk 의 걱정거리를 요약합니다. X는 이것을하고, Y는 그것을하고, Z는 어떤 극단이 관련되지 않는 한 가능하지 않을 수 있습니다. 드물게 발생할 수있는 경합 조건은 바람직하지 않지만, 적어도 현재의 고릴라 / 세션 디자인은 매우 단순하며 최소한의 놀라운 철학의 요소를 따릅니다.

제안한대로 고릴라 / 세션의 인터페이스 부분을 구현하는 것은 매우 간단 할 수 있지만, 똑같이 쉽게 잠금 / 해제를 구현하지 않는 한 백엔드를 쉽게 교체 할 수있는 시나리오를 만듭니다. 효율적인 방식입니다. 당신이 제안한 것과 관련하여 너무 많은 what ifs가있는 것 같습니다. 가장 중요한 것은 "해킹 프로그래밍에 의존하지 않고 백엔드가 이것을 구현할 수 있습니까?", "FileSystemStore에서 FooBarStore로 스왑하려고 시도했지만 그렇지 않습니다." Lock / Release를 구현하는 것으로 보이며 내 프로그램이 예상대로 작동하지 않습니다. "

여기에 세션 별 잠금의 뉘앙스에 대한 좋은 기사가 있습니다.

http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/

우리가 이미 여기에서 결론을 내렸 듯이 무언가 잘못되었을 때 잠금 시간 초과는 이러한 종류의 체계를 구현하는 주요 문제 중 하나입니다. 이것은 더 많은 생각이 필요하고 매우 백엔드 의존적입니다.

Lock / Release 구현에 관해서는 별도의 인터페이스를 사용하여 세션 별 잠금 구현을 선택적으로 만들 수 있습니다. 그런 다음 백엔드가 해당 인터페이스에 대해 어설 션 될 수 있으며이를 구현하지 않는 경우 메모리 내 잠금을 사용하여 기본 구현을 제공 할 수 있습니다.

물론 또 다른 문제는 라이브러리 사용자가 잠금 및 해제를 사용하기 위해 코드를 업데이트해야한다는 것입니다.하지만 그렇지 않으면 지금과 동일한 동작을 할 것입니다.

"인 메모리 잠금을 사용하여 기본 구현을 제공 할 수 있습니다."

요청이로드 밸런싱되는 다중 서버 환경에서는 의미가 없습니다.

세션을 사용하는 기존 코드의 동작을 변경하지 않고 더 자유롭게 올바르게 구현할 수 있기 때문에 잠금에 완전히 다른 인터페이스를 제공한다는 아이디어가 마음에 듭니다.

@boj가 언급했듯이 의미있는 방식으로 데이터베이스 저장소에 메모리 잠금을 제공 할 수는 없습니다. 잠금 기능을 제공하는 부담은 상점 개발자에게있을 것입니다. 잠금 인터페이스가 누락 된 경우 세션이이를 사용하려고 할 때 오류를 반환 할 수 있습니다. 그것은 정말로 문제가되지 않을 것입니다. 만약 기본 스토어가 잠금을 제공한다면 다른 개발자들이이를 따를 것이고 사용자는 최소한의 불편 함을 느끼게 될 것입니다.

메모리 잠금은 일부 상점에서 여전히 의미가 있으며 FilesystemStore 이 좋은 후보라고 생각합니다. 현실적으로는 부하 분산 된 상황에서 파일 시스템 저장소를 사용하지 않을 것입니다 (이론적으로는 네트워크 파일 시스템에서 가능함). 파일 시스템 잠금은 선호되는 것처럼 보이지만 이동 중에 크로스 플랫폼을 구현하기가 어려우며 NFS와 함께 작동한다는 보장도 없습니다.

@boj : 동의했지만 @cless가 지적했듯이 귀하가 보유한 상점의 종류에 따라

저는 @cless에 전적으로 동의하며 세션 잠금 및 성숙한 플랫폼 (예 : PHP)이 세션 저장소에서이를 구현하는 것의 중요성을 강조하고 싶습니다. 파일에서는 'flock'syscall을 사용하고 memcache에서는 'add'작업의 반환 값과 '.lock'접미사 및 만료 집합이있는 추가 키를 사용합니다. 나는 또한 새로운 인터페이스를 갖기위한 @kisielk 의 접근 방식에 동의합니다 ( 'Lock'및 'Release'기능이있는 것이 합리적입니다.이 기능을 사용해 주시겠습니까? Go는 고성능과 안정성을 위해 갈 언어 여야합니다. 예를 들어 일부 구현 (FileSystem, Redis 및 Memcache)을 기꺼이 제공합니다. 몇 가지 새로운 구성 옵션이 필요합니다.

• spinLockWait : 잠금 획득 시도 사이의 휴면 시간 (밀리 초) (기본값 : 150)
• lockMaxWait : 잠금 대기 시간 (기본값 : 30)
• lockMaxAge : 자동으로 해제되기 전에 잠금이 유지 될 수있는 초 (기본값 : lockMaxWait)

이 문제는 최근 업데이트를 보지 못했기 때문에 자동으로 오래된 것으로 표시되었습니다. 며칠 후 자동으로 닫힙니다.