전체 글 썸네일형 리스트형 동시성과 gap-lock 동시성 관련해서 이런 이슈를 겪은 적이 있습니다. 해당 포스팅에서 해결 방법을 제시했고 실제로 그렇게 해결을 하였지만, 다른 해결 방법은 또 없을지 고민하는 시간이 길었습니다. 일단 해결 방법을 찾기 위해 동시성과 Lock 에 대해 정리해보려고 합니다. 다음과 같은 목록을 하나씩 짚어나가보겠습니다.2PLrecode-lock 과 gap-lockgap-lock 의 존재이유데드락을 해결하기 위한 방법gap-lock 최소화하면서 동시성 향상시키기 2PL2단계 잠금 프로토콜은 하나의 데이터에 대한 동시 접근을 차단하여 직렬화를 보장하는 DBMS 의 동시성 제어 방법입니다. 트랜잭션 도중에 락을 걸어서 데이터 접근 권한을 선점하는 방식인데요. 각 트랜잭션이 락 획득과 락 해제, 두 단계로 진행해서 2 Phase L.. 더보기 성능과 일관성을 무게추에 달아보자 On Redis ! redis 는 동작이 매우 빠릅니다. replica 와 함께 동작하는 경우에도 그렇습니다. redis 는 왜 빠른가?해당 포스팅에서는 이 궁금증을 따라가보는데에서 출발합니다. 그리고 아래 질문들의 답을 찾아가는 과정입니다. redis 는 왜 kafka 처럼 일관성을 위한 지원이 두둑하지않는가?kafka 대용으로 redis 의 PUB/SUB 은 왜 거론되지않는가? redis 의 replica(복제)는 동기인가 비동기인가? 동기 (또는 비동기) 라면 왜 그럴까?동기/비동기의 방식을 사용자가 컨트롤할 수 있을까? 마치 kafka 의 ISR 설정처럼?redis 에서 쓰기 작업을 손실할 수 있는 케이스는 무엇이 있을까?쓰기가 손실되면 어떤 영향이 있을까?그럼 cluster 는 어떻게 동작하고 있을까? 동기일까 비.. 더보기 오늘도 기획자한테 안 된다고 말했다. 웹 구독 시스템, 주문, 배송, 상품까지 단기간에 많은 프로젝트를 달려왔습니다. 9개월 남짓한 시간동안 다음 문장이 현실되었습니다. | 상품에 대한 주문이 발생하면 구독이 이루어지고 실물 상품에 대한 배송이 예약될 수 있다. 이 문장에 관여하는 많은 데이터들이 있습니다. 당장 상품을 주문하고 결제한 유저들이 그 데이터에 관심있겠지만, 개발자도 해당 데이터를 주시합니다. 그리고 또 관심가질 사람들있는데 운영 실무자들이 그 대상입니다. 개발자를 포함한 운영 실무자들이 상품관리, 회원관리, 주문.. 배송 등등을 관리할 수 있도록 서비스 플랫폼 어드민을 만드는 것이 기나긴 프로젝트의 마지막 테스크였습니다. 특히 어드민은 지금 생각해도 아쉬움이 많습니다. 그 과정을 정리해보려고 합니다. 대략적인 어드민 사이드 메.. 더보기 따닥 이슈와persist context flush 귀뽀연님이 겪으신 이슈를 공유받다가 해결했던 경험을 기록해두려고합니다. 상황은 이러했습니다. 클라이언트에서 따닥이슈로 이력 저장 요청이 중복으로 발생했다. 이때의 에러는 DataIntegrityViolationException 해당 에러를 try - catch 로 잡아서, 500 -> 400 error 로 응답 수정했다. 그리고 log 레벨을 error -> warn 으로 변경했다. 하지만 여전히 500 에러가 발생했고, 변경했던 warning 로그도 당연히 찍히지않았다. 이 에러는 어디서 언제 발생한 것 일까요? 맞춰보세요. 문제의 시발점은 42번 라인입니다. 해당 로직을 타고 들어가보겠습니다. 21번 라인에서 repository.save() 를 수행하고 있습니다. 해당 위치에서 DataIntegrit.. 더보기 서킷브레이커의 사용설명서는 없다 with.연동 라이브러리들 Discovering circuit breakers was the day I first encountered error handling. On a weekend afternoon, errors occurred consecutively across projects within the team. The initial point of error was a service heavily integrated with external systems. Errors originating from this service cascaded to affect other services, spreading like wildfire. circuitBreakers 를 처음 알게 된 건, 에러 대응을 한 날이었습니다. 주말 오후, 팀.. 더보기 믿거나 말거나, 데이터 독이 data dog인 이유 데이터 독을 공부하게 된 계기는 애플리케이션의 인사이트를 얻기 위해서였습니다. 서킷 브레이커 적용시 서비스에 대한 이해도를 높이기 위해서 데이터 독을 공부해야겠다는 생각을 했습니다. 근데 맘 잡고 공부할려니까 참고 서적이 하나도 없었습니다.. 참고할 만한 포스팅 역시 찾질 못했습니다. 그냥 혼자 시간이 될 때마다 조금씩 살펴보는 방식으로 공부를 했는데, 포스팅 하나 나올 정도가 되어보여 정리해보려고 합니다. 데이터 독에는 많은 기능이 있지만. 한 애플리케이션에 대한 이해도를 높이고자한다면 APM 페이지를 참조하면 충분합니다. APM 은 Application Performance Monitoring의 약자입니다. 길게 풀어 읽어보면 해당 페이지에서 어떤 정보를 제공하는지 감을 잡을 수 있습니다. 응답 시간.. 더보기 이전 1 2 3 4 ··· 18 다음
