웹 서비스의 개선 사항 을 기록 합 니 다.

우선,환경,간단 한 웹 서비스,관건 적 인 로 그 를 kafka 에 기록 하고 qps 가 단기 10k 에 도달 하도록 요구 하면 됩 니 다.
뒤에 발생 할 문제,해결 방안 과 원 리 는 다음 과 같다.
1.메모리 사용량 이 너무 많 습 니 다.jvm 의 메모리 사용량 은 1G 이지 만 프로 세 스 의 실제 메모리 사용량 은 12G 에 달 합 니 다.
     솔 루 션:프로그램 에서 kafka,new 에서 kafka producer 를 사용 하여 kafka 에 로 그 를 쓰 고 kafka 매개 변 수 를 조정 하여 해결 하 며 batch.size 와 partition 을 확대 하 였 습 니 다.
     원리:원인 은 batch.size 와 partition 설정 이 너무 작 아서 보 낼 패 킷 이 너무 많아 서 producer 의 기계 에 막 혔 습 니 다.그리고 kafka producer 는 zero copy 기술 을 사용 하여 대량의 커 널 메모리 를 사용 하여 방출 할 수 없 게 되 었 습 니 다.커 널 메모리 도 쌓 인 메모리 가 아니 라 사용자 가 제어 하지 않 기 때문에 프로 세 스 가 메모리 를 너무 많이 차지 하 는 상황 이 발생 했 습 니 다.kafka 버 전 은 0.8.2.2 입 니 다.(사실 여기 에는 한 가지 의문 이 존재 합 니 다.인터넷 에서 kafka 통신 을 할 때 zerocopy 를 사 용 했 습 니 다.그러나 제 가 실제 코드 를 따라 갈 때 producer 는 ByteBuffer.allocate 를 사 용 했 습 니 다.즉,메모리 더 미 를 사 용 했 습 니 다.ByteBuffer.allocateDirect 를 호출 하지 않 고 비 메모리 더 미 를 만 들 었 습 니 다.인터넷 에서 말 한 것 과 충돌 합 니 다.이 문제 의 원 리 를 아 는 친구 가 있다 면 가르쳐 주세요)
2.장시간 부하 가 높 은 상황 에서 프로그램의 성능 이 현저히 떨 어 지고 GC 상황 을 살 펴 보면 full gc 가 빈번히 진행 되 는 것 을 발견 할 수 있 습 니 다.
       해결 방안:jmap 사용 을 통 해 -dump 는 메모리 에 있 는 대상 정 보 를 파일 로 내 보 냅 니 다.jhat 명령 으로 분석 한 결과 kafka callback 대상 이 너무 많은 것 으로 나 타 났 습 니 다.이 Callback 대상 은 내용 이 긴 문자열 형식의 개인 변 수 를 포함 하여 문자열 이 많은 메모 리 를 차지 하 게 되 었 습 니 다.kafka 의 producer 는 캐 시 시스템 이 있어 서 Callback 대상 이 메모 리 를 차지 하여 방출 할 수 없습니다.나중에 Callback 의 개인 변 수 를 삭제 하고 Callback 을 하나의 예 로 바 꾸 어 메모리 사용량 을 줄 였 습 니 다.
 
3.다 중 스 레 드 데이터 손실
 해결 방안:실시 간 요구 가 있 기 때문에 막 을 수 없고 대기 행렬 의 길이 와 서브 스 레 드 의 수량 을 늘 리 는 방식 으로 만 가능 합 니 다. 
     원리:주 스 레 드 가 하위 스 레 드 에 임 무 를 할당 할 때 BlockingQueue 를 스스로 관리 하지 않 고 운영 체제 에서 스스로 관리 하고 하위 스 레 드 에 임 무 를 할당 할 때 Callable 대상 을 직접 배정 합 니 다.

//      
ExecutorService pool = newThreadPoolExecutor(threadPoolSize, threadPoolSize, 0L, TimeUnit.MILLISECONDS,
          newLinkedBlockingQueue<>(queueCapacity));
//         
pool.submit(() ->producer.send(new ProducerRecord<>(topic, null, record), kafkaCallback));

submit 방법 은 BlockingQueue 의 offer 방법 을 호출 하여 추가 합 니 다.대기 열 이 가득 차 면 차단 이 아 닌 false 로 되 돌아 갑 니 다.또한 Rejected Execution Exception(Runtime Exception 의 하위 클래스)을 던 져 이상 과 데 이 터 를 잃 어 버 립 니 다.
차단 방식 을 고려 하면 BlockingQueue 를 제어 하 는 것 으로 변경 할 수 있 습 니 다.차단 방식 을 사용 하지 않 으 려 면 quueCapacity 와 threadPoolSize 를 늘 릴 수 있 습 니 다.
 
4.로그 사용 log4j 기록 과 쓰기 kafka 성능 차이 가 너무 크 고 쓰기 로그 파일 은 3000 qps 에 달 하 며 kafka 를 쓰 면 11Kqps 에 달 할 수 있 습 니 다.
     솔 루 션:log4j 2.x 를 사용 하거나 kafka 를 사용 합 니 다.
      원리:log4j 의 코드 를 따라 들 어가 서 log4j 1.x 에서 sychronized 코드 를 많이 사용 한 것 을 발견 하여 log4j 다 중 스 레 드 에서 성능 문제 가 심각 하고 log4j 2.x 로 바 꾸 면 qps 를 10K 로 향상 시 킬 수 있 습 니 다.