서버에서 많은 양의 데이터를 보여주는 웹 페이지가 있습니다. 통신은 ajax를 통해 이루어집니다.

사용자가 상호 작용하고이 데이터를 변경할 때마다 (사용자 A가 이름을 변경한다고 가정) 서버에 작업을 수행하도록 지시하고 서버는 변경된 새 데이터를 반환합니다.

사용자 B가 동시에 페이지에 액세스하고 새 데이터 객체를 생성하면 다시 ajax를 통해 서버에 알리고 서버는 사용자를 위해 새 객체를 반환합니다.

A의 페이지에는 이름이 변경된 개체가있는 데이터가 있습니다. 그리고 B의 페이지에는 새로운 객체가있는 데이터가 있습니다. 서버에서 데이터에는 이름이 변경된 개체와 새 개체가 모두 있습니다.

여러 사용자가 동시에 사용하는 경우 페이지를 서버와 동기화 상태로 유지하기위한 옵션은 무엇입니까?

전체 페이지를 잠 그거나 변경 될 때마다 사용자에게 전체 상태를 덤프하는 것과 같은 옵션은 오히려 피합니다.

도움이된다면이 특정 예제에서 웹 페이지는 데이터베이스에서 저장 프로 시저를 실행하는 정적 웹 메서드를 호출합니다. 저장 프로시 저는 변경된 데이터 만 반환합니다. 그런 다음 정적 웹 메서드는 저장 프로 시저의 반환을 클라이언트로 전달합니다.

바운티 편집 :

Ajax를 사용하여 서버와 통신하지만 동시성 문제를 방지하는 다중 사용자 웹 애플리케이션을 어떻게 디자인합니까?

즉, 데이터 또는 상태 손상의 위험없이 데이터베이스의 기능 및 데이터에 대한 동시 액세스

개요 :

• 소개
• 서버 아키텍처
• 클라이언트 아키텍처
• 케이스 업데이트
• 사례 커밋
• 충돌 사례
• 성능 및 확장 성

안녕 Raynos,

여기서는 특정 제품에 대해 논의하지 않겠습니다. 다른 사람들이 언급 한 것은 이미 살펴볼 좋은 도구 세트입니다 (해당 목록에 node.js를 추가 할 수도 있음).

아키텍처 관점에서 보면 버전 관리 소프트웨어에서 볼 수있는 것과 동일한 문제가있는 것 같습니다. 한 사용자가 개체에 대한 변경 사항을 확인하고 다른 사용자가 다른 방법으로 동일한 개체를 변경하려고합니다 => 충돌. 사용자 변경 사항을 개체에 통합하는 동시에 업데이트를 적시에 효율적으로 제공하고 위와 같은 충돌을 감지하고 해결해야합니다.

내가 당신의 입장이라면 나는 다음과 같은 것을 개발할 것입니다.

1. 서버 측 :

• "원자 아티팩트"(페이지? 페이지의 개체? 개체 내부의 값?)라고 부르는 것을 정의 할 합리적인 수준을 결정합니다. 이것은 웹 서버, 데이터베이스 및 캐싱 하드웨어, 사용자 수, 개체 수 등에 따라 달라집니다. 쉬운 결정이 아닙니다.

• 각 원자 아티팩트에는 다음이 있습니다.

  • 응용 프로그램 전체의 고유 ID
  • 증가하는 버전 ID
  • 쓰기 액세스를위한 잠금 메커니즘 (뮤텍스 가능)
  • 링 버퍼 내부의 작은 히스토리 또는 "변경 로그"(공유 메모리가 잘 작동 함). 확장 가능성은 낮지 만 단일 키-값 쌍도 괜찮을 수 있습니다. http://en.wikipedia.org/wiki/Circular_buffer 참조

• 연결된 사용자 에게 관련 변경 로그를 효율적 으로 전달할 수있는 서버 또는 의사 서버 구성 요소입니다 . Observer-Pattern은 당신의 친구입니다.

2. 클라이언트 측 :

• 위에 언급 된 서버에 장기 실행되는 HTTP 연결을 가질 수 있거나 가벼운 폴링을 사용하는 자바 스크립트 클라이언트.

• 연결된 자바 스크립트 클라이언트가 감시 된 아티팩트 기록의 변경 사항을 알릴 때 사이트 콘텐츠를 새로 고치는 자바 스크립트 아티팩트 업데이트 프로그램 구성 요소입니다. (다시 한 번 관찰자 패턴이 좋은 선택 일 수 있습니다)

• 뮤텍스 잠금 획득을 시도하면서 원자 아티팩트 변경을 요청할 수있는 자바 스크립트 아티팩트 커미터 구성 요소입니다. 알려진 클라이언트 측 artifact-version-id와 현재 서버 측 artifact-version-id를 비교하여 아티팩트의 상태가 몇 초 전에 다른 사용자에 의해 변경되었는지 감지합니다 (JavaScript 클라이언트 지연 및 커밋 프로세스 요인).

• 사람이 올바른 결정을 내릴 수있는 자바 스크립트 충돌 해결사. 사용자에게 "누군가가 너보다 빠르다. 변경 사항을 삭제했습니다. 가서 울어"라고 말하고 싶지는 않을 것입니다. 다소 기술적 차이 또는 사용자 친화적 인 솔루션의 많은 옵션이 가능해 보입니다.

그래서 어떻게 굴러 갈까요 ...

사례 1 : 업데이트를위한 종류의 시퀀스 다이어그램 :

• 브라우저 렌더링 페이지
• 자바 스크립트는 각각 적어도 하나의 값 필드, 고유 및 버전 ID를 갖는 아티팩트를 "확인"합니다.
• javascript 클라이언트가 시작되어 발견 된 버전에서 시작하여 발견 된 이슈 기록을 "감시"하도록 요청합니다 (이전 변경 사항은 흥미롭지 않음).
• 서버 프로세스는 요청을 기록하고 지속적으로 기록을 확인 및 / 또는 전송합니다.
• 히스토리 항목에는 클라이언트가 독립적으로 또는 전체 데이터 세트를 폴링 할 수 있도록 "아티팩트 x가 변경됨, 클라이언트 pls 요청 데이터"라는 간단한 알림이 포함될 수 있습니다. "아티팩트 x가 값 foo로 변경되었습니다"
• javascript artifact-updater는 업데이트 된 것으로 알려지 자마자 새로운 값을 가져올 수있는 모든 작업을 수행합니다. 새로운 ajax 요청을 실행하거나 자바 스크립트 클라이언트에 의해 공급됩니다.
• 페이지 DOM 콘텐츠가 업데이트되고 사용자에게 선택적으로 알림이 전송됩니다. 역사 관찰은 계속됩니다.

사례 2 : 이제 커밋합니다.

• artifact-committer는 사용자 입력에서 원하는 새 값을 알고 서버에 변경 요청을 보냅니다.
• 서버 측 뮤텍스가 획득 됨
• 서버가 "이봐, 버전 123에서 아티팩트 x의 상태를 알고 있습니다. 값을 foo pls로 설정하겠습니다."
• 아티팩트 x의 서버 측 버전이 123보다 같으면 (작을 수 없음) 새 값이 허용되고 새 버전 ID 124가 생성됩니다.
• 새로운 상태 정보 "버전 124로 업데이트 됨"과 선택적으로 새로운 값 foo가 아티팩트 x의 링 버퍼 (변경 로그 / 이력)의 시작 부분에 배치됩니다.
• 서버 측 뮤텍스가 출시되었습니다.
• 아티팩트 커미터를 요청하면 새 ID와 함께 커밋 확인을 받게되어 기쁩니다.
• 한편 서버 측 서버 구성 요소는 링 버퍼를 연결된 클라이언트에 계속 폴링 / 푸시합니다. 아티팩트 x의 버퍼를보고있는 모든 클라이언트는 일반적인 대기 시간 내에서 새로운 상태 정보와 값을 얻습니다 (케이스 1 참조).

사례 3 : 충돌 :

• 아티팩트 커미터는 사용자 입력에서 원하는 새 값을 알고 서버에 변경 요청을 보냅니다.
• 한편 다른 사용자가 동일한 아티팩트를 성공적으로 업데이트했지만 (케이스 2 참조) 다양한 지연으로 인해 다른 사용자에게는 아직 알려지지 않았습니다.
• 따라서 서버 측 뮤텍스가 획득됩니다 (또는 "빠른"사용자가 변경 사항을 커밋 할 때까지 기다림)
• 서버는 "이봐, 버전 123에서 아티팩트 x의 상태를 알고 있습니다. 값을 foo로 설정하겠습니다."
• Serverside에서 artifact x의 버전은 이미 124입니다. 요청 클라이언트는 자신이 덮어 쓰게 될 값을 알 수 없습니다.
• 분명히 서버는 변경 요청을 거부하고 (신이 개입하는 덮어 쓰기 우선 순위에 포함되지 않음) 뮤텍스를 해제하고 새 버전 ID와 새 값을 클라이언트에 직접 보낼 수있을만큼 친절합니다.
• 거부 된 커밋 요청과 변경 요청 사용자가 아직 알지 못한 값에 직면했을 때 자바 스크립트 아티팩트 커미터는 사용자에게 문제를 표시하고 설명하는 충돌 해결자를 참조합니다.
• 스마트 충돌 해결 프로그램 JS에 의해 몇 가지 옵션이 제공되는 사용자는 값을 변경하려는 또 다른 시도가 허용됩니다.
• 사용자가 옳다고 생각하는 값을 선택하면 프로세스가 사례 2 (또는 다른 사람이 더 빠르면 사례 3)부터 다시 시작됩니다.

성능 및 확장성에 대한 몇 마디

HTTP 폴링과 HTTP "푸싱"

• 폴링은 허용 가능한 지연 시간으로 간주되는 모든 요청을 초당 1 회, 초당 5 회 생성합니다. (Apache?) 및 (php?)를 "경량"스타터로 구성하지 않으면 인프라에 다소 잔인 할 수 있습니다. 폴링 간격의 길이보다 훨씬 짧은 시간 동안 실행되도록 서버 측에서 폴링 요청을 최적화하는 것이 바람직합니다. 해당 런타임을 절반으로 분할하면 전체 시스템 부하를 최대 50 %까지 줄일 수 있습니다.
• HTTP를 통해 추진 한 아파치 / lighthttpd 각 사용자에 대해 사용 가능한 처리하도록 요구합니다 (가정 webworkers 너무 멀리 그들을 지원하는 꺼져) 모든 시간을 . 이러한 각 프로세스 및 시스템 총 메모리에 대해 예약 된 상주 메모리는 매우 특정한 확장 제한 중 하나입니다. 연결의 메모리 사용량을 줄이고 이들 각각에서 수행되는 연속 CPU 및 I / O 작업의 양을 제한해야합니다 (많은 절전 / 유휴 시간이 필요함).

백엔드 확장

• 데이터베이스와 파일 시스템을 잊어 버려, 당신은 할 필요 (클라이언트가 직접 다음 실행중인 각 서버 프로세스 것 폴링하지 않는 경우) 자주 폴링에 대한 공유 메모리 기반의 백엔드의 일종
• Memcache를 사용하면 더 잘 확장 할 수 있지만 여전히 비쌉니다.
• 커밋에 대한 뮤텍스는 부하 분산을 위해 여러 프런트 엔드 서버를 사용하려는 경우에도 전역 적으로 작동해야합니다.

프런트 엔드 확장

• 폴링 또는 "푸시"수신 여부에 관계없이 모든 시청 된 아티팩트에 대한 정보를 한 번에 얻으십시오.

"창의적인"비틀기

• 클라이언트가 폴링하고 많은 사용자가 동일한 아티팩트를 보는 경향이있는 경우 해당 아티팩트의 히스토리를 정적 파일로 게시하여 아파치가 아티팩트가 변경 될 때이를 서버 측에서 새로 고칠 수 있도록 허용 할 수 있습니다. 이것은 요청을 위해 게임에서 PHP / memcache를 제거합니다. Lighthttpd는 정적 파일을 제공하는 데 매우 효율적입니다.
• cotendo.com과 같은 콘텐츠 전송 네트워크를 사용하여 아티팩트 기록을 푸시합니다. 푸시 대기 시간은 더 커지지 만 확장 성은 꿈입니다.
• 사용자가 java 또는 flash (?)를 사용하여 연결하는 실제 서버 (HTTP를 사용하지 않음)를 작성합니다. 하나의 서버 스레드에서 많은 사용자에게 서비스를 제공해야합니다. 열린 소켓을 순환하고 필요한 작업을 수행 (또는 위임)합니다. 포크 프로세스 또는 더 많은 서버 시작을 통해 확장 할 수 있습니다. 뮤텍스는 전역 적으로 고유해야합니다.
• 로드 시나리오에 따라 아티팩트 ID 범위별로 프런트 엔드 및 백엔드 서버를 그룹화합니다. 이렇게하면 영구 메모리를 더 잘 사용할 수 있으며 (데이터베이스에 모든 데이터가 없음) 뮤텍스를 확장 할 수 있습니다. 하지만 자바 스크립트는 여러 서버에 대한 연결을 동시에 유지해야합니다.

이것이 여러분 자신의 아이디어를위한 시작이되기를 바랍니다. 더 많은 가능성이 있다고 확신합니다. 이 게시물에 대한 비판이나 개선 사항을 환영하는 것 이상으로 위키가 활성화되었습니다.

크리스토프 스트라 센

나는 이것이 오래된 질문이라는 것을 알고 있지만 나는 그냥 차임으로 생각했습니다.

OT (operational transforms) 는 동시적이고 일관된 다중 사용자 편집에 대한 요구 사항에 적합합니다. Google 문서에서 사용 되는 기술 이며 Google Wave에서도 사용되었습니다.

Google Wave 팀 구성원이 작성한 Operational Transforms-ShareJS ( http://sharejs.org/ ) 를 사용하기위한 JS 기반 라이브러리가 있습니다.

원하는 경우 모든 것을 수행하는 ShareJS에 구축 된 전체 MVC 웹 프레임 워크 인 DerbyJS ( http://derbyjs.com/ )가 있습니다.

그것은 서버와 클라이언트 간의 통신을 위해 BrowserChannel을 사용합니다 (그리고 WebSockets 지원이 작동해야한다고 생각합니다-이전에 Socket.IO를 통해 거기에 있었지만 Socket.io에 대한 개발자의 문제로 인해 제거되었습니다) 초보자 문서는 그러나 지금은 약간 희박합니다.

각 데이터 세트에 시간 기반 수정 스탬프를 추가하는 것을 고려할 것입니다. 따라서 db 테이블을 업데이트하는 경우 그에 따라 수정 된 타임 스탬프를 변경합니다. AJAX를 사용하면 클라이언트의 수정 된 타임 스탬프를 데이터 소스의 타임 스탬프와 비교할 수 있습니다. 사용자가 뒤처진 경우 디스플레이를 업데이트합니다. 이 사이트가 정기적으로 질문을 확인하여 답변을 입력하는 동안 다른 사람이 답변했는지 확인하는 것과 유사합니다.

푸시 기술 (Comet 또는 Reverse Ajax라고도 함)을 사용하여 db에 변경 사항이 작성되는 즉시 사용자에게 전파해야합니다. 현재 사용 가능한 가장 좋은 기술은 Ajax 긴 폴링으로 보이지만 모든 브라우저에서 지원되지는 않으므로 폴 백이 필요합니다. 다행히도 이미이를 처리하는 솔루션이 있습니다. 그중에는 orbited.org와 이미 언급 한 socket.io가 있습니다.

앞으로 WebSockets라고하는 더 쉬운 방법이있을 것입니다. 그러나 표준의 현재 상태에 대한 보안 문제가 있기 때문에 해당 표준이 언제 황금 시간대에 준비 될지는 아직 확실하지 않습니다.

새 개체를 사용하여 데이터베이스에 동시성 문제가 있어서는 안됩니다. 그러나 사용자가 개체를 편집 할 때 서버에는 그 동안 개체가 편집되었는지 또는 삭제되었는지 확인하는 로직이 있어야합니다. 개체가 삭제 된 경우 해결 방법은 간단합니다. 편집 내용을 삭제하면됩니다.

그러나 가장 어려운 문제는 여러 사용자가 동시에 같은 개체를 편집 할 때 나타납니다. 사용자 1과 2가 동시에 개체 편집을 시작하면 둘 다 같은 데이터를 편집합니다. 사용자 2가 데이터를 편집하는 동안 사용자 1이 변경 한 내용이 먼저 서버로 전송된다고 가정 해 보겠습니다. 그런 다음 두 가지 옵션이 있습니다. 사용자 1의 변경 사항을 사용자 2의 데이터에 병합하거나 사용자 2에게 데이터가 오래되었음을 알리고 데이터가 서버로 전송되는 즉시 오류 메시지를 표시 할 수 있습니다. 후자는 여기서 매우 사용자 친화적 인 옵션은 아니지만 전자는 구현하기가 매우 어렵습니다.

처음으로이 문제를 해결 한 몇 안되는 구현 중 하나는 Google이 인수 한 EtherPad 입니다. 나는 그들이 Google Docs와 Google Wave에서 EtherPad의 기술 중 일부를 사용했다고 생각하지만 확실히 말할 수는 없습니다. Google은 또한 EtherPad를 오픈 소스로 제공하므로 수행하려는 작업에 따라 살펴볼 가치가 있습니다.

지연으로 인해 웹에서 원자 적 연산을 수행 할 수 없기 때문에 동시에 편집 작업을 수행하는 것은 정말 쉽지 않습니다. 아마 이 기사는 당신이 주제에 대한 자세한 내용을 보려면하는 데 도움이 될 것입니다.

이 모든 것을 직접 작성하는 것은 큰 일이며 올바르게 작성하는 것은 매우 어렵습니다. 한 가지 옵션은 클라이언트가 데이터베이스와 실시간으로 동기화되도록 구축 된 프레임 워크를 사용하는 것입니다.

Meteor 프레임 워크가이 작업을 잘 수행하는 것으로 나타났습니다 ( http://docs.meteor.com/#reactivity ).

"Meteor는 반응 형 프로그래밍의 개념을 수용합니다. 즉, 간단한 명령형 스타일로 코드를 작성할 수 있으며 코드가 의존하는 데이터가 변경 될 때마다 결과가 자동으로 다시 계산됩니다."

"이 간단한 패턴 (반응 형 계산 + 반응 형 데이터 소스)은 폭 넓은 적용 가능성을 가지고 있습니다. 프로그래머는 구독 취소 / 재 구독 호출을 작성하고 적시에 호출되는지 확인하여 데이터 전파 코드의 전체 클래스를 제거합니다. 오류가 발생하기 쉬운 논리가있는 응용 프로그램입니다. "

아무도 Meteor 를 언급하지 않았다는 것을 믿을 수 없습니다 . 확실히 새롭고 미성숙 한 프레임 워크이지만 (공식적으로 하나의 DB 만 지원함) 포스터가 설명하는 것과 같은 다중 사용자 앱 에서 모든 지저분한 작업과 생각 이 필요 합니다 . 사실, 다중 사용자 라이브 업데이트 앱을 빌드 할 수 없습니다. 다음은 간단한 요약입니다.

• 모든 것이 node.js (JavaScript 또는 CoffeeScript)에 있으므로 클라이언트와 서버간에 유효성 검사와 같은 항목을 공유 할 수 있습니다.
• 웹 소켓을 사용하지만 이전 브라우저로 대체 할 수 있습니다.
• 백그라운드에서 서버로 전송되는 변경 사항과 함께 로컬 개체에 대한 즉각적인 업데이트 (즉, UI가 깔끔한 느낌)에 중점을 둡니다. 원자 적 업데이트 만 믹싱 업데이트를 더 간단하게 만들 수 있습니다. 서버에서 거부 된 업데이트는 롤백됩니다.
• 보너스로 라이브 코드 재로드를 처리하고 앱이 급격히 변경되는 경우에도 사용자 상태를 유지합니다.

Meteor는 적어도 훔칠 아이디어를 찾아 보라고 제안 할만큼 간단합니다.

이 위키 백과 페이지에 대한 학습에 추가 관점 도움이 될 수 있습니다 동시성 과 동시 컴퓨팅 설계를위한 AJAX 웹 응용 프로그램 중 하나 것을 당긴 또는이다 밀려 상태 이벤트 ( EDA ) 메시지를 A의 메시징 패턴을 . 기본적으로 메시지는 변경 이벤트 및 동기화 요청에 응답하는 채널 구독자에게 복제됩니다.

• https://en.wikipedia.org/wiki/Category:Concurrency_control
• https://en.wikipedia.org/wiki/Distributed_concurrency_control
• https://en.wikipedia.org/wiki/CAP_theorem
• https://en.wikipedia.org/wiki/Operational_transformation
• https://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

동시 웹 기반 협업 소프트웨어 에는 여러 형태가 있습니다 .

가 있습니다 etherpad 라이트에 대한 API 클라이언트 라이브러리 HTTP 하는 협력 실시간 편집기 .

django-realtime-playground 는 Socket.io 와 같은 다양한 실시간 기술을 사용하여 Django에서 실시간 채팅 앱을 구현합니다 .

AppEngine과 AppScale은 모두 AppEngine 채널 API를 구현합니다 . 이는 googledrive / realtime-playground에서 시연 하는 Google Realtime API 와는 다릅니다 .

서버 측 푸시 기술이 여기로가는 길입니다. 혜성 은 유행어입니다.

당신이 취하는 특정 방향은 당신의 서버 스택과 당신의 유연성에 따라 크게 달라집니다. 가능하다면 서버와의 양방향 통신을 가능하게하여 서버가 클라이언트에 업데이트를 푸시 할 수 있도록하는 매우 효율적인 방법을 제공하는 웹 소켓의 크로스 브라우저 구현을 제공하는 socket.io를 살펴 보겠습니다 .

특히 귀하가 설명하는 상황을 거의 정확하게 보여주는 라이브러리 작성자 의이 데모를 참조하십시오 .