본문 바로가기

ALL

 (128)
2-4) 인스턴스화를 막으려거든 private 생성자를 사용하라 인스턴스화를 막는 이유 정적 필드와 정적 메소드만으로 구성된 클래스를 만드는 경우가 있다. 예를 들어 java.util.Arrays의 배열을 위한 상수를 정적 필드로 가지고 있고, 배열관련 메소드를 정적 메소드로 가지고 있다. 이러한 성격의 클래스는 인스턴스화를 막는게 일반적이다. 인스턴스를 만든다는 것은 객체마다 다른 속성값을 가지고 있을 때 의미가 있다. 정적 필드와 메소드로만 구성된 클래스는 객체를 만드는것이 의미가 없다. 심지어 메모리상 낭비를 가져온다. 따라서 정적인 방식으로 만들어진 클래스는 인스턴스화를 막는것이 옳다. private 생성자 public class Arrays { ... private Arrays() {} ... } 정적 방식으로 만들어진 java.util.Arrays 클래스는..
2-3) private 생성자나 열거 타입(enum)으로 싱글톤을 보장하라 싱글톤 패턴 MyClass myClass1 = ... MyClass myClass2 = ... // true System.out.println(myClass1 == myClass2); 싱글톤 패턴은 클래스가 오로지 하나의 인스턴스를 만들 수 있도록 하는 패턴이다. 무상태 객체나 필요에 의해 시스템에 하나의 객체만 존재해야하는 경우 싱글톤 패턴을 사용한다. 싱글톤 패턴을 구현하는 방식은 크게 3가지가 존재한다. public static final 필드 방식의 싱글톤 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { } public void leaveTheBuilding() { System.out.p..
2-2) 생성자에 매개변수가 많다면 빌더를 고려하라 점층적 생성자 패턴 영양정보를 표현하는 클래스가 있다. 이 클래스에는 필수항목인 "1회 제공량", "총 n회 제공량"과 선택항목인 "칼로리", "지방", "나트륨", "탄수화물" 이 필드로 존재한다. 이 클래스의 생성자는 6개의 매개변수가 필요하고 필수항목만 입력하고 싶어도 6개의 매개변수를 모두 보내주어야 한다. 이러한 비효율적인 상황을 해결하기 위해 점층적 생성자 패턴을 사용할 수 있다. public class NutritionFacts { private final int servingSize; private final int servings; private final int calories; private final int fat; private final int sodium; private fin..
2-1) 생성자 대신 정적 팩토리 메소드를 고려하라. 생성자(new) 대신 정적 팩토리 메소드 (Static Factory Method) 생성자(new)는 JAVA의 가장 기본적인 문법이고 클래스의 인스턴스를 만들 때 일반적으로 생성자를 사용한다. 하지만 개발자는 클래스에 별도의 정적 팩토리 메소드 (Static Factory Method)를 제공할 수 있다. 클래스의 인스턴스를 반환하는 정적 팩토리 메소드를 제공하면 생성자 대신 사용할 수 있다. public class MyClass { // 생성자를 통한 인스턴스 생성 public MyClass() {} // 정적 팩토리 메소드를 통한 인스턴스 생성 public static MyClass getInstance() { return new MyClass(); } } 간단한 예제 코드를 보면, MyClass는..
12장 - 엔터프라이즈 카프카 아키텍처 구성 사례 엔터프라이즈 카프카 아키텍처 개요 엔터프라이즈 환경에서는 장애/복구, 성능 등을 위해 하나 이상의 데이터 센터를 사용하는 경우가 많다. 따라서 각 데이터 센터마다 카프카 클러스터를 배치해야 하고, 각 카프카 클러스터 간의 데이터 리플리케이션은 필수이다. 카프카 클러스터 안에서의 브로커 간의 리플리케이션이 아니라, 카프카 클러스터 간의 리플리케이션이다. 카프카 리플리케이션은 업스트림 카프카에서 다운스트림 카프카 사이에 필요할 수도 있고, 여러 카프카 데이터를 모으기 위해 필요할 수도 있다. 이렇게 복제된 미러 카프카는 최적의 위치에서 엘라스틱 서치, HBase 등에 연결되어 사용될 수 있다. 지금까지 배운 내용을 종합해서 위와 같은 엔터프라이즈 아키텍처를 만들고자 한다. 2개의 카프카 클러스터가 존재하고,..
1. SOLID - 객체 지향의 다섯가지 원칙 Design Smells Design Smells은 나쁜 설계의 증상들을 말하며 그 내용은 아래와 같다. 증상 내용 경직성 시스템 변경이 어렵다. 하나를 바꾸려고 할 때마다, 다른 것들도 끝없이 바꾸어야 한다. 취약성 한 부분의 수정이 다른 많은 부분들, 연관이 없는 부분에 까지 영향을 준다. 부동성 시스템을 재사용하기 위한 요소로 분리하기 어렵다. 점착성 시스템 설계나 개발환경에 맞추기 위해 실제 개발이 어려워진다. 불필요한 복잡성 당장 필요하지 않은 많은 코드다 들어가 있다. 불필요한 반복 같은 코드가 중복되어 쓰이고 있다. 불투명성 쉽게 의도를 알기 어려운 코드가 존재한다. SOLID SOLID는 객체 지향의 5가지 원칙으로 그 내용은 아래와 같다. Single-Responsibility Princ..
5장 - 프로듀서의 내부동작 원리와 구현 파티셔너 카프카는 토픽마다 병렬처리를 위한 파티션을 가지고 있고, 이에따라 각 메시지가 어느 파티션에 들어가야 하는지 결정하는 로직이 필요하다. 이때 사용하는 것이 바로 파티셔너이다. 카프카는 별도의 파티셔너를 정의하지 않으면 기본적으로 라운드 로빈 알고리즘을 사용하는 파티셔너를 사용했었다. 그러나 2019년 부터는 이를 개량한 스티키 파티셔닝 알고리즘을 사용한다. 라운드 로빈 알고리즘은 메시지를 각 파티션에 순서대로 하나씩 넣는다. 이렇게 하면 각 파티션에 동일한 수의 메시지가 들어가게 되고, 자연스럽게 각 파티션을 가져가는 컨슈머도 동일한 부하를 가지도록 한다. 하지만 카프카의 기본 특징인 메시지의 배치 전송 때문에 라운드 로빈 전략은 약점이 존재한다. 위 이미지처럼 batch.size가 3으로 설정..
3장 - 카프카 기본 개념과 구조 카프카의 주요 구성 요소 주키퍼(Zookeeper): 카프카의 메타데이터를 관리 하고 브로커의 상태를 점검하는 어플리케이션 카프카(Kafka): 프로듀서와 컨슈머 사이에서 메시지를 중개하는 메시지 브로커 어플리케이션 브로커(Broker): 카프카가 설치되고 동작하는 서버 또는 노드 프로듀서(Producer): 카프카로 메시지를 보내는 클라이언트 컨슈머(Consumer): 카프카에서 메시지를 가져가는 클라이언트 토픽(Topic): 카프카 메시지를 구분하는 카테고리. 카프카 내에서 고유하다. 파티션(Partition): 병렬 처리를 위해 토픽을 나눈 것 세그먼트(Segment): 메시지가 저장된 브로커의 디스크 파일 메시지(Message) 또는 레코드(Record): 프로듀서가 전송하고 컨슈머가 가져가는 데..

티스토리툴바