교착상태 발생 조건 상호 배제 - 하나의 자원은 하나의 프로세스에 의해서만 사용된다. 점유와 대기 - 하나의 자원을 점유한 상태로 추가 자원 요청 비선점 - 점유된 자원에 대해 경쟁할 수 없다. 환형 대기 - 자원의 점유와 대기가 원형을 구성한 상태 해결 방법 예방 - 상호 배제를 제외한 나머지 발생 조건을 부정하는 방법 * 점유 자원 해제 후 새 자원 요청 * 이미 점유된 자원 경쟁 가능 * 원형 구성이 안되도록 하나의 프로세스 요청을 먼저 다 처리하기 회피 - 데드락이 발생하지 않도록 어떻게든 알고리즘을 잘 짜라 (예방보다 덜 엄격한 제한) * 은행가 알고리즘 발견, 복구 - 알고리즘으로 교착 상태를 감지하고 해결한다. * 자원할당 그래프 (발견) * 프로세스 kill (복구) - 프로세스를 순차적으..

Stack Memory 함수의 호출과 관계되는 지역 변수와 매개변수가 저장되는 영역이다. 함수가 호출되면 호출이 끝난 뒤 돌아갈 반환 주소값, 함수의 매개변수, 함수에서 선언된 지역 변수 등이 스택에 저장되고 호출이 완료되면 소멸한다. stack memory의 모든 과정은 컴파일 타임에 미리 결정된다. 즉, 개발자가 코드를 작성하지 않는다. stack은 독립적인 스레드에서 실행된다. stack은 heap보다 할당/해제가 빠르다. why => 스택은 미리 예약된 메모리이기 때문에 메모리 할당이 따로 필요없으며, 사용한 메모리를 굳이 반납하지 않고 (= 삭제 작업을 거치지 않고) 단순히 스택 포인터를 감소시킴으로써 스택 공간을 제한시킨다. 스택 포인터를 감소시키면서 남아있던 데이터는 스택 포인터가 다시 증가..

TCP/UDP Socket Protocol 흐름 Socket Interface 를 통해 TCP, UDP 통신 프로토콜을 사용할 수 있다. Socket Interface 는 특정 OS 및 프로그램 언어에 종속돼서 제공된다. TCP Socket Programming 흐름 서버는 Socket을 생성하고 주소를 할당(Bind)한다. 그 후 연결 요청을 기다리고(Listen) 연결을 허용(Accept)한다. 연결은 유지되며 통신하다가 로직에 따라 연결을 해제한다. UDP Socket Programming 흐름 TCP와 다르게 Listen(), Accept() 가 없다. UDP는 연결된 채로 sendto() 를 실행하지 않기에 하나의 sendto()에 하나의 recvfrom()이 호출된다. 예시로 Server의 r..

시작 현재 메신저 서비스를 보면 다른 테이블에서 Message 테이블을 참조할 일은 딱히 보이지 않는다. Message를 FK로 사용할 일이 없다면 관계형보단 일반적으로 I/O가 빠른 Nosql을 사용해도 되지않을까? MongoDB를 알아보자. Document는 JSON {} 형태로 구성된다. Field는 Column처럼 고정되지 않고 자유로운 key : value 형태이다. value는 boolean, array([ ]), null, nested한 document({ }) 등이 가능하다. Document { _id: ObjectId('64f9eb1cdb80f40007827e02'), text: '안녕하세요', 'boolean': true, array: [ 1, 2, 3, 4 ], empty: null ..

Inner Join 교차 부분만 추출한다. ( NULL이 없다. ) Outer Join Left Outer Join - 왼쪽 테이블 기준으로 추출한다. JOIN 조건과 무관하게 왼쪽 데이터가 모두 보이는 결과이다. - JOIN 조건(on)에 맞지 않은 부분은 NULL 로 구성된다. Right Outer Join - 오른쪽 테이블 기준으로 추출한다. JOIN 조건과 무관하게 오른쪽 데이터가 모두 보이는 결과이다. - JOIN 조건(on)에 맞지 않은 부분은 NULL 로 구성된다. Full Outer Join - 양쪽의 모든 데이터를 추출한다. JOIN 조건과 무관하게 양쪽 데이터가 모두 보이는 결과이다. - 데이터 조합을 추출하는건 아니다. ( JOIN 조건이 있다. ) - JOIN 조건(on)에 맞지 않..

HTTP GET/POST 차이 이 질문에 대한 대답은 "언제 어떤 메서드를 사용한다." 가 주대답이고 GET/POST 동작의 차이가 부가적인 대답같다. 언제 어떤 메서드를? 우리는 보통 API를 설계할 때 서버의 상태를 변화시키지 않고 정보를 조회하는 성격의 요청은 GET을 사용하고 서버의 상태를 변화시키는 요청이라면 POST, DELETE, PUT, PATCH 등 적절한 메서드를 사용한다. 동작 차이 GET query string을 통해 데이터를 전송하고 길이에 제한이 있고 URL에 노출된다. 브라우저 히스토리에 기록이 남고 서버 설정에 따라 캐싱이 가능하다. (캐싱이 가능하려면 당연히 브라우저 어딘가 기록이 있을 것이다.) POST body를 통해 데이터를 전송하고 데이터 크기에 제한은 없다. URL..

Factory Method Product 객체를 직접 생성하지 않고 Factory 클래스에서 Product를 만든다. 여러 Product 구현체가 있고 그 Product 를 만드는 Factory 구현체가 있다. 각각의 Factory 구현체가 그에 해당하는 Product 객체 생성의 책임을 가지고 있다. 객체 생성에 필요한 과정과 메서드를 템플릿 처럼 구성해놓고 과정과 메서드의 내부 동작은 Product 구현체와 Factory 구현체에서 유연하게 만들 수 있다. 장점 생성자와 구현 객체의 강한 결합을 피할 수 있다. 팩토리 메서드를 통해 객체 생성 후 공통으로 할 일을 수행하도록 지정할 수 있다. 캡슐화, 추상화를 통해 생성되는 객체의 구체적인 타입을 감출 수 있다. SRP(Single Responsibi..

카프카 producer key CompletableFuture future = kafkaTemplate.send(MSG_TOPIC, key, msg.getMsg()); future.whenComplete((result, ex) -> { System.out.println("future : " + result.getProducerRecord().value()); }); producer에 key가 있을 수도 있고 없을 수도 있다. 있다면 그 key로 해시값을 만들어 동일한 key라면 동일한 partition에 메세지를 전송할 수 있고 없으면 메세지를 라운드로빈으로 적절히 파티션들에 분산시키는 듯 하다. Consumer partition @Bean public NewTopic messageTopic() { re..

KRaft 모드 카프카에 대해 조사를 해보면 카프카의 메타 데이터, 브로커 상태, 토픽 상태 등을 관리하기 위해 주키퍼를 사용하는 것을 볼 수 있다. 그런데 docker kafka 이미지들을 보면 zookeeper 없이 구성된 docker-compose를 볼 수 있는데 카프카의 최근 버전에서는 주키퍼 없이 카프카를 사용할 수 있는 구조를 지향한다고 한다. 그래서 주키퍼없이 자체적으로 메타데이터를 관리하기 위해 만들어진 것이 KRaft 모드이고 QUORUM 컨트롤러는 KRaft 와 관련된 키워드이다. bitnami/kafka services: kafka: image: bitnami/kafka:latest ports: - '9092:9092' environment: # KRaft settings - KAFK..