1C: Enterprise: Java, PostgreSQL, Hazelcast를 위한 고부하 확장 가능 서비스를 작성하는 방법과 이유

이 글에서는 우리가 개발한 방법과 이유에 대해 이야기하겠습니다. 상호작용 시스템 – 클라이언트 응용 프로그램과 1C:Enterprise 서버 간에 정보를 전송하는 메커니즘 - 작업 설정부터 아키텍처 및 구현 세부 사항을 통한 사고까지.

상호 작용 시스템(이하 SV)은 전달이 보장되는 분산된 내결함성 메시징 시스템입니다. SV는 온라인 서비스(1C에서 제공)와 자체 서버 시설에 배포할 수 있는 대량 생산 제품으로 모두 사용할 수 있는 높은 확장성을 갖춘 고부하 서비스로 설계되었습니다.

SV는 분산 스토리지를 사용합니다. 헤이젤 캐스트 및 검색 엔진 탄성 검색. 또한 Java와 PostgreSQL을 수평적으로 확장하는 방법에 대해서도 이야기하겠습니다.

문제 성명

상호 작용 시스템을 만든 이유를 명확히하기 위해 1C에서 비즈니스 애플리케이션 개발이 어떻게 작동하는지 조금 설명하겠습니다.

우선, 우리가 하는 일을 아직 모르는 분들을 위해 우리에 대해 조금 소개하겠습니다. :) 우리는 1C:Enterprise 기술 플랫폼을 만들고 있습니다. 플랫폼에는 비즈니스 애플리케이션 개발 도구는 물론 비즈니스 애플리케이션을 크로스 플랫폼 환경에서 실행할 수 있는 런타임도 포함되어 있습니다.

클라이언트-서버 개발 패러다임

1C:Enterprise에서 생성된 비즈니스 애플리케이션은 XNUMX단계로 작동합니다. 클라이언트 서버 아키텍처 “DBMS – 애플리케이션 서버 – 클라이언트”. 다음으로 작성된 애플리케이션 코드 내장 1C 언어, 애플리케이션 서버 또는 클라이언트에서 실행될 수 있습니다. 애플리케이션 개체(디렉터리, 문서 등)에 대한 모든 작업과 데이터베이스 읽기 및 쓰기는 서버에서만 수행됩니다. 양식 및 명령 인터페이스의 기능도 서버에서 구현됩니다. 클라이언트는 양식 수신, 열기 및 표시, 사용자와의 "통신"(경고, 질문 등), 빠른 응답이 필요한 양식의 간단한 계산(예: 가격에 수량 곱하기), 로컬 파일 작업 등을 수행합니다. 장비 작업.

애플리케이션 코드에서 프로시저와 함수의 헤더는 &AtClient / &AtServer 지시문(영어 버전의 언어에서는 &AtClient / &AtServer)을 사용하여 코드가 실행될 위치를 명시적으로 나타내야 합니다. 1C 개발자는 이제 지시문이 실제로 ~ 이상, 그러나 우리에게는 이것이 지금 중요하지 않습니다.

클라이언트 코드에서 서버 코드를 호출할 수 있지만 서버 코드에서 클라이언트 코드를 호출할 수는 없습니다. 이는 여러 가지 이유로 인해 우리가 만든 근본적인 제한 사항입니다. 특히, 서버 코드는 클라이언트에서든 서버에서든 호출되는 위치에 관계없이 동일한 방식으로 실행되도록 작성되어야 하기 때문입니다. 그리고 다른 서버 코드에서 서버 코드를 호출하는 경우에는 그러한 클라이언트가 없습니다. 그리고 서버 코드를 실행하는 동안 이를 호출한 클라이언트가 닫히고 응용 프로그램이 종료될 수 있으며 서버는 더 이상 호출할 사람이 없게 됩니다.

버튼 클릭을 처리하는 코드: 클라이언트에서 서버 프로시저를 호출하면 작동하지만 서버에서 클라이언트 프로시저를 호출하면 작동하지 않습니다.

이는 예를 들어 "장기 실행" 보고서 생성이 완료되어 보고서를 볼 수 있다는 메시지를 서버에서 클라이언트 애플리케이션으로 보내려는 경우 그러한 방법이 없다는 것을 의미합니다. 예를 들어 클라이언트 코드에서 서버를 주기적으로 폴링하는 등의 트릭을 사용해야 합니다. 그러나 이 접근 방식은 불필요한 호출로 시스템을 로드하므로 일반적으로 그다지 우아해 보이지 않습니다.

그리고 예를 들어 전화가 왔을 때에도 필요합니다. SIP- 전화를 걸 때 발신자 번호를 사용하여 상대방 데이터베이스에서 이를 찾아 발신 상대방에 대한 사용자 정보를 표시할 수 있도록 이를 클라이언트 애플리케이션에 알립니다. 또는 예를 들어 주문한 상품이 창고에 도착하면 이에 대해 고객의 클라이언트 애플리케이션에 알립니다. 일반적으로 이러한 메커니즘이 유용한 경우가 많습니다.

생산 그 자체

메시징 메커니즘을 만듭니다. 빠르고 안정적이며 전달이 보장되고 메시지를 유연하게 검색할 수 있습니다. 메커니즘을 기반으로 1C 애플리케이션 내부에서 실행되는 메신저(메시지, 화상 통화)를 구현합니다.

수평 확장이 가능하도록 시스템을 설계합니다. 증가하는 부하는 노드 수를 늘려서 처리해야 합니다.

Реализация

우리는 SV의 서버 부분을 1C:Enterprise 플랫폼에 직접 통합하지 않고 1C 애플리케이션 솔루션의 코드에서 API를 호출할 수 있는 별도의 제품으로 구현하기로 결정했습니다. 이는 여러 가지 이유로 수행되었으며, 그 중 가장 큰 이유는 서로 다른 1C 응용 프로그램 간에(예: 무역 관리와 회계 간) 메시지를 교환할 수 있도록 하고 싶었기 때문입니다. 다양한 1C 응용 프로그램은 1C:Enterprise 플랫폼의 다양한 버전에서 실행될 수 있으며 다른 서버 등에 위치할 수 있습니다. 이러한 조건에서는 1C 설치의 "측면"에 위치한 별도의 제품으로 SV를 구현하는 것이 최적의 솔루션입니다.

그래서 우리는 SV를 별도의 제품으로 만들기로 결정했습니다. 소규모 기업에서는 서버 로컬 설치 및 구성과 관련된 오버헤드 비용을 피하기 위해 당사 클라우드(wss://1cdialog.com)에 설치한 CB 서버를 사용하는 것이 좋습니다. 대규모 고객은 시설에 자체 CB 서버를 설치하는 것이 좋습니다. 우리는 클라우드 SaaS 제품에서도 유사한 접근 방식을 사용했습니다. 1c신선한 – 양산형 제품으로 생산되어 고객사 현장에 설치되며, 당사 클라우드에도 배포됩니다. https://1cfresh.com/.

신청

로드 및 내결함성을 분산하기 위해 하나의 Java 애플리케이션이 아닌 로드 밸런서를 앞에 두고 여러 애플리케이션을 배포합니다. 노드에서 노드로 메시지를 전송해야 하는 경우 Hazelcast에서 게시/구독을 사용하세요.

클라이언트와 서버 간의 통신은 웹소켓을 통해 이루어집니다. 실시간 시스템에 매우 적합합니다.

분산 캐시

우리는 Redis, Hazelcast 및 Ehcache 중에서 선택했습니다. 2015년이에요. Redis는 방금 새 클러스터를 출시했습니다(너무 새롭고 무섭습니다). Sentinel에는 많은 제한이 있습니다. Ehcache는 클러스터로 조립하는 방법을 모릅니다(이 기능은 나중에 나타납니다). 우리는 Hazelcast 3.4를 사용해 보기로 결정했습니다.
Hazelcast는 상자에서 꺼내어 클러스터로 조립됩니다. 단일 노드 모드에서는 그다지 유용하지 않으며 캐시로만 사용할 수 있습니다. 데이터를 디스크에 덤프하는 방법을 모르므로 유일한 노드를 잃으면 데이터도 잃게 됩니다. 우리는 중요한 데이터를 백업하는 여러 Hazelcast를 배포합니다. 우리는 캐시를 백업하지 않습니다. 신경쓰지 않습니다.

우리에게 헤이즐캐스트는 다음과 같습니다.

• 사용자 세션 저장. 매번 세션에 대한 데이터베이스로 이동하는 데 시간이 오래 걸리기 때문에 모든 세션을 Hazelcast에 넣었습니다.
• 은닉처. 사용자 프로필을 찾고 있다면 캐시를 확인하세요. 새 메시지를 작성했습니다. 캐시에 넣으세요.
• 애플리케이션 인스턴스 간 통신을 위한 주제입니다. 노드는 이벤트를 생성하고 이를 Hazelcast 주제에 배치합니다. 이 주제를 구독하는 다른 애플리케이션 노드는 이벤트를 수신하고 처리합니다.
• 클러스터 잠금. 예를 들어 고유 키를 사용하여 토론을 만듭니다(1C 데이터베이스 내의 싱글톤 토론).

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

채널이 없는 것을 확인했습니다. 우리는 자물쇠를 가져와서 다시 확인하고 만들었습니다. 잠금을 획득한 후 잠금을 확인하지 않으면 그 순간 다른 스레드도 확인하여 동일한 토론을 만들려고 시도할 가능성이 있지만 이미 존재합니다. 동기화 또는 일반 Java 잠금을 사용하여 잠글 수 없습니다. 데이터베이스를 통해 - 속도가 느리고 데이터베이스가 안타깝지만, 헤이즐캐스트를 통해 - 그것이 바로 당신에게 필요한 것입니다.

DBMS 선택

우리는 PostgreSQL을 사용하고 이 DBMS 개발자와 협력한 광범위하고 성공적인 경험을 가지고 있습니다.

PostgreSQL 클러스터로는 쉽지 않습니다. XL, XC, 시투스, 그러나 일반적으로 이는 기본적으로 확장되는 NoSQL이 아닙니다. 우리는 NoSQL을 메인 스토리지로 생각하지 않고 이전에 작업하지 않았던 헤이즐캐스트를 사용하는 것으로 충분했습니다.

관계형 데이터베이스를 확장해야 한다면 이는 샤딩. 아시다시피 샤딩을 통해 데이터베이스를 별도의 부분으로 나누어 각 부분을 별도의 서버에 배치할 수 있습니다.

샤딩의 첫 번째 버전에서는 애플리케이션의 각 테이블을 다양한 비율로 여러 서버에 배포하는 기능을 가정했습니다. 서버 A에 많은 메시지가 있습니다. 이 테이블의 일부를 서버 B로 이동하겠습니다. 이 결정은 단순히 조기 최적화에 대한 비명을 지르는 것이므로 우리는 다중 테넌트 접근 방식으로 제한하기로 결정했습니다.

예를 들어 웹사이트에서 다중 테넌트에 대해 읽을 수 있습니다. 씨투스 데이터.

SV는 애플리케이션과 구독자의 개념을 가지고 있습니다. 애플리케이션은 사용자 및 비즈니스 데이터가 포함된 ERP 또는 회계와 같은 비즈니스 애플리케이션의 특정 설치입니다. 가입자는 자신을 대신하여 애플리케이션이 SV 서버에 등록된 조직 또는 개인입니다. 구독자는 여러 개의 애플리케이션을 등록할 수 있으며 이러한 애플리케이션은 서로 메시지를 교환할 수 있습니다. 구독자는 우리 시스템의 테넌트가 되었습니다. 여러 가입자의 메시지는 하나의 물리적 데이터베이스에 위치할 수 있습니다. 가입자가 많은 트래픽을 생성하기 시작한 것을 확인하면 이를 별도의 물리적 데이터베이스(또는 별도의 데이터베이스 서버)로 이동합니다.

우리는 모든 가입자 데이터베이스의 위치에 대한 정보와 함께 라우팅 테이블이 저장되는 기본 데이터베이스를 가지고 있습니다.

기본 데이터베이스의 병목 현상을 방지하기 위해 라우팅 테이블(및 기타 자주 필요한 데이터)을 캐시에 보관합니다.

구독자의 데이터베이스 속도가 느려지기 시작하면 이를 내부 파티션으로 잘라냅니다. 우리가 사용하는 다른 프로젝트에서는 pg_pathman.

사용자 메시지를 잃는 것은 좋지 않기 때문에 우리는 복제본을 사용하여 데이터베이스를 유지 관리합니다. 동기식 및 비동기식 복제본을 결합하면 기본 데이터베이스가 손실된 경우에도 안전을 확보할 수 있습니다. 메시지 손실은 기본 데이터베이스와 해당 동기 복제본이 동시에 실패하는 경우에만 발생합니다.

동기 복제본이 손실되면 비동기 복제본은 동기 복제본이 됩니다.
주 데이터베이스가 손실되면 동기 복제본은 주 데이터베이스가 되고, 비동기 복제본은 동기 복제본이 됩니다.

검색을 위한 Elasticsearch

무엇보다도 SV는 메신저이기도 하므로 부정확한 일치를 사용하여 형태를 고려한 빠르고 편리하며 유연한 검색이 필요합니다. 우리는 바퀴를 재발명하지 않고 라이브러리를 기반으로 만들어진 무료 검색 엔진 Elasticsearch를 사용하기로 결정했습니다. 루센. 또한 Elasticsearch를 클러스터(마스터 – 데이터 – 데이터)에 배포하여 애플리케이션 노드에 장애가 발생할 경우 문제를 제거합니다.

github에서 우리는 찾았습니다 러시아어 형태학 플러그인 Elasticsearch용으로 사용하세요. Elasticsearch 인덱스에는 단어 어근(플러그인이 결정함)과 N-그램을 저장합니다. 사용자가 검색할 텍스트를 입력하면 N-gram 중에서 입력된 텍스트를 찾습니다. 인덱스에 저장되면 "texts"라는 단어가 다음 N-gram으로 분할됩니다.

[그들, tek, tex, text, texts, ek, ex, ext, texts, ks, kst, ksty, st, sty, you],

그리고 "text"라는 단어의 어근도 보존됩니다. 이 접근 방식을 사용하면 단어의 시작, 중간, 끝에서 검색할 수 있습니다.

큰 그림

기사 시작 부분부터 그림을 반복하되 설명을 추가합니다.

• 인터넷에 노출된 밸런서; 우리는 nginx를 가지고 있으며 무엇이든 될 수 있습니다.
• Java 애플리케이션 인스턴스는 Hazelcast를 통해 서로 통신합니다.
• 우리가 사용하는 웹 소켓으로 작업하려면 그물코.
• Java 애플리케이션은 Java 8로 작성되었으며 번들로 구성됩니다. OSGi. 계획에는 Java 10으로의 마이그레이션과 모듈로의 전환이 포함됩니다.

개발 및 테스트

SV를 개발하고 테스트하는 과정에서 우리는 우리가 사용하는 제품의 여러 가지 흥미로운 기능을 발견했습니다.

로드 테스트 및 메모리 누수

각 SV 릴리스에는 로드 테스트가 포함됩니다. 다음과 같은 경우에 성공합니다.

• 테스트는 며칠 동안 진행되었으며 서비스 장애는 없었습니다.
• 주요 작업에 대한 응답 시간이 편안한 임계값을 초과하지 않았습니다.
• 이전 버전 대비 성능 저하가 10%를 넘지 않습니다.

우리는 테스트 데이터베이스를 데이터로 채웁니다. 이를 위해 프로덕션 서버에서 가장 활동적인 구독자에 대한 정보를 수신하고 그 숫자에 5(메시지 수, 토론 수, 사용자 수)를 곱하고 그런 식으로 테스트합니다.

우리는 세 가지 구성으로 상호 작용 시스템의 로드 테스트를 수행합니다.

1. 스트레스 테스트
2. 연결만
3. 가입자 등록

스트레스 테스트 중에 우리는 수백 개의 스레드를 시작하고 메시지 작성, 토론 생성, 메시지 목록 수신 등을 멈추지 않고 시스템을 로드합니다. 일반 사용자의 작업(읽지 않은 메시지 목록 가져오기, 다른 사람에게 쓰기) 및 소프트웨어 솔루션(다른 구성의 패키지 전송, 경고 처리)을 시뮬레이션합니다.

예를 들어 스트레스 테스트의 일부는 다음과 같습니다.

• 사용자 로그인
  • 읽지 않은 토론을 요청합니다
  • 메시지를 읽을 가능성이 50%
  • 문자를 보낼 가능성이 50%
  • 다음 사용자:
    • 새로운 토론을 만들 확률은 20%입니다.
    • 임의의 토론을 무작위로 선택합니다.
    • 안으로 들어간다
    • 메시지, 사용자 프로필 요청
    • 이 토론에서 무작위 사용자에게 전달되는 XNUMX개의 메시지를 생성합니다.
    • 토론을 떠난다
    • 20회 반복
    • 로그아웃하고 스크립트 처음으로 돌아갑니다.

  • 챗봇이 시스템에 진입합니다(애플리케이션 코드의 메시징을 에뮬레이션).
    • 데이터 교환을 위한 새로운 채널을 만들 확률이 50%입니다(특별 토론).
    • 50%는 기존 채널에 메시지를 쓸 가능성이 높습니다.

"연결 전용" 시나리오가 나타난 데에는 이유가 있습니다. 상황이 있습니다. 사용자가 시스템에 연결했지만 아직 참여하지 않았습니다. 각 사용자는 아침 09시에 컴퓨터를 켜고 서버에 연결한 후 침묵을 유지합니다. 이 사람들은 위험합니다. 그들 중 다수가 있습니다. 그들이 가지고 있는 유일한 패키지는 PING/PONG이지만 서버에 대한 연결을 유지합니다(그들은 연결을 유지할 수 없습니다. 새 메시지가 있으면 어떻게 됩니까?). 이 테스트는 00분 만에 다수의 사용자가 시스템에 로그인을 시도하는 상황을 재현합니다. 스트레스 테스트와 유사하지만 초점은 정확히 이 첫 번째 입력에 맞춰져 있으므로 실패가 없습니다(사람이 시스템을 사용하지 않고 이미 떨어졌기 때문에 더 나쁜 것을 생각하기 어렵습니다).

구독자 등록 스크립트는 첫 번째 실행부터 시작됩니다. 스트레스 테스트를 실시한 결과 통신 중에 시스템이 느려지지 않는지 확인했습니다. 그런데 사용자들이 왔고 시간 초과로 인해 등록이 실패하기 시작했습니다. 등록할 때 우리가 사용한 / dev / random, 이는 시스템의 엔트로피와 관련이 있습니다. 서버는 충분한 엔트로피를 축적할 시간이 없었고 새로운 SecureRandom이 요청되면 수십 초 동안 정지되었습니다. 이 상황에서 벗어날 수 있는 방법은 여러 가지가 있습니다. 예를 들어 덜 안전한 /dev/urandom으로 전환하고, 엔트로피를 생성하는 특수 보드를 설치하고, 미리 난수를 생성하여 풀에 저장합니다. 풀 관련 문제는 일시적으로 해결되었으나, 이후 신규 가입자 등록을 위해 별도의 테스트를 진행하고 있습니다.

우리는 부하 생성기로 사용합니다. JMeter를. 웹소켓으로 작업하는 방법을 모르므로 플러그인이 필요합니다. "jmeter websocket" 쿼리에 대한 첫 번째 검색 결과는 다음과 같습니다. BlazeMeter의 기사, 추천하는 것 Maciej Zaleski의 플러그인.

그것이 우리가 시작하기로 결정한 곳입니다.

진지한 테스트를 시작한 직후에 우리는 JMeter에서 메모리 누수가 시작된다는 사실을 발견했습니다.

플러그인은 별도의 큰 이야기로, 별 176개와 github에 132개의 포크가 있습니다. 저자 자신은 2015년 이후로 이를 약속하지 않았습니다(우리는 2015년에 이를 받아들였지만 의심을 일으키지 않았습니다), 메모리 누수와 관련된 여러 github 문제, 닫히지 않은 끌어오기 요청 7개.
이 플러그인을 사용하여 부하 테스트를 수행하기로 결정한 경우 다음 토론에 주의하십시오.

1. 멀티스레드 환경에서는 일반 LinkedList를 사용하였고 그 결과는 다음과 같았습니다. NPE 런타임에. 이 문제는 ConcurrentLinkedDeque로 전환하거나 동기화된 블록을 통해 해결할 수 있습니다. 우리는 스스로 첫 번째 옵션을 선택했습니다.https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. 메모리 누수, 연결 해제 시 연결 정보가 삭제되지 않음(https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. 스트리밍 모드(샘플 종료 시 websocket이 닫히지 않았지만 나중에 계획에서 사용되는 경우)에서는 응답 패턴이 작동하지 않습니다(https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

이것은 github에 있는 것 중 하나입니다. 우리가 한 일:

1. 가져옴 포크 엘리란 코간 (@elyrank) – 문제 1과 3을 수정합니다.
2. 해결된 문제 2
3. 부두를 9.2.14에서 9.3.12로 업데이트했습니다.
4. ThreadLocal에서 SimpleDateFormat을 래핑했습니다. SimpleDateFormat은 스레드로부터 안전하지 않아 런타임 시 NPE가 발생합니다.
5. 또 다른 메모리 누수 수정(연결이 끊어졌을 때 연결이 잘못 닫혔음)

그럼에도 불구하고 그것은 흐른다!

하루가 아니라 이틀 만에 기억력이 떨어지기 시작했습니다. 남은 시간이 전혀 없었기 때문에 더 적은 수의 스레드를 실행하기로 결정했지만 에이전트는 XNUMX개였습니다. 이 정도면 적어도 일주일은 충분했을 것입니다.

이틀이 지났다..

이제 Hazelcast의 메모리가 부족해졌습니다. 로그에 따르면 며칠 간의 테스트 후 Hazelcast가 메모리 부족에 대해 불평하기 시작했고 얼마 후 클러스터가 무너지고 노드가 계속해서 하나씩 죽었습니다. JVisualVM을 hazelcast에 연결하고 "rising saw"를 보았습니다. 이는 정기적으로 GC를 호출했지만 메모리를 지울 수 없었습니다.

Hazelcast 3.4에서는 map/multiMap(map.destroy())을 삭제할 때 메모리가 완전히 해제되지 않는 것으로 나타났습니다.

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

현재는 3.5에서 버그가 수정됐지만 당시에는 문제가 됐다. 우리는 동적 이름을 가진 새로운 multiMap을 생성하고 논리에 따라 삭제했습니다. 코드는 다음과 같습니다.

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

보기:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

multiMap은 각 구독마다 생성되었으며 필요하지 않을 때 삭제되었습니다. 우리는 Map을 시작하기로 결정했습니다. , 키는 구독 이름이 되고 값은 세션 식별자가 됩니다(필요한 경우 사용자 식별자를 얻을 수 있음).

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

차트가 좋아졌습니다.

부하 테스트에 대해 또 무엇을 배웠습니까?

1. JSR223은 Groovy로 작성되어야 하며 컴파일 캐시를 포함해야 합니다. 훨씬 빠릅니다. 링크.
2. Jmeter-Plugins 그래프는 표준 그래프보다 이해하기 쉽습니다. 링크.

Hazelcast에 대한 우리의 경험에 대해

Hazelcast는 우리에게 새로운 제품이었습니다. 우리는 버전 3.4.1부터 작업을 시작했으며 현재 프로덕션 서버에서는 버전 3.9.2를 실행하고 있습니다(이 글을 쓰는 시점에서 Hazelcast의 최신 버전은 3.10입니다).

ID 생성

우리는 정수 식별자로 시작했습니다. 새로운 엔터티를 위해 또 다른 Long이 필요하다고 상상해 봅시다. 데이터베이스의 순서가 적합하지 않고 테이블이 샤딩과 관련되어 있습니다. DB1에 메시지 ID=1이 있고 DB1에 메시지 ID=2이 있는 것으로 나타났습니다. 이 ID를 Elasticsearch나 Hazelcast에 넣을 수 없습니다. , 그러나 최악의 상황은 두 데이터베이스의 데이터를 하나로 결합하려는 경우입니다(예를 들어 이러한 구독자에게 하나의 데이터베이스로 충분하다고 결정하는 경우). 여러 개의 AtomicLong을 Hazelcast에 추가하고 거기에 카운터를 유지할 수 있습니다. 그런 다음 새 ID를 얻는 성능은 incrementAndGet에 Hazelcast에 대한 요청 시간을 더한 것입니다. 그러나 Hazelcast에는 FlakeIdGenerator라는 더 최적의 기능이 있습니다. 각 클라이언트에 접속할 때 ID 범위가 제공됩니다(예: 첫 번째는 1~10, 두 번째는 000~10 등). 이제 클라이언트는 발급된 범위가 끝날 때까지 자체적으로 새 식별자를 발급할 수 있습니다. 빠르게 작동하지만 애플리케이션(및 Hazelcast 클라이언트)을 다시 시작하면 새로운 시퀀스가 ​​시작됩니다. 따라서 건너뛰는 등이 발생합니다. 또한 개발자는 ID가 정수인 이유를 실제로 이해하지 못하지만 일관성이 없습니다. 우리는 모든 것을 평가하고 UUID로 전환했습니다.

그건 그렇고, Twitter처럼 되고 싶은 사람들을 위해 Snowcast 라이브러리가 있습니다. 이것은 Hazelcast 위에 Snowflake를 구현한 것입니다. 여기서 볼 수 있습니다:

github.com/noctarius/snowcast
github.com/twitter/snowflake

하지만 우리는 더 이상 그것에 대해 다루지 않았습니다.

TransactionalMap.replace

또 다른 놀라움: TransactionalMap.replace가 작동하지 않습니다. 테스트는 다음과 같습니다.

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

getForUpdate를 사용하여 직접 대체 항목을 작성해야 했습니다.

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

일반 데이터 구조뿐만 아니라 트랜잭션 버전도 테스트합니다. IMap이 작동하지만 TransactionalMap이 더 이상 존재하지 않는 경우가 있습니다.

가동 중지 시간 없이 새 JAR 삽입

먼저 우리는 수업의 객체를 Hazelcast에 기록하기로 결정했습니다. 예를 들어, Application 클래스가 있는데 이를 저장하고 읽으려고 합니다. 구하다:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

읽기 :

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

모든 것이 작동하고 있습니다. 그런 다음 Hazelcast에 색인을 구축하여 다음을 검색하기로 결정했습니다.

map.addIndex("subscriberId", false);

그리고 새 엔터티를 작성할 때 ClassNotFoundException을 받기 시작했습니다. Hazelcast는 색인에 추가하려고 시도했지만 우리 클래스에 대해 아무것도 몰랐고 이 클래스가 포함된 JAR이 제공되기를 원했습니다. 우리는 그렇게 했고 모든 것이 제대로 작동했지만 새로운 문제가 나타났습니다. 클러스터를 완전히 중지하지 않고 JAR을 업데이트하는 방법은 무엇입니까? Hazelcast는 노드별 업데이트 중에 새 JAR을 선택하지 않습니다. 이 시점에서 우리는 색인 검색 없이도 살 수 있다고 결정했습니다. 결국, Hazelcast를 키-값 저장소로 사용하면 모든 것이 작동할까요? 설마. 여기서도 IMap과 TransactionalMap의 동작이 다릅니다. IMap이 신경 쓰지 않는 경우 TransactionalMap에서 오류가 발생합니다.

아이맵. 우리는 5000개의 객체를 쓰고 읽습니다. 모든 것이 예상됩니다.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

하지만 트랜잭션에서는 작동하지 않으며 ClassNotFoundException이 발생합니다.

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8에서는 사용자 클래스 배포 메커니즘이 나타났습니다. 하나의 마스터 노드를 지정하고 해당 노드의 JAR 파일을 업데이트할 수 있습니다.

이제 접근 방식을 완전히 바꾸었습니다. 직접 JSON으로 직렬화하고 Hazelcast에 저장합니다. Hazelcast는 클래스의 구조를 알 필요가 없으며 다운타임 없이 업데이트할 수 있습니다. 도메인 객체의 버전 관리는 애플리케이션에 의해 제어됩니다. 서로 다른 버전의 애플리케이션이 동시에 실행될 수 있으며 새 애플리케이션이 새 필드가 포함된 개체를 작성하지만 이전 애플리케이션이 아직 이러한 필드를 알지 못하는 상황이 발생할 수 있습니다. 동시에 새 응용 프로그램은 새 필드가 없는 이전 응용 프로그램에서 작성한 개체를 읽습니다. 이러한 상황은 애플리케이션 내에서 처리하지만 단순성을 위해 필드를 변경하거나 삭제하지 않고 새 필드를 추가하여 클래스를 확장하기만 합니다.

고성능을 보장하는 방법

Hazelcast로 XNUMX번의 여행 - 좋음, 데이터베이스로 XNUMX번 - 나쁨

데이터를 캐시로 이동하는 것이 데이터베이스로 이동하는 것보다 항상 낫지만, 사용하지 않는 레코드도 저장하고 싶지 않습니다. 우리는 무엇을 캐시할지에 대한 결정을 개발 마지막 단계까지 맡깁니다. 새로운 기능이 코딩되면 PostgreSQL의 모든 쿼리에 대한 로깅을 활성화하고(log_min_duration_statement를 0으로 설정하고 20분 동안 로드 테스트를 실행합니다. 수집된 로그를 사용하여 pgFouine 및 pgBadger와 같은 유틸리티는 분석 보고서를 작성할 수 있습니다. 보고서에서는 주로 느리고 빈번한 쿼리를 찾습니다. 느린 쿼리의 경우 실행 계획(EXPLAIN)을 작성하고 해당 쿼리를 가속화할 수 있는지 평가합니다. 동일한 입력 데이터에 대한 빈번한 요청은 캐시에 적합합니다. 우리는 쿼리당 하나의 테이블을 "플랫"으로 유지하려고 노력합니다.

착취

SV는 온라인 서비스로 2017년 봄부터 운영에 들어갔고, 별도의 상품으로 SV는 2017년 XNUMX월(당시 베타 버전 상태) 출시됐다.

XNUMX년이 넘는 운영 기간 동안 CB 온라인 서비스 운영에 심각한 문제는 발생하지 않았습니다. 우리는 다음을 통해 온라인 서비스를 모니터링합니다. 자 비츠, 다음에서 수집 및 배포 대나무.

SV 서버 배포판은 RPM, DEB, MSI와 같은 기본 패키지 형태로 제공됩니다. 또한 Windows의 경우 서버, Hazelcast 및 Elasticsearch를 하나의 컴퓨터에 설치하는 단일 EXE 형태의 단일 설치 프로그램을 제공합니다. 처음에는 이 설치 버전을 "데모" 버전이라고 불렀지만 이제 이것이 가장 널리 사용되는 배포 옵션이라는 것이 분명해졌습니다.

출처 : habr.com