3PC기법이 생겨난 이유 자체가
2PC에서 코디네이터가 뒤져서 최종 커밋 메세지를 못보내줄 경우 영원히 커밋메세지를 기다리며 블로킹할 가능성이 있어서(이미 일부는 커밋을 완료했을수 있으니)
3PC기법에서 중간의 preCommit단계를 둬서 코디네이터가 뒤졌을때를 대비하자 인데
막상 3PC의 doCommit의 단계에서
코디네이터가 일부한태만 Commit메세지를 보내고 뒤지거나 네트워크 문제로 못보낸 경우
일부는 커밋되고 일부는 롤백되는 현상이 발생하는거아님?
3PC라는게 최종단계에서 동일한 응답을 받아야 함을 전제하는거같은데 맞는거임?
제미나이한태 물어보니 3PC의 기본설계는 타임아웃=커밋 이라는데 이게 맞는진 둘째치고 맞다해도 그럼 반대로 일부는 abort메세지 받고 일부는 타임아웃 이면 누구는 커밋되고 누구는 abort되는건 똑같고..
3PC는 결국 결함이 있는 분산트랜잭션 방식임?
고수없냐고
여기에 2PC/3PC를 아는 사람이 많겠냐고...
여기MSA 고수 많잔아. MSA에 제일 기본이되는 분산트랜잭션을 모른다는게 말이되겠어?
2pc 3pc 라니 언제적 이야기야 ㅋㅋㅋ - dc App
TCC든 SAGA든 지금쓰는게 뭐든지 옛날 기술도 이론을 다 알고있어야지.. 하등 쓸모없는 SORT알고리즘 다 공부하듯이
2pc/3pc 보기전에 가장 기본적인 cap에 대한 고찰을 해보는걸 추천 - dc App
@킥보드 질문에 답이나 해주지 왜 김대기마냥 답변을 해.. CAP 고찰을 해서 뭐 어떻게 하라는거야...
3pc는 네트워크 지연과응답시간이 제한된 환경을 가정함. 따라서 현실에서는 원자성을 보장하기 힘들어 그래서 단일 노드 코디네이션에서 falut tolerant consensus protocol을 쓰지
글을 잘못썼네 단일 코디네이션에서 저걸로 넘어간다는 소리임
우앙 뭔지머르겠다 공부해옴
@글쓴 백갤러(61.79) 내가 이해한바로는 그래. 취준생 이야기라 잘 검증해서 들어
@글쓴 백갤러(61.79) 그리고 tcc 랑 saga는 2pc의 자원 잠금 성능 문제를 해결하기 위해 나온거고
그정도 수준이면 직접 테스트 해보고 외모지상주의 처럼 “자신만의 길”을 찾는게 맞는 것 같은데 - dc App
난 지금 속도의 경지 단련중이라 ㅇㅇ 좀만 기다려라 - dc App
그게뭔데 이 씹덕아
ㅇㅇ 결함있음 split brain 현상 발생함 위에 백갤러가 설명한거 맞음