미국 주식 시장에는 세 가지 거래 시간대가 있습니다. 전시장, 장중, 장후입니다. 인터페이스 데이터 푸시는 값의 증분 로직(가능한 한 대역폭을 절약)이며, 처음 보내는 때는 전체 데이터를 보내고, 두 번째부터 모든 필드는 증분 방식으로 푸시됩니다.
최적의 방안을 사용하지 않는 이유는 무엇인가요? 여러 프로젝트 팀이 관련되어 있고, 일부는 이미 수년 전에 배포되었습니다. 저희 쪽은 새로 연결하는 입장이므로 최대한 호환성을 고려할 수밖에 없습니다.
일련의 문제
초록만 보더라도 별다른 문제가 없어 보일 수 있지만, 시스템 아키텍처가 문제 그룹으로 들어오면서 일련의 문제가 발생했습니다. 막 지난 문제를 해결하려 했더니 또 다른 문제가 생겼고, 이 문제는 이전 문제로 인해 발생한 것입니다.
거래 기간을 식별할 수 없습니다
알려진 바에 따르면, 디스크 내 단계 정의는 protobuf에서 0으로 정의되어 있지만, 데이터를 수신할 때 증분 푸시로 인해 비즈니스 측면에서는 이 0이 기본값인지 실제 비즈니스 값인지 효과적으로 식별하기 어렵습니다
일반적인 이해로, 0을 받을 때마다 이 0이 새로운 시세 설정 값인지, 아니면 프로토콜 버퍼의 기본값인지 판단하기 어렵습니다
선택적 도입
Since protobuf release 3.15, proto3 supports using the optional keyword (just as in proto2) to give a scalar field presence information
조 내 통신 프로토콜은 protobuf 기반이지만, 역사적인 이유로 비교적 오래된 버전이 선택되었고 optional 키워드를 지원하지 않습니다. 아시는 분들은 이해하실 텐데, 하위부터 protobuf를 도입하기 시작했고 프로젝트가 정적 라이브러리 방식으로 배포되어 전체 컴파일 링크를 업그레이드해야 하는데, 이 비용은 매우 높습니다.
GCC 버전 문제
정말 어렵게 대안을 마련했는데, 하위 레이어에서 두 가지 다른 버전을 배포하여 가능한 한 protobuf 새 버전의 컴파일 의존성 전파를 제어하려고 했습니다. 하지만 컴파일하는 과정에서 gcc 버전이 너무 낮아 protobuf의 새로운 기능을 지원하지 않는다는 것을 발견했습니다.
그룹 내에서 일반적으로 사용되는 서버 유형은 CentOS 7, CentOS 8입니다. CentOS 7의 기본 gcc 버전은 4.8이고, CentOS 8의 기본 gcc 버전은 8.3입니다. protobuf의 새로운 기능은 gcc 버전이 7.4 이상을 요구하므로 CentOS 7은 지원할 수 없습니다.
마지막으로 관련 서비스 배포 및 컴파일 서버를 CentOS 8로 옮겨서 이 문제를 해결했다
합리적인 열거
전체 문제를 되돌아보면, 사실 더 간단하고 효율적인 해결책이 있습니다. 바로 열거형의 정의를 조정하여 1부터 번호를 매기도록 하는 것입니다. 이렇게 하면 기본값과 비즈니스 값을 효과적으로 구별할 수 있으며, 위에서 언급한 일련의 문제들을 피할 수 있습니다.
왜 1부터 시작하는 것이 더 합리적일까요?
protobuf에서 열거형 유형의 기본값은 0으로 고정되어 있습니다. 의미 있는 비즈니스 값을 0으로 정의할 경우(예: “거래 중”), 증분 푸시 시 비즈니스 측에서 수신된 0이 비즈니스 값인지, 아니면 초기화되지 않은 기본값인지 판단하기 어렵습니다. 하지만 열거형을 1부터 시작하여 정의하면 0은 무의미한 기본값 또는 “알 수 없음” 상태로 유지할 수 있어 문제가 해결됩니다.
권장되는 방법:
프로토콜 버퍼 열거형을 설계할 때 항상 0을 무의미한 기본값(예: UNKNOWN 또는 RESERVED)으로 정의하십시오
실제 비즈니스 값을 1부터 할당하여 기본값 0과 구별되도록 합니다
이 작은 조정 덕분에 우리는 거래 시간대 식별 문제를 해결했을 뿐만 아니라 향후 프로토콜 설계에 귀중한 교훈을 얻게 되었습니다