소개
안녕하세요.
실용주의 프로그래머가 되고 싶은 평범한 엔지니어입니다.
- (前) 카카오엔터프라이즈 소프트웨어 엔지니어
- (前) 카카오 Ground X 소프트웨어 엔지니어
강의
전체2수강평
- 수준높은 강의 감사합니다.
강창환
2024.05.07
0
- 쉽게 접하기 힘든 주제의 강의을 접할 수 있어서 좋았습니다. 앞으로도 다양한 주제의 강의를 해주시면 좋을 것 같습니다.
ryuu.public
2024.05.06
0
게시글
질문&답변
2024.05.26
토스 개발자센터 들어가서 토스에서 지원하는 키 제공을 안해주네요...
안녕하세요~ 질문 남겨주셔서 감사합니다. 주말에 열심히 강의 들으시고 계신데 불편하셨을거 같아요. 이전에 나왔던 질문이라 답변한 적이 있어서 관련 링크 붙혀둘게요~ 해당 강좌 수업 노트에도 붙혀놓긴 했었는데, 인프런에서 강의에서 자주 하는 질문 리스트 이런 내용들을 볼 수 있는 페이지가 있으면 좋긴 하겠네요.. https://www.inflearn.com/questions/1253630/%ED%86%A0%EC%8A%A4-%ED%8E%98%EC%9D%B4%EB%A8%BC%EC%B8%A0-%EA%B2%B0%EC%A0%9C%EC%9C%84%EC%A0%AF-%EC%97%B0%EB%8F%99-api-%ED%82%A4-%EB%B9%84%ED%99%9C%EC%84%B1%ED%99%94
- 0
- 2
- 93
질문&답변
2024.05.21
wallet service 구축에서 중복메시지 검증 로직이 필요한지 궁금합니다
안녕하세요~ 질문 남겨주셔서 감사합니다. 카프카 프로듀서에서 enable.idempotence=true 설정을 한다면 멱등성 프로듀서가 되서 중복 메시지는 발행안되는 건 맞습니다. 멱등성 프로듀서의 중복 메시지 제거 기법은 프로듀서 ID 와 메시지 Sequence Number 를 통해 중복을 제거하는데요. 중요한 건 프로듀서 어플리케이션이 새롭게 시작하는 경우 똑같은 프로듀서 ID 를 재발급 받을 수 없다는거에요. 그래서 이건 해당 프로듀서 어플리케이션이 살아있는 세션 내에서만 메시지 발행이 중복이 되지 않습니다. 만약 멱등성 프로듀서 어플리케이션이 메시지를 보내다가 죽은 경우, 다시 재부팅되서 메시지를 보내는 경우에는 두 개의 메시지가 전송되는 케이스는 존재하는거죠. 그래서 엄격하게 메시지 발행을 하나로만 보장하려면 카프카 트랜잭션을 사용해야하는거죠. 물론 현재 저희 어플리케이션에서는 Payment Service 가 트랜잭셔널 아웃박스 패턴으로 메시지를 하나만 발행하고 있기 때문에 메시지는 여러건 발행되지 않으므로 의미는 없긴합니다. 그리고 여담이긴 하지만 저 같은 경우는 일관성이 엄격하게 중요한 어플리케이션에서 하나만 믿고 로직을 작성하기 보다는 불확실한 것들이 있는 경우에는 여러가지 케이스를 고려해서 2차까지 방어 로직을 작성하는 것을 선호합니다. 도움이 되셨으면 좋겠네요. 감사합니다.
- 0
- 2
- 62
질문&답변
2024.05.21
완강!!!!!!!!!!!!!!
축하드립니다~~ 주말에도 열심히 하시는 것 같던데 항상 좋은 결과 있길 바랄게요. 질문도 필요하시면 언제든지 주세요~
- 1
- 2
- 77
질문&답변
2024.05.18
테스트 시 오류
안녕하세요~ 질문 남겨주셔서 감사합니다. 똑같이 따라 한 것 같은데 무결성 제약 조건이 나서 불편하셨겠네요.. 에러 메시지를 보니까 외래 키 제약 조건 위반을 나타내는 것 같네요. 이 경우, ledger_entries 테이블에 데이터를 삽입하려고 할 때 transaction_id 열의 값이 ledger_transaction 테이블의 id 열에 존재하지 않는 값이기 때문에 발생한 것으로 보입니다. ledger_entries 테이블에 삽입하려고 하는 transaction_id 값이 ledger_transaction 테이블의 id 열에 존재하지 않기 때문에 이 에러가 발생한 것으로 보이는데요. 비즈니스 로직이나 테스트 코드 로직을 다시 검토해보시는걸 추천드립니다~ 제 프로젝트에서는 잘되는데 왜 안되는지 모르겠군요..
- 0
- 1
- 91
질문&답변
2024.05.13
실무에서 prefix index를 어떤 요구사항이 있을때 사용하는지 궁금합니다!
안녕하세요~ 질문 남겨주셔서 감사합니다. 먼저, Prefix 인덱스는 꽤 다양하게 사용될 수 있는데요. 게시글 본문 내용을 색인하는 경우 이커머스 플랫폼에서 상품 설명이 저장된 긴 내용을 색인하는 경우 로그 데이터나 사용자의 행동을 기록하는 텍스트 필드에서 색인하는 경우 그리고 다음 질문 주신 내용인 prefix index의 한계점도 일부 맞는 말입니다: Prefix 인덱스는 해당 prefix로 시작하는 모든 행을 먼저 찾은 다음, 실제 데이터를 검색하여 추가적인 필터링을 수행해야 합니다. 이렇게 두 단계를 거치지만 인덱스를 사용하지 않는 경우보다는 빠를거에요. 물론 인덱스 검색도 전체 데이터의 20~25%이상 조회하는거라면 풀스캔이 더 빠르긴 하겠죠. Prefix 인덱스는 ORDER BY 나 GROUP BY 절에서의 정렬이나 그룹화 작업에 효과적이지 않아요. 이건 인덱스가 전체 값을 포함하지 않기 때문에, MySQL이 결과의 정확한 순서를 보장할 수 없기 때문이에요. 커버링 인덱스는 쿼리가 필요로 하는 모든 데이터를 인덱스에서 직접 가져올 수 있을 때 사용되는데요. Prefix 인덱스는 필드의 일부만을 포함하므로, 쿼리가 해당 필드의 전체 데이터를 필요로 하는 경우 추가적인 디스크 접근이 필요하기 때문에 사용할 수 없어요.
- 0
- 1
- 130