루시와 프로그래밍 이야기

Object 명세 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시 테이블의 성능이 좋아진다. hashCode hashCode 재정의를 잘못했을 떄 크게 문제가 되는 조항은 두 번째다. 논리적으로 같은 객체는 같은 해시..

재정의하지 않는 경우 각 인스턴스가 본질적으로 고유하다. 클래스는 값 표현x 동작하는 개체를 표현 (ex. Thread) 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없다. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다. 위험 회피 스타일 / 실수로라도 호출되는 것이 싫다면 다음과 같이 구현하자 @Override public boolean equals(Object o){ throw new AsserionError(); //호출금지! } Q. 언제 equals를 재정의해야 할까? A. 논리적 동치성을 확인해야할 때, 상위 클래스의 equals가 논리적 ..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

아주 핵심적인 기본 원칙 : 명료성 / 단순성 컴포넌트는 사용자를 놀라게 하는 동작을 해서는 절대 안된다 정해진 동작이나 예측할 수 있는 동작만 수행해야한다 컴포넌트란? 모든 소프트웨어 요소를 뜻한다 코드는 복사되는 게 아니라 재사용되어야 한다 컴포넌트 사이의 의존성은 최소로 유지해야 한다 오류는 만들어지자마자 가능한 한 빨리 잡아야 한다 자바가 지원하는 타입 : 인터페이스, 클래스, 배열, 기본타입 (＊참조타입) annotation은 인터페이스의 일종이며, enum은 클래스의 일종이다 클래스의 인스턴스 & 배열 = 객체(Object) / 기본타입은 x 클래스의 멤버 = 필드, 메서드, 멤버 클래스, 멤버 인스턴스 메서드 시그니처 = 메서드 이름+입력 매게변수(parameter)의 타입 (※반환값의 타입..

13.1 주키퍼 없는 카프카의 미래 기존은 주키퍼에 대한 의존성이 높음 주키퍼는 매우 단순하고 안정적인 어플리케이션으로서 많은 분산 애플리케이션들의 코디네이터 역할을 함 13.1.1. 주키퍼 사용에 따른 제약사항 컨슈머의 오프셋 저장소 전환 카프카 2.0 이전 버전에서는 컨슈머 그룹의 저장소로 주키퍼의 지노드를 이용함 메시지수 증가/오프셋 증가/컨슈머 증가 -> 카프카 0.10버전부터 카프카의 내부 토픽인 _consum_offsets로 이전하면서 의존선 제거 각기 다른 애플리케이션 운영에 대한 부담 주키퍼와 카프카는 아파치에서도 완전히 별개의 프로젝트임 (추구하는 방향성도 다름) 각기 다른 API사용에 따른 부담 -> 개발생산성 저하로 이어짐 운영의 어려움 습득해야하는 지식이 2배 운영의 리소스가 2배 ..

운영중인 카프카 클러스터에 미치는 영향을 최소로 줄이면서 버전을 업그레이드하는 과정을 실습 업그레이드 순서와 주의사항 8.1 카프카 버전 업그레이드를 위한 준비 현재 사용하고 있는 카프카의 버전이 무엇인지 확인하기 명령어를 이용하는 방법 : /usr/local/kafka/bin/kafka-topics.sh —version -> 2.6.0 카프카가 설치된 경로에서 jar파일들을 확인하는 방법 : 실습환경에서는 /usr/local/kafka 가 위치이므로 -> ls -l /usr/local/kafka/libs/kafka_* 차이점 파악 : 업그레이드 하려는 버전을 정하고 카프카의 릴리스 노트 등을 살펴보면서 버전 업그레이드 시 문제가 될 만한 부분은 없는지 확인 카프카 상위 버전은 클라이언트들의 하위 호환성..

4.4 정리 카프카에서 메세지의 신뢰성을 보장하는데 중요한 리플리케이션의 개념 리플리케이션 동작을 위한 리더와 팔로워의 구분 및 역할 그리고 장애 복구를 위한 동작들 카프카 클러스터 내에서 리더 선출 작업을 책임지고 있는 컨트롤러 4.1 카프카 리플리케이션 카프카는 초기 설계 단계에서부터 일시적인 하드웨어 이슈 등으로 브로커 한두 대에서 장애가 발생하더라도 중앙 데이터 허브로서 안정적인 서비스가 운영될 수 있도록 구상됐습니다. 이때 안정성을 확보하기 위해 카프카 내부에서는 리플리케이션이라는 동작을 하게 됩니다. 4.1.1 리플리케이션 동작 개요 카프카의 리플리케이션 동작을 위해 토픽 생성시, 필수값으로 replication factor라는 옵션을 설정해야 합니다. kafka-topics.sh --boot..