[일반] 오늘부터 새책 읽는다

[밀우(ggbadza2)]

완독 한달이면되냐

[포치포치타타(preheat0897)]

오 이것도 읽어봐야겠다 - dc App

[밀우(ggbadza2)]

카프카 마스터가 될거야

[포치포치타타(preheat0897)]

가즈아아아 - dc App

[야타코이(lkh2926)]

이거 읽다가 머리터져서 지금 요양중임

[밀우(ggbadza2)]

ddia를 완독한 나에게 불가능은업다

[야타코이(lkh2926)]

[さかいもか(magnet5519)]

난 아직도 카프카 언제 쓰는지 모르겠엉 ㅇㅅㅇ

[백갤러 1(122.128)]

로그적재

[밀우(ggbadza2)]

카프카를 어디쓰냐면 카프카는 단순한 이벤트큐를 넘어선 로그db임. 로그기반 메세지브로커의 장점은 데이터를 언제든지 꺼내쓸수있다는점. 일반 메세지큐는 기존 데이터가 손실되면 새로 발급받아야하고 그 비용도 클뿐더러 새로발급받는 데이터라 이전 데이터와 동일함을 보장하지못함. 하지만 카프카는 그걸 보장해줌. 그냥 소비자는 이전 메세지를 읽으면 그만임. 생산자는 자기의 상태변화를 카프카에담아서 계속 쏘고 소비자는 계속 읽어가며 상태를 맞추는거임. 새로 들어오는 소비자도 기존 큐에서 메세지를 가져가서 읽을 뿐임. 그래서 확장성이 매우 뛰어남. 소비자를 계속 붙여줘도 로그db는 유지됨. 대표적으로 쇼핑몰 상품이 바뀌면 그 바뀐 사실을 엘라스틱서치에 동기화해줘야함. 근데 복잡하게 구성할필요없름. 그냥 상품이 변경된 내역을

[밀우(ggbadza2)]

@밀우 카프카에 던지면 그만이고, 엘라스틱서치가 그걸 가져가서 알아서 동기화하도록 시스템을 분리시키면 그만이니까 책임도 분리되고 엘라스틱서치가 터져도 나중에 다시 복구했을때 로그에서 다시 데이터를 가저와서 바로 동기화가가능함. 유사하게 msa시스템에서 사용자정보를 사용자api에 요청하는게 부담일때 사용자에 대한db 사본을 각 서비스단에 저장할수도있음. 이때도 사용자서비스는 그냥 db변경내역을 카프카에 던져주면 자기 책임을 다한거임. 그걸로 사용자복제db를 구축하는건 각각 서비스단의 책임이고 그냥 카프카에서 비동기적으로 끌고올수있는거임.

[밀우(ggbadza2)]

@밀우 비동기라는건은 느슨한 결합을 한다는 소리이고 이로써 사용자서비스가 터져도 각각의 서비스는 사용자 서비스의 최신본을 들고 서비스를 하는게 가능해짐. 전체의 서비스에 대해 내결함성을 확보할수있게되는거임.

[さかいもか(magnet5519)]

@밀우 뭔가 DB 기능이 추가된 메시지 큐 느낌이네 요청에 대해 결과를 신경쓰지 않고 카프카에 책임을 맡긴다 << 이래서 느슨한 결합이고 저런 대규모 서비스가 필요하고 쓰는 곳은 진짜 극소수겠군