KR20110000737A - 다수의 처리 명령어를 실시간으로 취급하고 처리하는 것과 관련된 개선 - Google Patents

Abstract

프로세싱 세션 동안에 실시간으로 매우 높은 수의 명렁어(instructions)를 처리 및 취급하는 시스템(150)이 제공된다. 상기 각 처리 지시는 두 개의 다른 당사자들(14,16)에 관련되는 리소스 어카운트 데이터 파일(30)과 이 파일(30) 사이에 교환되어야 하는 리소스의 양(quantity) 및 타입(type)을 지정한다. 상기 시스템(150)은 리소스 어카운트 데이터 파일 각각의 현재 값을 가리키는 명령어와 관계되는 참조 데이터를 획득하는 프리로더(152)와, 각 프리로드돈 참조 데이터와 함께 복수 개의 처리 명령어를 큐잉하기 위한 인리치 명령어 큐(166)와, 수신된 참조 데이터를 이용하여, 각각의 수신된 명령어가 관련 시소스 계정 파일의 현재 값 하에서 실행될 수 있는지, 각각의 실행 가능한 명령어가 업데이팅 커맨드를 생성할 수 있는지를 순차적으로 결정하도록 구성된 실행 엔진(154)과, 실행 엔진(154)으로부터 업데이팅 커맨드에 응답하여, 각 실행 가능한 명령어의 결과로 마스터 베이스(24)를 업데이트하는 업데이터(158)를 포함한다.

Description

다수의 처리 명령어를 실시간으로 취급하고 처리하는 것과 관련된 개선{IMPROVEMENTS RELATING TO HANDLING AND PROCESSING OF MASSIVE NUMBERS OF PROCESSING INSTRUCTIONS IN REAL TIME}

본 발명은 매우 많은 수의 처리 명령어(processing instructions)을 실시간으로 취급하고 처리하는 것과 관련된 개선에 관한 것이다. 보다 구체적으로, 본 발명은 초당 수백 개의 명령어의 처리를 최적화하도록 설계된 컴퓨터 처리 아키텍처(computer processing architecture)에 관한 것이지만, 이에 제한되는 것은 아니다.

매우 많은 수의 처리 명령어를 실시간으로 취급(핸들링)하고 처리하는 문제를 다루는 것과 관련하여 다양한 접근법이 있다. 이들 모든 접근법은 광대한 수의 명령어를 취급하는 데에 있어서 성공적이었으며, 이러한 많은 성공은 좀 더 빠르고 좀 더 강력한 컴퓨팅을 채용하는 시스템으로 인한 것이었다. 그러나, 이러한 접근법의 근저에 있는 아키텍처는 이러한 시스템의 최대 가능한 처리량(throughput)의 상한을 제한하는 이런저런 방식으로 제한되었다.

예컨대, 대용량 데이터 통신 시스템 및 데이터 처리 시스템과 같이, 이러한 기술의 다양한 응용 분야가 있다. 이러한 기술이 어떻게 사용될 수 있는지 보여주는 비제한적인 예를 나타내는 한 가지 데이터 처리 시스템은 트랜잭션 결제 시스템(transaction settlement system)으로서, 상기 시스템에서는 상이한 당사자들 사이의 계약(agreements)을 나타내는 데이터 명령어 메시지가 실행되어 상기 계약의 실제 결제 또는 실행을 이루어낼 수 있다. 이러한 구성에서, 그 한 가지 예를 이하에서 상세하게 설명하는데, 신뢰성 있는 결제자 컴퓨터(trusted settlement entity computer)에의 명령어(또는 커맨드)는, 상기 결제자 컴퓨터(규칙)에 의해 정해진 조건이 그 명령어의 실행을 허용한다면 동작될 수 있다. 따라서, 그러한 프로세스의 제1 부분으로서, 결제 계약의 주체인 리소스에 대한 전자 데이터 계정 파일(account file)의 현재 상태에 대한 체크가 이루어져야 한다. 이러한 체크를 통해, 상기 전자 데이터 계정 파일 상에서 명령어를 실행하는 효과가 받아들여질 수 있는지 여부가 결정된다.

상기 프로세스의 제2 부분에서, 상기 명령어는 실행 승인되거나("commit"라 지칭된다) 또는 실행 거부된다("rollback"이라 지칭된다). 보다 구체적으로, 이 비 제한적인 예에서, 두 당사자의 리소스 계정 파일들의 위치가 결제자(settlement entity) 컴퓨터에 의해 액세스되어, 상기 명령어가 전자 데이터 계정 파일 상의 수용불가능한 위치로 되는 일이 없이 실행될 수 있는지를 결정한다. 상기 조건들이 적절하다면, 데이터 레코드 내에 포함되어 있는 상기 명령어(command)가 실행되고, 이어서 상기 리소스 계정의 현재 위치를 저장하는 데이터 파일이 업데이트된다(commit). 상기 조건이 적절하지 않다면, 이 순간 적시에 상기 명령어의 실행 없이 상기 전자 데이터 계정 파일은 변하지 않은 채 남아 있다. 또한, 제1 스테이지가 상기 전자 데이터 계정 파일 상의 결과 위치가 수용 불가능하다고 나타낸다면, 모든 계정을 디폴트로서 업데이트할 수 있고, 그 업데이트를 리버스할 수 있다(rollback). 이는 높은 처리량(high-throughput)의 시스템에 대해 바람직한 옵션이다. 일단 상기 조건들이 실패한 명령어에 대해 변경되면, 롤백된(rolled back) 데이터 명령어는 리사이클될 수 있고(recycled) 관련된 커맨드는 이후의 스테이지에서 다시 시도될 수 있다. 이들 모두는 또한, 종종 실시간으로 계약 당사자의 컴퓨터로 통보되어야 한다.

제안된 솔루션의 확장성(scalability)을 지금까지 제한한 이러한 데이터 처리의 실행의 한 가지 특징은 명령어들을 실행하기 위해 액세스되어야 하는 여러 상이한 리소스의 수가 명령어의 수가 증가함에 따라 증가하지 않는다는 것이다. 이는 종종 명령어의 수가 증가함에 따라 어떤 수의 리소스 상에서 명령어 실행이 집중되기 때문이다. 이러한 집중은 문제가 되는데, 왜냐하면 리소스 계정 파일의 값에 영향을 미치는 각 명령어가, 그 계정이 처리될 수 있다는 것을 특정하는 다음 명령어 전에 상기 값을 업데이트해야 하기 때문이다. 통상적으로, 이는 처리하는 동안 또는 그 리소스 계정 파일의 값을 체크하고 업데이트하는 동안, 주어진 계정 파일의 일시적 배타성(locking)을 취하는 특정 명령어에 의해 달성된다. 다음 명령어가 처리될 수 있기 전의 이러한 업데이팅은, 상기 증가된 수의 명령어가 처리될 수 있는 최대 속도에 직접적인 영향을 미친다. 이는 많은 상이한 종류의 명령어에 공통적인 당사자 리소스에 대하여 심각한 문제이다. 특히, 50%의 명령어가 단지 5%의 리소스 계정만을 업데이트하는 경우에(이는 고집중 상태(high-concentration situation)인 것으로 고려된다), 이는 특히 심각한 문제이다.

이러한 비제한적인 예는 실행될 명령어에 대해 펀드가 이용 가능한지 여부를 알아보기 위하여 당사자에 대한 현금 계정을 저장하는 데이터 파일을 체크해야 하는 경우에 볼 수 있다. 각 명령어에 대한 리소스 계정의 체크는, 이전의 명령어가 그 명령어의 실행 결과로서 현금 계정 위치를 업데이트한 후에 실행되어야 한다. 따라서, 이들 처리는 순차적이어야 하며 또는 하나의 명령어의 실행 동작(이는 그 계정의 밸런스(balance)를 변화시킨다)은, 그 계정에의 액세스를 필요로 하는 임의의 후속 명령어를 무효시킬 수도 있다. 종래 아키텍처(후술)의 최대 처리 속도는 이러한 이슈에 의해 제한되었다.

동시 처리 아키텍처가 사용되는 종래의 시스템에서 발생하는 다른 문제는 '데드록(deadlock)'이다. 이 문제적 상황은 두 개의 동시 명령어(concurrent instruction)가 동일한 두 개의 계정을 액세스하여 하나의 명령어는 하나의 리소스 계정을 로킹하게 되고 다른 명령어는 제2 리소스 계정을 로킹하게 되는 경우에 일어난다. 이는 각각의 명령어가, 그 명령어 달성을 체크하기 위해 다른 계정에 액세스하는 것을 방지한다. 두 명령어는 대기 상태에 속박되는데, 이 대기 상태에서는 상기 명령어가 그 명령어를 처리하는 실행(commit) 동작을 수행하는 것을 방지한다. 한 명령어의 롤백이 다른 명령어의 처리를 해제하는 반면에, 이러한 솔루션은 명령어 처리의 처리량을 현저하게 감소시킨다는 것을 이해할 것이다.

전자 계정 파일을 체크하고 업데이트하는 기본적인 프로세스는 싱글 명령어에 대하여 비교적 사소한 것으로 보이는 반면에, 매일 수 백만 개의 이러한 명령어를 처리하는 것은 그 솔루션을 사소하지 않은 것으로 만든다. 결제자에 의해 채용되는 임의의 시스템의 목적은 실시간으로 가능한 가장 높은 처리량을 달성하는 것이다. 어떤 솔루션의 확장성은, 임의의 처리 단계의 시간을 조금 절약하게 되면 그러한 시간 절약은 대량의 명령어를 취급하는 데에 수 배 이상 증가하므로, 매우 중요하다.

이러한 결제 과정을 실시하기 위해 종래에 많은 시스템이 개발되었으며, 이러한 시스템의 전형적인 예를 도 1 내지 도 5(도 5a, 도 5b)를 참조하여 설명한다.

도 1을 참조하면, 종래의 일반적인 중앙 리소스 관리 시스템(10)이 도시되어 있는데, 이 시스템은 수 백만 개의 명령어 데이터 메시지를 매일 다루도록 구성되어 있다. 상기 시스템(10)은 여러 통신 채널(12)에 접속되어 있는데, 상기 통신 채널은 전용 통신 회선(dedicated leased communication line)일 수 있고 또는 다른 종류의 보안 통신 채널(secure communciation channel)일 수도 있다. 이들 채널을 통해, 상기 시스템(10)은 여러 상이한 당사자 서버에 접속되어 있다. 이 예에서, 그리고 설명을 용이하게 하기 위해, 상기 시스템(10)은 당사자 A의 서버(14) 및 당사자 B의 서버(16)에 접속되어 있다. 당사자 A의 서버(14) 및 당사자 B의 서버(16)는 각각 레코드의 데이터베이스(18, 20)에 액세스하는데, 각 레코드는 다른 당사자와의 계약을 기술하고 있다.

상기 중앙 리소스 관리 시스템(10)은 통상 명령어 실행 서버(22)를 포함하는데, 이 서버는 마스터 리소스 데이터베이스(24)에 액세스하며, 상기 데이터베이스는 모든 당사자(즉 이 예에서는 A 및 B)의 리소스 계정을 나타내는 데이터 레코드를 포함한다.

도 2를 참조하면, 각 당사자에 대한 마스터 리소스 데이터베이스의 구조의 개략도가 제시되어 있다. 데이터베이스(24)는 각 당사자에 대한 복수 개의 상이한 종류의 리소스 계정 파일(30)과, 그 당자자에 대한 집합 리소스 값(aggregated resource value)의 표시자(32)를 포함한다. 이 특정의 예에서, 명령어 데이터 메시지는 각각 이들 계정 파일(30) 상의 커맨드 또는 명령어를 이행하도록 되어 있으며, 특히 어느 한 당자자의 계정을 다른 당사자의 계정으로 리소스를 전달하고 상기 집합 리소스 값 표시자(32)를 업데이트하도록 되어 있다. 상기 계정들은 당사자(14, 16)의 실제 리소스를 나타내는 데이터 파일(30)이다. 상기 리소스들은 어느 당사자의 임의의 리소스일 수 있다. 이 예에서, 상기 리소소는 당사자가 트레이드하고자 하는 것을 당사자가 갖고 있는 임의의 것을 나타낸다.

이제 도 3을 참조하면, 명령어 데이터 메시지(40)의 일반적 구조 또는 포맷이 도시되어 있다. 명령어 데이터 메시지(40)는 필수적으로, 명령어를 이행하는데 필요한 6개의 기본 필드를 갖고 있다. 명령어 데이터 메시지(40)는 당사자를 명령어에 식별시키기 위한 당사자 ID 필드(42)를 갖고 있다. 이 실시예에서, 명령어 데이터 메시지(40)는 당사자 A와 당사자 B를 식별할 수 있다. 실행 날짜 필드(44)는 명령어 데이터 메시지(40)가 실행되는 날짜를 규정하기 위하여 제공된다. 나머지 4개의 필드는 명령어의 주제인 리소스 세부 사항(resource details)을 식별한다. 제1 리소스 타입 필드(46)와 대응하는 제1 리소스 양 필드(48)는 제1 당사자(예컨대, 당사자 A)의 리소스와, 명령어에 포함되는 리소스의 양을 식별하기 위하여 제공된다. 제2 리소스 타입 필드(50)와 대응하는 제2 리소스 양 필드(52)는 제2 당자사(예컨대, 당사자 B)의 리소스와 명령어에 포함되는 리소스의 양을 식별하기 위하여 제공된다.

두 당자자 사이의 각각의 계약에 대하여, 두 가지 명령어 데이터 메시지(40)가 존재한다(각 당자자에 대해 한 개).

도 4는 도 1의 종래 명령어 실행 서버(22)의 구성 요소들을 보여준다. 이들 구성 요소는 수신된 명령어 데이터 메시지(40)의 유효성을 체크하도록 구성된 명령어 인증기(instruction validator)(60), 동일한 계약과 관련되어 있는 두 개의 상이한 명령어 데이터 메시지(40)를 함께 매치시키는 명령어 매처 모듈(instruction matcher module)(62)을 포함한다. 상기 명령어 매처는 또한 매치된 명령어 데이터 메시지들(40)에 대한 결제 명령어를 생성한다. 새로이 생성된 결제 명령어와 연관되어 있는 시간과 현재의 시간을 비교하기 위한 타이밍 모듈(64)도 제공된다. 또한, 타이밍 모듈(64)은 각 당사자의 리소스 계정 파일(30)에의 액세스를 위한 타이밍 윈도우가 현재 열려있는지 아니면 닫혀있는지를 판단할 수 있다. 향후의 실행을 위해 결제 명령어를 저장하기 위한 명령어 데이터베이스(66)도 제공된다. 명령어 실행 서버(22)는 정보 메시지를 관련 당사자에게 통신하기 위한 통보 모듈(reporting module)(68)을 더 포함한다. 마지막으로, 상기 명령어 실행 서버의 심장에는 명령어 체크 실행 및 업데이팅 엔진(instruction checking execution and updating engine)(70)이 제공된다. 통보 모듈(68)은 명령어 인증기(60), 명령어 매처(62) 및 명령어 체크 실행 및 업데이팅 엔진(70)과 접속되어 있다. 명령어가 처리되는 방식은 명령어 체크 실행 및 업데이팅 엔지(70)의 특정 데이터 처리 아키텍처에 의해 결정되고, 이는 (이하에서 설명하는 바와 같이) 여러 상이한 종래의 디바이스 사이에서 변한다.

명령어 실행 서버(22)가 동작하는 방식을 도 5(도 5a 및 도 5b)의 흐름도를 참조하여 설명한다. 포지셔닝 엔진(70)에서 명령어(결제 명령어)의 실행을 통해 명령어 데이터 메시지들(40)을 수신하고, 확인하며(validate), 매치시키는 단계 및 상기 업데이팅의 결과를 업데이트하고 통보하는 단계를 보다 자세히 설명한다. 구체적으로, 종래의 명령어 실행 서버(22)의 전체 동작(78)은 단계(80)에서 시작하는데, 상기 서버(22)는 통신 채널(12)에 접속되어 있고, 명령어 데이터 메시지들(40)의 수신을 잘 받아들인다. 당사자 A는 단계(82)에서 데이터 명령어 메시지(40)를 서버(22)에 전송하는데, 상기 메시지는 당사자 B와의 계약을 기술하고 있다. 유사하게, 당사자 B는 단계(84)에서 데이터 명령어 메시지(40)를 서버(22)에 보내는데, 상기 메시지는 당사자 A와의 계약을 기술하고 있다. 서버(22) 그 자체에서, 상기 메시지들(40)은 수신되고, 명령어 시험기(60)는 단계(86)에서, 수신된 각각의 명령어(40)를 유효하게 하려고 한다. 단계(88)에서 유효성 체크가 실패하면, 이는 단계(90)에서 통보 모듈(68)에 통신되고, 통보 메시지(도시 생략)가 단계(90)에서 유효하게 되지 않은 데이터 명령어 메시지(40)의 소스에 전송된다.

그렇지 않으면, 유효하게 된 명령어 데이터 메시지(40)에 대하여, 통보 모듈(68)은 단계(92)에서, 그 명령어 데이터 메시지(40)의 수신 및 유효성을 나타내는 포지티브 메시지를 상기 유효하게 된 명령어 메시지(40)의 소스에 전송하도록 지시받는다.

유효하게 된 명령어 메시지(40)는 명령어 매처(62)를 통과하게 되고, 단계(94)에서, 동일한 계약을 기술하고 있는 대응하는 명령어 데이터 메시지들(40)을 매치하는 시도가 이루어진다.

명령어 매처(62)는 단계(96)에서, 상이한 메시지들(40)을 함께 매치하려고 한다. 단계(96)에서의 매칭 체크가 실패하면, 이것은 단계(98)에서 통보 모듈(68)에 전해지고, 통보 메시지(도시 생략)가 단계(98)에서 상기 매치되지 않은 데이터 명령어 메시지(40)의 소스에 보내지며, 프로세스는 단계(100)에서 종료된다. 이러한 실패는 종래 기술의 시스템의 설명을 간단하게 하기 위해 꽤 간단하게 나타내었다. 그러나, 실제 상기 매치의 실패는 수 많은 시도 후에, 아마도 설정된 매칭 기간의 만료 후에(이는 며칠일 수 있다)만 도달되는 결론일 수 있다.

단계(96)에서 결정된, 매치된 명령어 메시지들(40)은 통보 모듈(68)에 통지되고, 이 모듈은 다시 단계(102)에서 매치된 쌍의 명령어 데이터 메시지들(40)의 존재를 그 매치된 데이터 명령어 메시지들(40)의 소스(이 경우 당사자 A 및 B)에 통보한다. 게다가, 상기 명령어 매처(62)는 단계(102)에서 실행 날짜를 갖고 있는 실행 명령어(결제 명령어)를 생성한다. 이 실행 날짜는 단계(104)에서, 매치된 명령어 데이터 메시지(40) 중 어느 하나(두 메시지는 동일하기 때문에)의 실행 날짜 필드로부터 얻어진다. 결제 명령어의 실행 날짜는 단계(104)에서, 실행 날짜 윈도우(타이밍 모듈(64)에 의해 정해진다)의 현재의 날짜 및 이용 가능성(availability)과 비교된다.

단계(106)에서 결정되는 상기 비교 결과가 상기 결제 명령어는 지금 실행 가능한 것이 아니라는 것이라면, 결제 명령어는 단계(108)에서 명령어 데이터베이스(66)에 저장된다. 데이터베이스(66)는 일정 간격으로 체크되고, 프로세스(78)는 단계(110)에서, 실행 날짜가 달성되고 실행 윈도우가 열릴 때까지 대기한다. 통상적으로, 실행 윈도우는 매일 몇 시간 동안 열려 있을 수 있다.

별법으로서, 단계(106)에서 결정된 비교의 결과가 결제 명령어가 이제 실행가능하다라는 것이라면, 결제 명령어는 저장되지 않는다.

명령어 실행 서버(22)의 전체 동작(78)의 다음 단계는 단계(112)에서, 결제 명령어를 상기 명령어 체크, 실행 및 업데이팅 엔진(70)(포지셔닝 엔진(positioning engine)이라고도 지칭한다)으로 전송하는 것이다. 포지셔닝 엔진(70)은 그것을 실행 규칙(72) 셋트와 연관시킨다. 이들 규칙(72)은 상기 결제 명령어가 실행될 수 있는지 여부를 판단한다. 즉 리소스 계정 파일(30) 및 집합 리소스 값(32)의 결제 명령어의 결과가 수용가능한 것인지 여부를 판단한다. 수용할 수 없는 조건의 한 가지 예는, 특정 리소스 계정 파일(30) 또는 집합 리소스 값(32)이, 커맨드를 실행한 결과로서, 미리 정해진 양보다 작은 값을 갖는 것이다. 상기 비제한적인 트랜잭션 결제 시스템 예에서, 리소스 계정은 현금 및 유가증권 계정(security account)일 수 있고, 집합 리소스 값(32)은 크레디트 라인(credit line)일 수 있는데, 이 라인에서, 제공된 크레디트에 대해 리소스가 담보 역할을 함에 따라, 리소스의 현재 값이 어떤 크기의 크레디트를 제공한다.

포지셔닝 엔진(70)은 단계(114)에서, 실행 규칙(72)이 커맨드가 실행된다면 여전히 만족되는지 여부, 즉 두 당사자의 리소스 계정 파일(30) 및 집합 리소스 값(32)에 미치는 결과적인 효과가 받아들여질 수 있는지를 판단한다.

단계(116)에서 판단되는 것과 같이, 실행 규칙이 만족되지 않는다면, 즉시불(prompt)이 단계(118)에서 통보 모듈(118)에 보내지고, 통보 모듈은 단계(118)에서 비성공적인 결과를 두 당사자에게 통보하는 메시지를 상기 실패한 결제 명령어, 예컨대 이 예에서는 당사자 A 및 B에게 보낸다. 후속하여, 상기 실패한 결제 명령어는 단계(120)에서 포지셔닝 엔진(70) 내에 남아 있고, 나중에 결제를 위해 재시도된다(단계 114 내지 126을 반복).

대체적으로, 실행 규칙(72)이 단계(116)에서 결정되는 것과 같이 만족된다면, 결제 명령어가 단계(122)에서 실행된다. 다음에, 포지셔닝 엔진(70)은 단계(124)에서, 실행된 결제 명령어의 결과로 리소스 계정 파일(30) 내의 현재 위치를 업데이트한다. 즉 리소스 계정 파일(30)과 집합 리소스 값(32)은, 리소스가 유효하게 전송된 후에 정확한 밸런스로 업데이트된다. 마지막으로, 통보 모듈(68)은 단계(128)에서, 두 당자자에게 결제의 성공정인 결과를 통보하는 메시지를 생성하여, 단계(126)에서 상기 성공적인 결제 명령어의 당사자, 예컨대 이 예에서는 당사자 A 및 B에게 보내도록 지시받는다.

결제 명령어의 성공적인 실행은 종래 명령어 실행 서버(22)의 전체 동작(78)을 싱글 명령어에 가깝게 한다. 그러나, 수 백만개의 명령어가 매일 처리됨에 따라, 프로세스(78)는 수 많은 다른 당사자의 서버로부터 계속 수신되는 다른 명령어 데이터 메시지(40)에 대해서 계속된다.

상기한 바와 같이, 결제 명령어가 처리되는 방식은 명령어 체킹 실행 및 업데이팅 엔진(70)의 특정 데이터 처리 아키텍처에 의해 결정되고, 이는 여러 상이한 종래 시스템에서 변한다. 본질적으로 두 가지 상이한 타입의 접근 방식이 있다. 즉 배치 프로세스(batch process)와 병렬 입력 매칭 프로세스(parallel input matching process)인데, 이 둘을 도 6 및 도 7을 참조하여 설명한다.

배치 프로세스는 표준의 순차적 업데이트 접근법으로서, 실행 명령어들은 순차 처리를 위해 저장되고, 자동으로 연속하여 실행된다. 이 프로세스(130)는 도 6에 개략적으로 도시되어 있는데, 새로운 명령어들(결제 명령어)의 배치(순차 셋트)를 담고 있는 신규 명령어들 파일(132)이 마스터 파일(134)과 함께 제공되며, 상기 마스터 파일은 모든 리소스 계정 파일(30)의 현재 위치 및 임의의 집합 위치(aggregated positions)(32)를 저장한다.

각 결제 명령어는 계약과 관련된 두 당사자, 리소스 계정 파일(30), 두 당자사 사이의 계약의 주제인 리소스의 양, 도 3에서 설명한 것과 같은 실행 시간/날짜를 식별한다. 이러한 종류의 처리 아키텍처의 주요 특징은, 이들 결제 명령어는 그 명령어가 관련된 리소스 계정(30)의 순서로 리스트되어야 한다는 것이다. 통상적으로, 시퀀스 키이(sequence key)에는 상호 참조(cross referencing)를 도와주는 각 명령어가 제공된다.

마스터 파일(134)은 상기 시퀀스 키이를 이용하여 리소스 데이터 계정(30)을 순서대로 리스팅한다. 마스터 파일과 입력 데이터 파일 사이의 이러한 순서 대응관계는 배치 처리에 있어서 매우 중요하다.

대응 명령어의 결제에 의해 각 계약이 실행될 수 있는가를 결정하기 위하여 순차 업데이트 프로그램(sequential update program)(136)이 제공된다. 프로세싱 엔진(도시 생략) 상에서 실행된 순차 업데이트 프로그램(136)은 매칭 알고리듬(matching algorithm)이라고 부르는 표준 알고리듬을 이용한다. 상기한 바와 같이, 상기 매칭 알고리듬은 두 입력 파일(기존의 마스터 위치 파일(134) 및 신규 명령어 파일(136))들이 시퀀스 키이의 순서대로 저장되는 것을 필요로 한다. 명령어 파일(132)에 사용되는 키이는 "트랜잭션" 키이라고 부르고, 기존의 마스터 파일(134)에 저장된 키이는 "마스터" 키이라고 부른다.

순차 업데이트 프로그램(136)은, 두 파일(132, 134)의 끝까지, 두 파일(132, 134)을 순서대로 읽는 로직을 규정한다. 상기 순차 업데이트 프로그램의 결과는 신규 마스터 파일(138)에 저장되는데, 이 파일은 당사자의 모든 리소스 계정 파일(30) 및 집합 위치(32)의 업데이트된 위치를 유지한다.

순차 업데이트 프로그램(136)은 각 파일(132, 134)의 첫 번째 명령어 또는 레코드를 읽음으로써 시작한다. 주어진 리소스 계정 파일(30)과 관련된 모든 명령어는 순차적으로 실행되는데, 리소스 계정 파일(30)의 값의 변화는 매칭 알고리듬을 구동하는 프로세싱 엔진의 메모리에 업데이트된다. 특정 리소스 계정 파일(30)에 대한 업데이트가 완료되면(다음 명령어에 대한 트랜잭션 키이의 변화에 의해 감지된다), 그 리소스 계정 파일(30)에 대한 결과 값이 업데이트된 집합 위치(32)와 함께 신규 마스터 파일(138)에 기록된다. 이러한 프로세스는 트랜잭션 파일(132)의 끝에 도달할 때까지 각각의 리소스 계정 파일(30)에 대하여 반복된다.

명령어를 실행하기 위하여 복수의 리소스 계정을 업데이트하여야 하는 경우에, 보다 정교한 접근법이 이용된다. 복수의 계정의 업데이팅을 다루기 위하여, 업데이팅은 여러 스테이지로 나뉘어진다. 그 솔루션은 첫 번째 구동에서만 리소스 계정 값들의 데이트(debit)를 실행하고, 크레디트를 대응 리소스 계정에 적용하기 전에 리소스 계정의 크레디트의 순서로 데비트가 성공적인 명령어들을 보고하는 것이다. 리소스 계정의 크레디팅이 지연되기 때문에 실패한 명령어로 인한 문제가 있지만, 이는 복수 회의 구동을 수행함으로써 해결될 수 있다.

순차 업데이트 프로그램(136)은 통상, 다음의 경우를 다루는 로직을 규정한다.

Transaction key = Master key

=> 현재의 명령어를 리소스 계정 파일의 현재의 마스터 데이터 레코드에 적용한다

=> 현재의 리소스 계정의 신규 위치를 업데이트된 마스터 레코드로서 메모리 내에 저장한다

=> 다음 명령어를 읽는다

Transaction key > Master key

=> 업데이트된 데이터 레코드를 신규 마스터 파일(138)에 기록한다

=> (이용 가능하다면) 마스터 데이터 레코드를 복구하고 또는 다음 마스터 데이터 레코드에 대한 마스터 파일을 읽는다

Transaction key < Master key

=> 현재의 마스터 레코드를 저장한다

=> 디폴트 마스터 레코드를 생성한다

=> 명령어를 마스터 레코드에 적용한다

또는

=> 대응 마스터 파일 정보가 존재하지 않으므로, 즉 계정 리소스 파일(30)이 마스터 파일(134)에서 발견되지 않으므로, 명령어를 거절한다

=> 다음 명령어를 읽는다

상기의 것이 행해지면, 다음 명령어 레코드가 트랜잭션 파일(132)로부터 읽혀지고, 트랜잭션 키이가 현재의 마스터 키이보다 더 커질 때까지 동일한 프로세스가 다시 적용된다.

상기 알고리듬에서, 메모리 내의 싱글 프로세스가 복수의 업데이트를 신규의 마스터 파일(138)에 네팅하는데(nets), 이는 명령어들을 보다 빨리 처리하도록 해준다. 제한은, 프로세스(배치)를 구동하기 전에 모든 명령어를 그룹화하고 소팅하여야 한다는 것이다. 또한, 모든 명령어는 첫 번째 답신 메시지를 명령어의 실행을 확인하는 당자자에게 반송할 수 있기 전에, 처리되어야 한다. 게다가, 배치 프로세스에서, 데이터는 매칭 알고리듬을 구동하는 동안에 다른 프로세스에 대해서는 이용 가능하지 않다. 데이터에 실시간으로 액세스하기 위해, 데이터베이스 업데이트가 필요하다. 직접 행해진다면, 이들 데이터베이스 업데이트는 프로세스의 전체 처리량을 죽이게 될 것이다. 실행 후 (예컨대 DB2 로드 유틸리티) 여분의 단계에서 실행된다면, 그것은 유리하게도 그 시간 동안 데이터에의 모든 액세스를 차단한다. 이 결과는, 배치 처리가 실행되는 경우 매우 효율적이지만, 실행 전에 그룹화 및 소팅에 대한 요구 조건 때문에 실시간으로 실행될 수 없다는 것이다.

다른 선택적인 접근법, 즉 상기한 병렬 입력 매칭 접근법이 도 7에 도시되어 있다. 이러한 접근법 하에서, 명령어 매처(62)에 의해 생성된 결제 명령어는 복수의 개개 명령어 취급 컴퓨터 또는 프로세서(140, 142)에 의해 다루어진다. 또한, 시퀀스 파일 취급 프로세스(144)는 명령어 데이터베이스(66)에 저장되어 있는 명령어의 배치를 다룰 수 있다. 각 프로세스(140, 142, 144)는, 현재의 리소스 계정(30)의 값과 집합 리소스 값(32)을 읽을 수 있고 마스터 테이터베이스(24) 내의 당사자 리소스 계정 파일(30)에 대한 다이렉트 업데이트 명령어를 생성할 수 있는 다이렉트 업데이트 프로그램(146)의 자신의 버전을 갖고 있다. 프로세스(140, 142, 144)로부터 수신된 명령어들에 의해 데이터베이스(24)의 업데이트에 대한 최종 결정을 하기 위해 싱글 명령어 실행 매니저(148)가 제공된다. 상기 명령어 실행 매니저(148)는 실행 규칙(72)(도 4 참조)의 셋트를 이용하여, 실행을 위한 업데이트 명령어를 실행(commit)하거나 나중에 실행하기 위해 그것을 롤백(rollback)한다.

명령어 실행 매니저(148)가 실행해야 하는 실행 규칙(72) 중 하나는 록아웃(lockout)의 이슈를 다루고 있다. 상기한 바와 같이, 록아웃(lockout)은 리소스 계정 파일(30)에 대한 액세스는 다른 업데이트 명령어에 대해 사용되는 프로세스 중에 금지되는 것이다. 실제, 이것이 의미하는 것은 특정 리소스 계정(30)을 업데이트하기 위한 경쟁(contention)이, 리소스 계정 파일(30)이 이전의 업데이트 명령어로부터 릴리스될 때까지, 즉 이전의 업데이트가 완료될 때까지, 대기 상태를 삽입하여 다루어지는 것을 의미한다. 이러한 방식으로, 명령어 실행 매니저(148)는 두 개의 상이한 업데이트 명령어가 동일한 리소스 계정 파일(30)을 병렬식으로 수정하는 것을 방지한다.

각 프로세스(140, 142, 144)는 병렬 구동되고, 단일 프로세스보다 더 큰 대역폭을 제공하며, 이는 더 큰 잠재적인 처리량으로 이어져야 한다. 구체적으로, 대단히 많은 수의 상이한 리소스 계정 파일(30)에 걸쳐 업데이트가 분배되는 경우, 병렬 시스템은 확장 가능하다(scalable). 이러한 환경 하에서, 많은 업데이팅 프로세스(140, 142, 144)를 병렬로 구동함으로써, 시스템의 처리량을 증대시킬 수 있다. 그러나, 업데이트가 잘 분배되지 않으면, 데이터 일체성을 확보하는 록아웃(lockout) 프로세스가 실행되어, 재빨리 시스템이 도달할 수 있는 최대 처리량을 제한한다. 이 한계에 도달되면, 하나 이상의 업데이트 프로세스를 구동하여도 전체 처리량이 증가하지 않는데, 왜냐하면 이는 또한 이용 가능하지 않은(locked) 리소스 계정 파일(30)에 대한 다른 업데이트 명령어의 "대기 상태"를 증가시키기 때문이다.

이러한 접근법은 실시간 업데이트를 위해서는 훌륭하지만, 대부분의 조건 하에서 처리량이 떨어진다는 단점이 있다. 이는 보통 업데이트가 상당히 많은 수의 여러 리소스 파일(30)에 걸쳐 분배되지 않기 때문이다. 대신에, 많은 용례에 있어서, 어떤 리소스 계정이 많은 여러 명령어에 의해 과도하게 사용되는 것은 흔한 일이다. 예컨대, 트랜잭션 결제 분야에 있어서, 50%의 명령어가 5%의 이용 가능한 리소스 계정 파일(30) 상에 집중되는 것은 흔한 일이다. 이러한 환경 하에서, 도 7의 실시간 처리 기법은 성능이 떨어진다.

고려해야 하는 다른 이슈는 실패한 명령어를 리사이클링하는 것이다. 여기서, 리소스 계정이 실행 규칙을 충족시키는 데 필요한 값을 갖고 있지 않아서 특정 순간에 적시에 실행될 수 없는 명령어가 단순히 나중에 다른 시도된 실행을 위해 저장되어 있다. 각각의 일시적 실패는 명령 지시자(instructor)에게 보고될 수 있는데, 이는 리소스 계정 조건이 일단 변화면 명령어가 곧 실행될 수 있을 것이라는 것을 나타낸다. 여러 번 실패한 시도 또는 시간의 만료로 인하여, 상기 명령어가 최종적으로 실패한 것으로 보고될 수도 있다.

상기 종래의 리사이클링 프로세스는 실행 엔진에 제안되는 신규 명령어의 수를 감소시킬 때에 유용하다. 상기 명령어를 "펜딩 중(pending)"인 것으로 보유함으로써, 조건이 변화하는 경우 그것이 처리될 가능성은 더 커지게 된다. 처리될 명령어의 용량이 주어지면, 대부분의 리사이클된 명령어는 최종 실패한 것으로 보고되어야 하는 일 없이 실행될 가능성이 크다.

그러나, 이러한 리사이클링은, 리사이클링 프로세스에 의해 실행 엔진의 속도가 떨어진다는 점에서, 실행 엔진의 처리량에 문제를 야기한다. 특히, 병렬 입력이 있는 경우, 큰 리소스 계정 이동을 기술하는 명령어는 종종, 그 실행을 위한 조건이 리사이클링 기간 내에(타임 아웃이 일어나기 전에) 도달하지 않음에 따라, 실패하게 된다. 순차적 입력이 있는 경우, 상기 실패는 실패한 명령어를 다루는 데 필요로 하는 구동 수를 증가시킨다.

이러한 문제를 극복하고자 하는 많은 노력이 있어 왔다. 또한, 이러한 이슈에 대한 솔루션을 찾아내기 위해 투입된 돈과 자원의 양은 상당하다. 이러한 노력에도 불구하고, 명령어 처리 아키텍처에서 처리량 대 실시간 처리의 문제가 남아 있다.

다양한 종래의 기술이 다음의 논문에 기술되어 있는데, 이들은 가시적인 솔루션의 발견 없이 알려진 시간의 길이 및 상기 문제를 설명하는 역할을 한다.

1) KAl LI ET AL: "Multiprocessor Main Memory Transaction Processing" 19881205; 19881205-19881207, 5 December 1988, pages 177-187, XP010280434.

2) GARCIA-MOLINA H ET AL: 'MAIN MEMEORY DATABASE SYSTEM:AN OVERVIEW' IEEE TRANSACTIONS ON KNOWEDGE AND DATA ENGINEERING, IEEE SERVICE CENTRE, LAS ALAMITOS, CA, US, vol. 4, no.6, 1 December 1992, pages 509-516, XP001167057 ISSN: 1041-4347.

3) GRAY J ET AL: "Transaction processing: concepts and techniques, PASSAGE' 1 January 1993, TRANSACTION PROCESSING: CONCEPTS AND TECHNIQUES, PAGE(S) 249 - 267, 301 , XP002323530.

4) GRAY J ET AL: "Transaction processing: concepts and techniques' 1 January 1993, TRANSACTION PROCESSING: CONCEPTS AND TECHNIQUES, PAGE(S) 333 - 347, 496, XP002207245.

본 발명은 상기 문제 중 적어도 일부를 해결하고자 하는 것이며, 매우 많은 수의 처리 명령어를 실시간으로 처리하고 취급하는 개선된 시스템을 제공하고자 한다.

본 발명의 더 세부적인 목적을 고려하기 전에, 명령어 처리 아키텍처의 몇몇 중요한 특징을 이해하는 것이 중요하며, 이를 이하에서 나타낸다.

각각의 새로운 시스템은 특정의 처리량 요구 조건을 갖고 있다. 처리량은 시스템의 목적에 부응하기 위해 미리 규정된 시간 내에 시스템이 실행하여야 하는 명령어의 수를 나타낸다. 처리량은 매일, 매시간, 매분 또는 매초 처리된 명령어의 수로 나타낼 수도 있다. 처리량은 매초당 100 개보다 더 큰 경우 "고처리량"이라고 한다.

명령어 프로세서의 싱글 인스턴스로 처리 아키텍처를 실시하는 시스템에서, 상기 프로세서는 필요한 처리량을 달성할 수 있어야 한다. 그러나, 싱글 프로세서가 이를 달성하는 경우에, 병렬로 명령어를 처리하는 프로세서들의 복수의 인스턴스를 갖게 하는 것은 상기 목적이 달성될 수 있도록 하여야 한다. 후자의 경우에, 전체 처리량은 각각의 인스턴스에 의해 도달된 처리량의 합계이다. 명령어 실행 프로세스가 복수의 후속 단계로 구성된다면, 전체 명령어 실행 프로세스의 처리량은 가장 약한(가장 느린) 단계(예컨대, bottleneck)의 처리량에 의해 결정된다.

신규 시스템의 응답 시간은 제3자의 서버로부터 들어오는 명령어 실행 리퀘스트의 수신과, 그 서버로의 관련 답신 반송 사이의 경과된 시간을 나타낸다. 5초 미만의 평균 응답 시간을 갖고 있는 명령어 처리 시스템은 "실시간" 시스템이라고 할 수 있다. 명령어 프로세서의 싱글 인스턴스를 구동하면, 응답 시간은 상기 요구를 처리하는(상기 요구를 읽고 명령어를 실행하는) 시간과 답신을 전송하는(답신을 생성하여 전송하는) 시간으로서 측정될 수 있다. 리퀘스트가 시스템의 처리량보다 높은 속도로 도달한다면, 리퀘스트의 큐잉(queuing)이 일어난다. 이러한 경우에, 큐(queue)에서 리퀘스트가 소모하는 시간은 그 레퀘스트에 대한 시스템의 전체 응답 시간의 일부로서 고려되어야 한다. 명령어 프로세서가 복소의 처리 단계로 구성되는 경우, 시스템의 전체 응답 시간은 각 단계의 응답 시간의 합으로서 계산된다.

통상적으로, 각 명령어 처리 시스템은 수 백개의 당사자의 서버로 동작하며, 국소적으로 저장된 각 당사자에 대한 대응 리소스 계정을 갖고 있다. 각 당사자가 많은 리소스 계정(수십 개 및 수백 개는 흔하다)을 가질 수 있음에 따라, 명령어들이 관계되는 리소스 계정들은 이들 많은 리소스 계정 파일에 걸쳐 균일하게 분포될 수 있다. 그러나, 명령어 처리 시스템의 일부 특정 애플리케이션에서, 작은 셋트의 리소스 계정 파일이 높은 빈도로 업데이트되도록 명령어에 포함되어야 하는 그러한 조건이 있다. 명령어 처리 시스템의 집중은 작은 셋트의 리소스 계정 파일이 빈번하게 처리된 명령어에 포함되는 정도를 결정한다. 5%의 리소스 계정 파일을 업데이트하는 명령어의 50%를 갖고 있는 명령어 처리 시스템은 "고집중도"를 갖는 것으로서 규정된다.

상기한 특징과 관련하여, 본 발명의 다른 특정 목적은 실시간으로 동작하고(상기한 바와 같다), 고처리량을 가지며(상기한 바와 같다), 고집중도(상기한 바와 같다)를 취급할 수 있는 명령어 처리 시스템을 제공하는 것이다.

본 발명은 고집중도의 명령어를 취급할 수 있는 실시간 명령어 처리 시스템에서 매우 빠른 처리량을 달성하고자 할 때 종래의 접근법의 한계를 부분적으로나마 인식하고 있다. 본 발명자들은 새로운 하이브리드 데이터 처리 아키텍처를 개발하였는데, 상기 아키텍처는 평소에는 필요한 분산 처리(distributed processing)의 속도와 순차 처리의 확실성을 이용하여, 고집중도를 취급할 수 있고 실시간으로 동작 가능한, 대량의 명령어들을 위한 최적화된 데이터 처리 아키텍처를 제공한다.

본 발명의 한 가지 양태에 따르면, 매우 많은 수의 처리 명령어를 처리 세션 중에 실시간으로 처리하고 취급하기 위한 시스템이 제공되는데, 각각의 처리 명령어는 리소스 계정 데이터 파일을 특정하고, 상기 데이터 파일은 두 상이한 당사자(엔터티)와 상기 데이터 파일들 사이에서 교환되는 리소스의 양 및 타입과 관련된다. 상기 시스템은 복수 개의 프리로더(preloader)를 포함하는데, 각 프리로더는 상기 명령어와 관련된 참조 데이터를 얻도록 구성되며, 상기 참조 데이터는 상기 특정된 각 리소스 계정 데이터 파일(30)의 현재 값을 나타낸다. 상기 복수 개의 프리로더는 복수 개의 각 수신된 명령어에 대하여 마스터 데이터베이스로부터 상기 참조 데이터를 읽도록 병렬 동작하게 구성된다. 상기 시스템은 각 프리로드된 참조 데이터와 함께 복수 개의 처리 명령어를 큐잉하기 위한 인리치 명령어 큐(enriched instruction queue)를 포함한다. 상기 시스템은 상기 수신된 참조 데이터를 이용하여, 각각의 수신된 명령어가 관련 리소스 계정 파일의 현재 값 하에서 실행될 수 있는지, 각각의 실행 가능한 명령어가 업데이팅 커맨드를 생성할 수 있는지를 순차적으로 결정하도록 구성된다. 상기 시스템은 상기 실행 엔진으로부터의 업데이팅 커맨드에 응답하여, 각 실행 가능한 명령어의 결과로 상기 마스터 테이터베이스를 업데이트하는 업데이터를 포함하고, 상기 업데이터의 동작은 상기 실행 엔진의 동작과는 디커플링된다(decoupled).

본 발명에 도달할 때쯤에, 본 발명자들은 제일 먼저 하기의 사항들을 인지하였다.

실시간 응답을 제공하기 위하여, 본 발명의 명령어 처리 시스템은 개개의 리퀘스트를 처리하고 응답할 수 있어야 한다. 따라서, 순수한 "배치 지향적(batch oriented)" 솔루션은 그러한 솔루션이 매우 효과적일지라도 실시할 수가 없다.

본 발명의 명령어 처리 시스템은 매우 높은 고처리량에 도달하여야 하며, 이 때문에, 상당 수의 업데이트가 상기 저장된 리소스 계정 파일에 대하여 짧은 시간 내에 수행되어야 한다. 전통적인 종래의 병렬 입력 매칭 접근법(도 7에서 설명함)에서는, 실시간 처리가 가능하고, 처리량의 증대는 명령어 프로세서의 여러 인스턴스를 병렬로 구동함으로써 달성될 수 있었다. 그러나, 시스템은 고집중도의 명령어를 처리해야 하므로, 명령어 프로세서의 여러 인스턴스를 병렬로 구동하게 되면, 명령어들의 로킹을 증가시키게 되고, 이는 불리하게도 처리량을 감소시킨다.

본 발명자들은 종래의 접근법들의 특징들을 새로이 특정 조합하면 개선된 솔루션을 얻을 수 있고, 이는 본 발명의 목적을 충족시킨다는 것을 인지하였다. 새로운 하이브리드 솔루션은 명령어들을 순차 처리함으로써 명령어에 미치는 로킹 효과를 방지한다. 이에 의해 보통 나타나게 되는 처리량의 감소는 실제 처리를 최소한의 것으로 줄임으로써, 즉 단지 명령어 프로세서가 명령어 자체가 실행될 수 있는지 여부를 결정하게만 함으로써, 미연에 방지된다. 계정 리소스 파일들의 업데이팅은 명령어 프로세서의 상기 결정과는 디커플링되어 있고, 그 결정과는 외부에서 이루어져, 명령어 프로세서의 처리량을 증대시킨다. 또한, 처리 결정하는 데에 필요한 모든 데이터로 명령어를 프리로딩함으로써, 시간적으로 고비용의 데이터베이스 액세스가 명령어 프로세서에 의해 방지된다.

본 발명은 싱글의 순차 실행 엔진을 구동하는 것에 기초하고 있기 때문에, 처리 명령어에 대한 참조 데이터의 프리로딩을 필요로 한다. 이것이 없다면, 프리로더의 하류측에서 실행되는 상기 싱글 순차 실행 엔진은 원하는 고처리량에 도달할 수 없을 것이다. 이것은 실행 엔진이 명령어를 처리하기 위하여 많은 참조 데이터 값을 읽어야 하기 때문이며, 만일 그러한 읽는 동작이 마스터 데이터베이스에 대하여 실행된다면, 프로세서 사이클의 면에서 매우 비쌀 것이다. 원하는 전체적인 처리량에 도달하기 위하여, 상기 프리로딩 기능은 멀티-인스턴스 구성 요소로서 실시되는데, 이는 복수 개의 프리로더가 바람직하게는 병렬로 다루어지는 복수 개의 명령어 각각에 대하여 마스터 데이터를 읽기 위해 제공된다는 것을 의미한다. 또한, 상기 프리로더는 복수의 입력 큐(인스턴스)를 가질 수 있는데, 이는 병목현상을 경감시키는 것을 도와주며, 각 입력 큐는 복수 개의 프리로더 중 대응하는 프리로더에 전용의 입력을 제공하도록 구성된다. 병렬 처리의 확장성은 로킹 이슈에 의해 위태롭게 되지는 않는다. 이것은 프리로더 동작은 단지 읽혀지기만 하기 때문이며, 이는 로킹 문제를 야기할 수 없다.

마스터 데이터베이스는 단지 상기 업데이터에 의해서 실시간 업데이트된다. 프리로더의 읽기만 하는 동작은 따라서, 유리하게도 데이터베이스 로킹을 발생시키지 않는다. 프리로더는 단지, 업데이터의 업데이트 프로세스에 의해 이미 로킹된 리소스 계정 파일을 읽으려고 하는 경우에 지연된다. 프리로더 성능은 또한 병렬로 구동하는 데이터 읽기 기능의 새로운 인스턴스를 추가함으로써 확장 가능하다.

상기 시스템은 또한, 상기 실행 엔진에서 저장되고, 상기 업데이트된 리소스 계정 파일 각각의 업데이트된 실시간 값의 표현이 얻어지도록 상기 리소스 계정 파일 상에서 실행된 명령어의 결과로 업데이트되도록 구성되어 있는 현재 조건 테이블을 포함한다. 상기 실행 엔진은, 명령어의 후속되는 순차 처리를 위해, 특정 리소스 계정 파일에 대한 프리로더로부터의 참조 정보에 우선하여, 상기 현재 조건 테이블 내의 정보를 이용하도록 구성된다.

각 프리로더는 마스터 데이터 콜렉터를 포함하며, 각 마스터 데이터 콜렉터는 마스터 데이터베이스로부터 읽도록 구성되어 있다. 비동기적 프로세스(asynchronous process)이므로, 참조 데이터의 검색된 값들은 못쓰게 될 수도 있다. 이것은 문제가 되지 않는데, 왜냐하면 실행 엔진은, 처음으로 정보를 수신하고 이것이 현재 조건 테이블에 저장되는 경우 상기 마스터 데이터는 정확하다라는 것을 알고 있기 때문이다. 첫 번째 명령어가 실행된다면, 현재 조건 테이블 내의 리소스 계정 파일들의 값들에 대한 업데이트가 이루어진다. 그러나, 역시 동일한 리소스 계정 파일을 참조하는 후속 명령어들은 유리하게도, 마스터 데이터베이스의 못쓰게 된 값보다는 특정 리소스 계정 파일에 대한 업데이트된 정확한 값을 갖고 있는 현재 조건 테이블 내의 값들을 이용한다.

상기 현재 조건 테이블의 가장 빠른 가능한 실시를 보장하기 위하여, 상기 실행 엔진은 바람직하게도, 상기 현재 조건 테이블을 저장하기 위한 고속의 로컬 데이터 메모리를 포함한다.

상기 시스템은 또한, 복수 개의 상이한 소스로부터 실시간 명령어 및 배치 명령어를 수신하도록 구성되고, 복수 개의 프리로더에 대한 입력을 위해 상기 명령어를 큐 하도록 되어 있는 초기 입력 큐를 더 포함할 수 있다. 상기 초기 입력 큐는 바람직하게는 우선 순위(priority)를 각각의 들어오는 명령어에 할당하도록 구성된다.

명령어의 처리 결과가 실행 규칙 셋트의 위반을 야기하는 경우 처리 명령어 실패가 일어난다. 상기 규칙은 처리의 수용 불가능한 결과의 정의 또는 임계치를 제공할 수 있다. 예컨대, 명령어가 그 리소스 계정의 양이 0 미만으로 되게 한다면, 받아들여지지 않을 것이다. 어떤 리소스 계정에 대하여, 상기 임계치는 집합 리소스 값이 미리 정해진 레벨 미만이 되는 경우 도달될 수 있다.

상기 실행 엔진은 각 명령어의 우선 순위에 따라 명령어를 처리하도록 구성된다. 우선 순위 제어는 또한 리사이클 될 수 있는 실패한 명령어에 적용된다. 그렇게 하기 위해, 상기 실행 엔진은, 명령어가 관련된 리소스 계정 중 하나의 밸런스 상에 변화(통상적으로는 증가)가 발행된 경우 성공적으로 실행될 수 있었던 실패한 명령어의 재처리(reprocessing)를 포함한다.

상기 시스템은 처리 세션, 통상 하루 당 하나의 세션 내에서 동작한다. 동작일의 관점으로부터, 세션의 개시는, 상기 시스템이 동작 중이 아닌 경우에는 처리될 수 없었던 미리 저장된 모든 명령어의 실행을 유발한다. 이러한 초기 기간 중에, 상기 시스템 거동은 보다 배치 지향적으로 된다. 그러나, 상기 세션 개시 기간 중에도, 상기 명령어들의 배치가 처리를 위해 시스템에 의해 수신되고 있는 경우, 상기 시스템은 임의의 새로이 들어오는 비-배치(non-batch) 처리 명령어를 실시간으로 처리할 수 있고, 그들 명령어에 우선 순위를 할당할 수 있으며, 그 상대적인 우선 순위에 따라 처리를 위해 그 명령어들을 차례대로 나열할 수 있다(시퀀싱).

바람직하게는, 상기 실행 엔진은 실패한 처리 명령어를 고속 로컬 메모리에 저장하고, 그 실패한 처리 명령어에 의해 식별된 리소스 계정 파일 내에서 업데이트가 발생한 후에, 상기 실패한 처리 명령어를 재실행을 위해 제공하는 리사이클링 모듈을 포함한다. 이들 실패한 처리 명령어는 바람직하게는, 우선 순위 선정되어, 리사이클링 중에 성공적인 실행의 가능성을 개선할 수 있다. 보다 바람직하게는, 상기 시스템은 좀 더 작은 이동을 갖는 명령어보다는, 큰 리소스 계정 크레디트 또는 데비트 이동을 갖는 명령어에 더 큰 우선 순위를 부여하도록 구성될 수 있다.

일단 세션 개시에 의해 촉발된 명령어 벌크가 완료되면, 상기 시스템의 거동은 순전히 실시간으로 된다. 이 시간 동안에, 특정 리소스 계정 파일의 값 또는 특정 집합 리소스 값의 증가는, 특정 리소스 계정 파일의 값 또는 특정 집합 리소스 값이 너무 낮기 때문에 결제에 실패한 이전의 모든 명령어를 리사이클시키게 된다. 이러한 리사이클링은 바람직하게는 상기한 리사이클링을 위해 저장된 각 명령어의 미리 정해진 우선 순위에 따라 실행된다.

바람직하게는, 상기 리사이클링 모듈은 상기 실패한 명령어를 그 우선 순위의 순서대로 저장하도록 구성되고, 가장 높은 우선 순위의 명령어를 리사이클링 과정 중에 먼저 재실행하도록 구성된다.

상기 실행 엔진은 그 메모리 내에 실패한 모든 명령어를 유지하고 있기 때문에, 리소스 계정 파일의 레벨 또는 집합 리소스 레벨의 증가는 바람직하게는 그러한 증가를 기다리는 모든 실패한 명령어의 리사이클링을 촉발시킬 수 있다. 상기 실행 엔진은 바람직하게는, 참조 데이터의 증가(변화)를 기다리는 상기 실패한 명령어의 리스트를 그 로컬 메모리 내에 유지하며, 우선 순위의 순서를 따라 그 명령어들의 리스트를 처리하는 것은 비교적 쉽다.

상기 리사이클링 모듈은 명령어에 대한 리소스 계정 파일의 현재 값을 상기 리스트에 보유하고, 그 보유된 양을 리사이클링 과정 중에 해당 명령어의 요구 조건을 이행하는 데에 사용하도록 구성될 수 있다.

상기 보유된 양을 이용하여, 더 작은 명령어를 피하기 위해 큰 명령어에 대한 리소스 계정 내에 이용가능 리소스를 보유하는 것은 리사이클시 결제 효율을 증대시킨다. 예컨대, 명령어가 50을 필요로 하고 밸런스는 30이다. 결제는 20이 부족하여 실패한다. 상기 30을 보유하면, 단지 20만을 결제하는 데에 필요로 하는 더 작은 명령어의 실행을 방지할 것이다. 그 목적은, 20의 수취가 일어난다면(이는 다른 명령어의 실행에 의해 제공될 것이다) 50의 더 큰 명령어가 실행될 가능성을 제공하는 것이다. 이러한 보유 옵션은 실패한 명령어에 대하여 유지된다. 상기 리사이클링 엔진은, 주어진 리소스 계정 파일의 밸런스 양에 증가가 일어나는 경우 상기 보유 양을 증대시킬 수 있는 실패한 명령어를 실행할려고 시도한다.

상기한 바와 같이, 종래 기술의 실행 엔진에서 명령어의 리사이클링은 실행 엔진의 전체 성능을 저하시켰다. 상기한 다이나믹 리사이클링은 효율을 현저하게 증대시켜, 실행 엔지의 전체 성능은 사실, 어떠한 리사이클링 기능이 주어지지 않는 경우보다 더 빠르게 이루어진다.

상기 실행 엔진은 그 메모리 내에 리소스 계정 파일의 현재 값과 집합 리소스 레벨의 업데이트된 정확한 이미지를 보유하고 있기 때문에, 보존을 위한 어떤 필요성은 로컬 메모리 내에서 상대적으로 쉽게 구체화될 수 있다. 실행 엔진의 동작에 병렬성(parallelism)이 없기 때문에, 명령어는 우선 순위 순서로 수신되어, 가장 높은 우선 순위의 명령어가 먼저 보유된다.

상기 리사이클링 모듈은 실패한 처리 명령어를 미리 정해진 최대 횟수만큼 재실행하도록 구성될 수 있고, 상기 처리 명령어가 여전히 실행되지 않는다면, 상기 리사이클링 모듈은 그 실패한 명령어를 취소하도록 구성될 수 있다.

본 발명을 구현하는 시스템은 원하는 목적을 달성하도록 구축되었다. 채용된 아키텍처의 관점에서, 상기 시스템은 다음의 기술적 특징을 갖고 있다.

상기 시스템은 실시간으로 동작한다. 당사자가 명령어를 전송하면, 피드백(상기 명령어의 성공 또는 실패)이 통상 3초 이내에 수신된다. 이러한 경과 시간은 상기 당사자의 통신 인프라스트럭쳐와 상기 시스템 플랫폼 사이에서 상기 수신 명령어 및 답신 메시지를 전송하는 데 필요한 시간과, 상기 명령어의 처리를 실행하는 데에 필요한 시간을 포함한다. 이는 메시지를 처리 플랫폼에 전송하기 위한 1초, 처리 플랫폼 내에서 실행을 위한 1초, 답신 메시지를 명령 지시자에 전송하기 위한 1초로 분할된다. 물론, 상기 전송 시간은 네트워크 전송 로드 및 동작 조건에 의존함에 따라 미미하게 변할 수 있다는 것을 이해하여야 한다. 따라서, 상기 시간은 명령어에 대하여, SSE로 또 SSE로부터의 평균 전송 시간을 나타낸다.

본 발명을 구현하는 상기 시스템은 고처리량을 달성한다. 구체적으로, 상기 시스템은 (배치 명령어가 수신되고 있는) 처리 세션의 개시시에 통상 일어나는 피크 시간에 초당 500 개의 명령어의 처리량을 달성할 수 있다.

본 발명을 구현하는 상기 시스템은 "Synchronous Finality"라 명명되는 것을 달성한다. 이는, 실행 엔진이 명령어를 처리하는 경우, 포함된 당사자의 집합 리소스 값 및 이루어진 리소스 계정 모든 것에 대한 업데이트가 작업의 동일한 논리 단위의 일부로 실행되는 것을 의미한다.

본 발명을 구현하는 상기 시스템은 다른 애플리케이션이 리소스 계정 값의 마스터 데이터베이스에 액세스할 수 있도록 구성되어 있다. 이러한 유용성은, 상기 시스템이 활동 중인 동안에, 마스터 데이터베이스를 참고해야 하는 외부 시스템의 동작에 유리하다.

본 발명의 아키텍처의 디자인에 의해, 로킹 친화성(locking affinity)을 갖고 있지 않은 시스템이 얻어진다. 상기 마스터 데이터베이스 상에서 수행된 업데이트는, 상기 실행 엔진이 상기 동일 리소스 계정 파일을 고속으로 업데이트하는 경우에 성능이 영향 받지 않는 그러한 방식으로 관리된다. 이러한 본 발명의 특징은 집중적인 업데이트가 있는 실제 이점으로서, 예컨대 특정 집합 리소스 값이 초당 50번 업데이트될 수 있다.

바람직하게는, 상기 시스템은 실행 엔진의 처리 명령어 처리량을 결정하고, 대기 상태를 명령어 주입 프로세스(instruction injection process)(queue)에 적용하여 처리 명령어의 로딩 속도를 실행 엔진의 처리량 미만으로 저하시키기 위한 페이싱 모듈(pacing module)을 더 포함한다. 또한, 상기 실행 엔진이 몇 개의 처리 모듈을 갖고 있는 경우에(각 모듈은 명령어 로딩을 위한 복수의 인스턴스 큐를 갖고 있다), 상기 페이싱 모듈은 대기 상태를 실행 엔진 내의 임의의 처리 모듈의 임의의 큐에 적용하여, 명령어 로딩 속도를 실행 엔진 자체의 처리량 미만으로 저하시키도록 구성되어 있다.

메시지 큐잉 디자인에서, 상기 시스템은 너무 많은 명령어를 임의의 명령어 큐에 저장하는 것을 피해야 한다. 사실, 메시지 큐잉 시스템은 명령어를 데이터 콘테이너로서 보유하는 것이 아니라, 명령어를 전송하도록 설계된다. 이 마지막 기능은 데이터베이스에 보유되어야 한다. 정말로, 많은 명령어를 큐잉 처리하는 경우, 명령어 큐는 그들을 직접 메모리 내에 보유할 수는 없다. 대신에, 명령어 큐는 이러한 경우에, 그 명령어를 디스크에 오프로딩할 것이다. 그 결과, 처리량은 심각할 정도로 감소된다.

상기 시스템에서 너무 많은 메시지를 저장하는 것을 피하기 위하여, 상기 페이싱 모듈은 새로운 명령어가 시스템 내로 로딩되는 속도를 제어한다. 상기 로딩 속도가 큐잉 디자인의 가장 약한 링크의 처리량보다 높다면 큐잉이 일어날 것이다. 로딩 속도를 제어하기 위해서, "pacing"이라고 부르는 슬리핑 타임(sleep time)이 각각의 commit 후에 실행되어, 미리 규정된 속도를 초과하는 로딩 처리량을 방지할 수 있다.

바람직하게는, 상기 실행 엔진은 수신된 명령어의 실행의 결과를 통보하기 위한 통보 모듈을 포함하는데, 상기 통보 모듈은 실행될 수 있다고 결정된 각 명령어에 대한 업데이트 명령어, 각 실패한 명령어에 대한 통지 명령어를 출력하도록 구성된다.

상기 시스템은 또한, 상기 통보 모듈로부터의 통지 명령어 및 업데이트 명령어를 수신하고 큐 하도록 구성된 종국 큐(finality queue)를 포함할 수 있다.

상기 마스터 데이터베이스 업데이팅을 실행 엔진 결정과 디커플링 하는 것은 본 발명의 아키텍처에서 종래 기술과 비견되는 주요 차이점이다. 업데이트 명령어를 종국 큐 내에 배치하는 것은 명령어가 최종인 것으로 선언되는 방식이다. 대부분의 종래 배치 시스템은 "all or nothing"에 기초하에 동작하다. 따라서, 배치의 끝에서 종국이 도달된다. 대부분의 종래의 실시간 시스템은 그 최종 명령어를 마스터 데이터베이스에서 변화를 commit함으로써 얻는다. 본 발명에서, 상기 종국은 실행 엔진이 업데이트 명령을 종국 큐 내로 commit하자마자 도달된다. 이것은, 실행된 명령어와, 마스터 데이터베이스 내의 리소스 계정 파일의 관련 값 사이의 실시간 동시성(reali-time synchronisation)이 없다는 것을 의미한다.

상기 처리 아키텍처의 디커플링 특징은 복수의 프리로더에 의해 읽혀진 참조 데이터가 구식이 될 수 있다는 것을 의미한다. 본 발명은 처음 참조 데이터가 실행 엔진에 제공될 때, 그 참조 데이터의 값은 참조 계정 및 집합 참조 값의 실제 현재 상태를 반영하는 것을 보장해 준다. 그렇게 하기 위해, 상기 시스템은 바람직하게는, 명령어의 실행을 반영하는 모든 업데이트 커맨드가 처리 세션 개시 전에, 즉 프리로더 및 실행 엔진의 동작을 개시하기 전에, 마스터 데이터베이스 내에 반영되도록 하는 것을 보장할 필요가 있다. 즉, 처리 세션을 시작하기 전에 모든 큐가 비어 있는 것이 보장된다.

바람직하게는, 상기 통보 모듈은 commit 이벤트가 일어날 때까지 복수 개의 업데이트 명령어를 일시적으로 저장하고, 그 저장된 복수 개의 업데이트 명령어를 상기 commit 이벤트의 발생시 출력하도록 구성되며, 상기 commit 이벤트는 상기 실행 엔진에 의한 작업의 한 물리적 단위의 완료를 나타낸다.

디자인에 의해, 상기 시스템 처리 단계는 복수 개의 단계를 포함한다. 시스템의 전체 처리량은 가장 약한 링크에 의해 제한된다. 프로세스 중 어느 단계가 병렬성을 통한 확장성을 갖고 있는 경우, 그 단계는 가장 약한 링크일 수는 없다(성능은 추가의 단계를 동시에 구동함으로써 늘 증가될 수 있다). 그 결과, 시스템의 가장 약한 링크는 후속 실행 엔진이 되는데, 왜냐하면 병렬성을 지원하지 않는 시스템의 유일한 구성 요소이기 때문이다.

실행 엔진 따라서 시스템의 성능을 개선하기 위하여, 불필요한 외부 데이터 액세스를 피함으로써, 가능한 한 많이 CPU에 구속되어 상기 실행 엔진의 동작을 유지하도록 모든 일을 다 해야 한다. 상기 복수 개의 프리로더를 이용함으로써, 상기 실행 엔진이 필요로 하는 읽혀진 모든 데이터는 명령어와 함께 프리로드되고, 출력시 실행될 모든 업데이트 명령어는 싱글의 명령어 메시지로 일괄되어진다. 결론적으로, 실행 엔진의 외부 데이터 액세스는 입력시 하나의 지속적인 메시지와 출력시 하나의 지속적인 메시지로 제한된다. 다른 데이터 액세스를 추가하는 것은 가능하지만, 이는 불리하게도 시스템의 전체 처리량을 감소시킬 것이다.

성능을 개선하기 위하여, CPU 사이클을 버닝하는 것을 피하기 위한 모든 조치를 다 함으로써 실제 명령어 실행이 아닌 다른 로직을 수행하여야 한다. 예컨대, CPU 사이클은 commit 타임 중에 버닝된다. 따라서, 실행 엔진은 (commit 프로세스를 실행하기 전에 (로컬 메모리 내에) 복수 개의 들어오는 명령어를 실행하는) 작업의 논리적 단위들의 셋트를 묶는(bundle) 물리적 작업 단위를 수행한다. 50의 commit 빈도에 있어서, 초당 500 개의 명령어의 처리량은 500 대신에 초당 10 개의 commit을 야기한다. commit 프로세스는 실행 엔진에 대한 물리적 작업 단위를 나타낸다. 50의 commit 빈도는, 수행된 모든 업데이트의 마지막을 제공하는 기술적 commit 상태로 들어가기 때문에, 50개의 처리 명령어가 실행되고 보고된다는 것을 의미한다(들어오는 명령어의 물리적 삭제 및 통보 메시지의 물리적 기록).

바람직하게는, 상기 시스템은 또한 라우팅 프레임워크(routing framework)를 포함하는데, 상기 라우팅 프레임워크는 명령어를 복수 개의 초기 입력 큐 또는 동시에 동작하는 업데이팅 인스턴스 큐에 분배하도록 구성된다. 이는 명령어가, 복수 개의 상이한 큐 또는 처리 요소가 프리로더 및 업데이터에서와 같이 이용 가능한 경우에, 균일하게 분배되도록 해준다.

상기 라우팅 프레임워크는 바람직하게는, 명령어가 관련된 정보의 타입을 기술하는 명령어 이름과, 그 명령어를 식별하는 독특한 키이를 제공하는 작업로드 밸런서 키이(workload balancer key)를 명령어에 할당하도록 구성될 수 있다. 이러한 경우에, 라우팅 프레임워크는 입력 큐 중 하나 또는 업데이팅 인스턴스 중 하나를 상기 수신된 명령어 이름 및 작업로드 밸런서 키이를 이용하여 선택하도록 구성될 수 있다.

바람직하게는, 상기 라우팅 프레임워크는 작업로드 밸런서를 포함하는데, 이 밸런서는 라우팅 프레임워크와 함께, 초기 입력 큐 중 하나 또는 업데이팅 인스턴스 큐 중 하나를 상기 수신된 명령어 이름 및 작업로드 밸런서 키이를 이용하여 선택하도록 구성된다.

병렬성을 이용하여 처리량에 도달하는 시스템의 각 구성 요소(예컨대, 프리로더 및 업데이터)에 대하여, 상기 작업로드는 그 구성 요소 각각의 사이에서 상기 작업로드 밸런서 및 라우팅 프레임워크에 의해 정확하게 분배된다. 그러나, 유리하게도, 이러한 분배는 들어오는 명령어가 실행될 순서를 규정하는 시퀀싱 규칙에 어떠한 위반도 생성하지 않는다.

상기 라우팅 프레임워크 및 작업로드 밸런서는 작업로드를 큐의 셋트(예컨대, 마스터 데이터 격리 큐(master data segregation queues)) 상에 분배할 수 있고, 동일한 시퀀싱 키이를 갖고 있는 명령어들이 동일한 큐로 라우팅되는 것을 보증할 수 있다. 프레임워크는, 이용 가능한 인스턴스의 갯수를 분석하고, 나가는 메시지를 시퀀싱 구속 사항을 깨뜨리는 일 없이 확산시킴으로써, 그 자체를 직접 타겟 프로세스에 적응시킬 수 있다.

즉, 상기 작업로드 밸런서는 주어진 작업로드 밸런서 키이를 동일한 특정 목적지에 늘 링크시켜, 특정 리소스 계정 데이터 파일과 연관된 모든 명령어가 늘 복수 개의 큐 중 동일한 큐로 라우팅되는 것을 보장하도록 구성된다.

바람직하게는, 상기 시스템은 구분자 프레임워크(delimiter framework)를 더 포함하는데, 이는 주어진 시간에서 처리 세션이 닫혀지는 것에 응답하여, 실행 엔진의 출력에 주어진 큐의 입력에 메시지를 전송하고, 그 응답을 대기하며, 추가의 메시지를 업데이터의 입력 큐에 전송하고 그 응답을 기다리도록 구성되며, 상기 순차적 응답의 수신은 상기 처리 세션이 닫혀지기 전에 실행된 모든 처리 명령어의 결과로 마스터 데이터베이스의 업데이트를 나타낸다.

상기 시스템이 각 처리 명령어의 결과를 보고하기 위한 디스패처 모듈(dispatcher module)을 포함하는 경우, 바람직하게는 상기 구분자 프레임워크는 또한 그 디스패처의 입력 큐에 메시지를 전송하도록 구성되고, 처리 세션이 닫혀지기 전에 실행된 처리 명령어에 대한 통보 메시지가 모두 전송되었다는 것을 확인해 주는 응답 피드백을 기다린다.

즉, 상기 구분자 프레임워크는 실행 엔진의 출력, 즉 종국 큐에 메시지를 전송한다. 그 메시지에 대한 응답을 받자마자, 이것은 구분자 메시지의 도달 전에 종국 큐에 저장된 모든 명령어가 처리되었다는 것을 나타낸다. 그 이후, 구분자 프레임워크는 디스패처의 각 인스턴스에 메시지를 전송할 수 있고, 그들 각각으로부터 대응 피드백을 기다린다. 디스패처로부터 모든 인스턴스가 관련된 피드백을 구분자 프레임워크에 전송하면, 구분자 프레임워크는 모든 디스패치 프로세스(명령, 실행, 결과 및 보고)가 완료된 것을 알게 된다. 다음에, 구분자 프레임워크는 업데이터 상에서 구분 프로세스(delimiting process)를 시작할 수 있다. 이것은 마스터 데이터 업데이터의 각 인스턴스에 메시지를 전송하고 관련된 모든 피드백을 대기함으로써 이루어진다.

피드백이 마스터 데이터 업데이터의 모든 인스턴스로부터 수신되면, 구분자는 데드라인 전에 포지셔닝 엔진에 의해 실행된 명령어의 처리와 관련된 모든 명령어 업데이트가 이제 마스터 데이터베이스에서 반영되었다는 것을 알게 된다. 구분자 작업 흐름은 완료되고, 세션 활동 리포트가 디스패처에 의해 생성될 수 있다.

본 발명은 또한 처리 세션 중에 매우 많은 수의 처리 명령어를 실시간으로 처리하고 다루는 컴퓨터 실행 방법으로 확장된다. 각각의 처리 명령어는 리소스 계정 데이터 파일을 규정하며, 상기 데이터 파일은 두 상이한 당사자와 상기 파일들 사이에서 교환되어야 하는 리소스의 양 및 타입과 관련되어 있다. 상기 방법은 복수 개의 프리로더로부터 명령어에 관련된 참조 데이터를 얻는 것을 포함하는데, 상기 각각의 프리로더는 명령어와 관련된 참조 데이터를 얻도록 구성되며, 상기 참조 데이터는 상기 특정된 리소스 계정 데이터 파일 각각의 현재 값을 나타내며, 상기 참조 데이터를 얻는 단계는 상기 복수 개의 프리로더를 병렬로 동작시켜 복수 개의 각 수신된 명령어에 대해 마스터 데이터베이스로부터 참조 데이터를 읽는 것을 포함하며; 각 프리로드된 참조 데이터와 함께 복수 개의 처리 명령어를 인리치 명령어 큐에 큐잉하는 것을 포함하고; 실행 엔진을 이용하여, 각각의 수신된 명령어가 관련 리소스 계정 파일의 현재 값 하에서 실행될 수 있는지 상기 수신된 참조 데이터를 이용하여 순차적으로 판단하고, 각 실행 가능한 명령어에 대해 업데이팅 커맨드를 생성하는 것을 포함하고; 상기 실행 엔진으로부터의 업데이팅 커맨드에 응답하는 복수 개의 업데이터를 이용하여 각 실행 가능한 명령어의 결과로 상기 데이터베이스를 업데이트하는 것을 포함하며, 상기 업데이팅 단계는 상기 실행 엔진의 동작과는 디커플링되어 있다.

본 발명의 다른 양태에 따르면, 처리 세션 중에 매우 많은 수의 처리 명령어를 실시간으로 처리하고 다루기 위한 시스템이 제공되는데, 각 처리 명령어는 리소스 계정 데이터 파일을 규정하며, 상기 데이터 파일은 두 상이한 당사자와 상기 파일들 사이에서 교환되어야 하는 리소스의 양 및 타입과 관련되어 있다. 상기 시스템은 복수 개의 프리로더(preloader)를 포함하는데, 각 프리로더는 상기 명령어와 관련된 참조 데이터를 얻도록 구성되어 있으며, 상기 복수 개의 프리로더는 마스터 데이터베이스로부터 상기 참조 데이터를 읽도록 병렬 동작하도록 구성되어 있다. 상기 시스템은 각각의 얻어진 참조 데이터와 함께 복수 개의 처리 명령어를 큐잉하기 위한 명령어 메시지 큐를 포함한다. 상기 시스템은 각 명령어 메시지를 순차 실행하기 위한 실행 엔진을 포함하며, 상기 실행 엔진은 임의의 마스터 데이터베이스 액세스를 이용하기 보다는, 상기 프리로드된 참조 정보를 이용하여, 상기 명령어 메시지가 관련 파일의 현재 조건 하에서 실행될 수 있는지 판단한다. 상기 시스템은 상기 실행된 명령어의 결과로 업데이트되어, 관련 파일의 업데이트된 실시간 위치를 확립하도록 구성된 현재 조건 테이블을 포함한다. 상기 실행 엔진은 명령어의 후속 순차 처리를 위하여, 상기 특정 데이터 파일에 대한 프리로더로부터의 참조 정보에 우선하여 상기 현재 조건 테이블 내의 정보를 이용하여, 해당 데이터 파일이 상기 처리 세션 중에 상기 실행 엔진에 의해 업데이트되었는지 여부를 판단하도록 구성된다.

이러한 양태의 본 발명은 실행 엔진에 대한 메모리 내의 최신의 리소스 계정 값의 실시간 업데이트 가능한 복사를 함으로써 상기 마스터 데이터베이스의 업데이팅을 피할 수 있는 방식과 관련된 것이다. 이는 대량의 처리 명령어를 실시간으로 처리하는 종래 기술의 많은 문제점을 해결하는 중요한 디자인 특징이다.

본 발명의 다른 양태에 따르면, 처리 세션 중에 매우 많은 수의 처리 명령어 메시지를 처리하고 다루기 위한 시스템을 제공하는데, 명령어는 상이한 속도로 비동기식으로 수신된다. 상기 시스템은 명령어 메시지를 순차 처리하도록 구성된 실행 엔진을 포함하는 처리 모듈 중 하나로 명령어 메시지 상에서 상이한 타입의 처리를 수행하는 복수 개의 처리 모듈과; 복수 셋트의 명령어 큐를 포함하며, 상기 셋트는 각 데이터 처리 모듈로의 입력을 큐잉하기 위해 제공된다. 상기 시스템은 상기 실행 엔진의 처리 명령어 처리량을 판단하고, 대기 상태를 임의의 명령어 큐에 적용하여, 처리 명령어의 로딩 속도를 실행 엔진의 처리량 미만으로 떨어뜨리는 페이싱 모듈을 포함한다.

상기한 바와 같이, 처리 세션 중에 매우 많은 수의 처리 명령어 메시지를 처리하고 다루기 위한 시스템으로서, 상기 명령어는 상이한 속도로 비동기식으로 수신되는 상기 시스템은 너무 많은 명령어를 임의의 명령어 큐에 저장하는 것을 피할 필요가 있다. 메시지는 저장되기 보다는 전송될 필요가 있는데, 이는 데이터베이스의 기능이다. 큐잉된 명령어의 수가 너무 크게 되면, 그 명령어는 처리량을 직접 감소시키는 시간 소모적인 프로세스인 디스크에 오프로드되어야 한다.

상기 시스템에서 너무 많은 메시지를 저장하는 것을 피하기 위하여, 상기 페이싱 모듈은 유리하게도, 새로운 명령어가 시스템 내로 로딩되는 속도를 제어한다. 상기 로딩 속도가 큐잉 디자인, 본 경우에 순차적 실행 프로세서의 가장 약한 링크의 처리량보다 높다면, 큐잉이 일어난다. 로딩 속도를 제어하기 위하여, 슬리핑 타임이라고 부르는 "페이싱"이, 각 처리 시간 후에 실행되어, 미리 정해진 속도를 초과하는 로딩 처리량을 방지한다.

본 발명의 다른 양태에 따르면, 처리 세션 중에 매우 많은 수의 처리 명령어 메시지를 처리하고 다루기 위한 시스템이 제공되는데, 각 처리 명령어는 데이터 파일을 특정하며, 상기 데이터 파일은 두 상이한 당사자와, 상기 파일들 사이에서 교환되어야 하는 리소스의 양 및 타입과 관련되어 있다. 상기 시스템은 복수 개의 프리로더를 포함하며, 각 프리로더는 상기 명령어와 관련된 참조 데이터를 얻도록 구성되고, 상기 복수 개의 프리로더는 마스터 데이터베이스로부터 상기 참조 데이터를 읽도록 병렬 동작하도록 그리고 상기 참조 데이터를 상기 명령어 메시지와 함께 실행 엔진에 출력하도록 구성되며, 상기 실행 엔진은 각 명령어 메시지를 순차 실행하도록 구성되고, 상기 실행 엔진은 임의의 마스터 데이터베이스 액세스를 이용하기보다는, 상기 프리로드된 참조 정보를 이용하여, 상기 명령어 메시지가 상기 관련된 리소스 계정 파일의 현재 조건 하에서 실행될 수 있는지 여부를 판단한다. 상기 시스템은 상기 파일 상에서 실행된 명령어의 결과로 업데이트되어 관련 파일의 업데이트된 실시간 위치를 확립하도록 구성된 현재 조건 테이블을 저장하기 위한 고속 로컬 메모리를 포함한다. 상기 시스템은 실패한 처리 명령어의 리스트를 상기 고속 로컬 메모리에 저장하고, 리사이클링 과정을 실행하기 위한 리사이클링 모듈을 포함한다. 상기 실패한 처리 명령어는 상기 실패한 처리 명령어에 의해 확인된 상기 테이블 내의 리소스 계정 파일의 업데이트가 일어난 후에 재실행을 위해 제공된다.

바람직하게는, 상기 리사이클링 모듈은 상기 실패한 명령어를 그 우선 순위 순서로 저장하고, 가장 높은 우선 순위의 명령어를 먼저 리사이클링 과정 중에 재실행하기 위해 제공하도록 구성된다. 이는 여러 상이한 우선 순위의 명령어를 최대의 처리량으로 효율적으로 다루는 최적의 방식을 제공한다.

상기 리사이클링 모듈은 명령어에 대한 리소스 계정 파일의 현재 값을 상기 리스트 중에 보유하고, 리사이클링 과정 중에 상기 명령어의 요구 사항을 이행할 때 이 보유된 양을 이용하도록 구성될 수 있다. 이는 리소스에 대한 유사한 요구가 초기 단계에서 식별되어 중요한 듀(due)의 실패를 방지하는 것을 보장한다.

또한, 상기 리사이클링 모듈은 유리하게도, 소정의 최대 횟수만큼 재실행을 위해, 실패한 처리 명령어를 제공하도록 구성될 수 있고, 처리 명령어가 여전히 실행되지 않았다면, 상기 리사이클링 모듈은 그 실패한 명령어를 취소하도록 구성될 수 있다. 이는 실행되지 않을 트랜잭션으로 시스템의 동작이 나빠지는 문제점을 방지한다.

본 발명의 이러한 다이나믹한 리사이클링의 이점은 리사이클링 모듈과 관련하여 이미 설명하였고, 따라서 반복 설명하지 않는다.

본 발명의 특정 실시예를 첨부 도면을 참조하여 설명한다.
도 1은 당사자 A, B 사이의 계약을 실행하는 명령어 처리의 기본적인 종래의 구조를 보여주는 개략도이다.
도 2는 마스터 데이터베이스에 저장된 리소스 계정 파일을 보여주는 개략적인 블록도이다.
도 3은 당사자로부터의 데이터 메시지 명령어의 구성을 부여주는 개략적인 블록도이다.
도 4는 도 1의 명령어 실행 서버의 주요 구성 요소를 보여주는 개략적인 블록도이다.
도 5는 종래의 명령어 처리 플랫폼의 일반적인 동작 방법을 보여주는 흐름도이다.
도 6은 배치 입력을 위한 종래의 표준 매칭 프로세스를 보여주는 개략적인 도면이다.
도 7은 병렬의 복수의 프로세스 입력을 위한 종래의 표준 매칭 프로세스를 보여주는 개략적인 도면이다.
도 8은 본 발명의 한 가지 실시예에 따른 처리 플랫폼을 보여주는 개략적인 블록도이다.
도 9는 도 8의 처리 플랫폼의 동작을 보여주는 흐름도이다.
도 10은 도 8의 처리 플랫폼의 프리로더 모듈의 동작을 보여주는 흐름도이다.
도 11은 도 8의 처리 플랫폼의 포지셔닝 모듈의 개략적인 블록도이다.
도 12는 도 11의 포지셔닝 엔진의 동작을 보여주는 흐름도이다.

본 발명의 한 가지 실시예에 따른 처리 플랫폼(150)을 도 8 내지 도 12를 참조하여 설명한다. 도 2 및 도 4를 참조로 도입부에서 설명한 것과 유사한 명령어 실행 서버(22) 내에 상주하는 처리 플랫폼(150)은 전체적인 동작면에서 종래의 명령어 실행 서버(22)와 등가이다. 구체적으로, 후술하는 본 실시예의 처리 플랫폼(150)은 도 4에 도시한 종래의 명령어 체크, 실행 및 업데이팅 엔진(70)을 대체한다.

도 8로부터 알 수 있는 바와 같이, 처리 플랫폼(150)은 4개의 주요 구성 요소, 즉 복수 개의 프리로더(152), 포지셔닝 엔진(154), 디스패처(156) 및 업데이터(158)를 포함한다. 이들 구성 요소는 후술하는 큐잉 모듈 및 다른 기능 모듈과 함께 도 8에 도시한 것과 같이 배치(구성)된다.

프리로더(152)는 모든 당사자의 리소스 계정 파일(30)과 집합 리소스 값(32)의 마스터 데이터베이스(24)에 읽기만을 위해 액세스한다. 도 8에서, 설명의 편의를 위해, 마스터 데이터베이스(24)는 프리로더(152)의 일부인 것으로 도시하였다는 것을 이해하여야 한다. 그러나, 프리로더(152)는 시스템에 단지 하나의 마스터 데이터베이스(24)가 있는 것처럼, 마스터 데이터베이스(24)를 포함하지 않는다는 것을 이해하여야 한다. 대신에, 각 프리로더(152)는 그 자신의 전용 초기 입력 큐(164)로부터 명령어를 액세스하는 기능을 하며, 마스터 데이터베이스(24)로부터 필요한 정보를 얻기 위한 마스터 데이터 콜렉터(182))(후술)를 포함하고, 결과를 인리치 명령어 큐(166)에 출력한다. 각 프리로더(152)는 마스터 데이터 콜렉터(182)(도 8 참조. 그러나, 간결하게 하기 위해 총 2개만을 도시한다)를 포함한다. 데이터 콜렉터(182)는 들어오는 결제 명령어를 다루는 모듈로서, 각각의 들어오는 커맨드는 하나의 마스터 데이터 콜렉터(182)에 할당된다. 마스터 데이터 콜렉터(182)의 기능은 그 커맨드에 대한 적절한 마스터 데이터를 마스터 데이터베이스(24)로부터 읽어, 이들을 원래의 결제 명령어와 함께 결합하여, 각 프리로더(152)로부터 출력되는 인리치 명령어(enriched instruction)(도시 생략)를 형성하는 것이다. 프리로더(152)(및 따라서 마스터 데이터 콜렉터(182))의 갯수는 프리로더가 데이터베이스 동작만을 읽는 것을 수행하는 것과 같이, 프리로더가 로킹과 같은 데이터베이스 충돌 없이 동작을 병렬로 수행함에 따라, 확장 가능하다. 마스터 데이터베이스(24)는 일정하게 업데이트되고 있지만, 이들의 종래의 문제점은, 마스터 데이터베이스 업데이트와 읽기 기능을 분리하고, 읽혀진 리소스 계정 값(30)이 처리 세션에서 최초로 읽은 후에, 정확할 것을 요구하지 않음으로서 방지된다.

포지셔닝 엔진(154)은 싱글 인스턴스 로직 프로세서(184)와 업데이트된 마스터 데이터 레코드 테이블(186)을 포함하며, 이 테이블은 상기 프로세서의 메모리에 저장된다. 업데이트된 마스터 데이터 레코드 테이블(186)은 마스터 데이터베이스 내의 리소스 계정 파일에 대응하는 복수 개의 파일(30a)을 포함한다. 그러나, 도 11로부터 알 수 있고 후술하는 바와 같이. 모든 리소스 계정 파일(30)이 대응 파일(30a)을 갖는 것은 아니다.

싱글 인스턴스 로직 프로세서(184)는 프리로더(182)에서 생성된 인리치 명령어를 수신하고 한 번에 하나씩 처리하여, 인치리 명령어가 기반하고 있는 결제 명령어를 실행(commit) 해야할지 아니면 롤백(rollback) 해야할지를 판단한다. 본질적으로, 각 당사자에 대한 리소스 계정 파일(30)의 값과 집합 리소스 값(32)이, 결제 명령어의 실행 후에, 받아들여진다면(즉, 실행 규칙(72)과 부응한다면), 결제 명령어는 받아들여진다. 이러한 결정을 하기 위하여, 싱글 인스턴스 로직 프로세서(184)는, 업데이트된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)을 상기 수용 가능한 결제 명령어로부터 비롯되는 각 리소스 계정 파일(30)의 최신의 업데이트된 값으로 계속 업데이트한다. 이들 업데이트된 리소스 계정 파일(30a)의 값은 후속하여 수신된 인리치 명령어에 포함된 대응 값에 우선하여 사용된다. 포지셔닝 엔진(154)의 출력은 표지셔닝 엔진(154)에 입력된 결제 명령어의 리스트로서, 명령어가 수용 가능한지, 즉 명령어가 ㅅ실행(commit) 되어야 하는지 혹은 수용할 수 없는 것인지, 즉 롤백(rollback) 하여야 하는지를 나타낸다. 또한, 롤백된 명령어는 보유되고, 리사이클되며, 이는 이하에서 상세히 설명한다. 명령어의 주제가 아닌 리소스 계정 파일(30)은 마스터 레코드 메모리 테이블(186) 내에 대응 파일을 갖고 있지 않으며, 따라서 메모리의 사이즈는 데이터베이스의 사이즈보다 작다.

디스패처(156)는 디스패처 프로그램 모듈(188)을 포함한다. 디스패처 프로그램 모듈(188)은 포지셔닝 엔진(154)로부터 출력된 처리된 결제 명령어의 리스트를 수신하고, 그 처리의 결과(commit 또는 rollback)를 결제 명령어와 연관된 당사자에게 통보한다. 롤백된 명령어의 경우, 실패의 이유가 응답 메시지에 기술된다. 실행(commit)된 명령어의 경우, 이들은 성공정으로 처리된 결제 명령어인 것으로 보고되고, 또한 업데이터(158)를 통과한다.

업데이터(158)는 복수 개의 마스터 데이터 업데이터(190)를 포함하는데, 이들 각각은 마스터 데이터베이스(24)의 독특한 부분에 액세스한다. 도 8은 마스터 데이터베이스의 3 부분(24a, 24b, 24c)을 액세스하는 3개의 마스터 업데이터(190)를 보여준다. 그러나, 본 실시예에서, 이것은 플랫폼(150)의 확장 가능한 부분이어서, 많은 마스터 업데이터(190) 및 데이터베이스(24a, 24b, 24c)의 관련된 독특한 부분들이 제공된다. 성공적인 결제 명령어가 마스터 업데이터 내로 분포되는 정확한 방법은 후술한다.

각각 입력으로서 결제 명령어(160)의 배치를 제공하는 복수의 시퀀스 파일 취급 프로세스(160), 실시간으로 수신되어 실시간으로 처리되는 결제 명령어를 다루는 하나 이상의 개별 명령어 취급 컴퓨터 또는 프로세스(162)(본 실시예에서는 하나만 도시)로부터 처리 플랫폼(150) 내로 입력이 이루어진다.

처리 플랫폼(150)의 주요 구성 요소 사이에 큐잉 모듈이 제공된다. 몇몇 경우에 있어서, 이들 큐는 동시 프로세스 도메인으로부터 순차적 프로세스 도메인으로 그리고 그 역으로 전환하는 수단으로서 작용한다. 구체적으로, 복수 개의 초기 입력 큐(164)가 입력으로서 복수 개의 프리로더(152)에 제공되어, 비동기성 결제 명령어 중 임의의 것을 큐 처리하는데, 상기 명령어는 복수의 시퀀스 파일 취급 프로세스(160) 및 개별 명령어 취급 프로세스(162)로부터 수신될 수 있다. 프리로더(152)의 마스터 데이터 콜렉터의 동시 동작의 결과를 조합(collate)하고, 이들 결과를 포지셔닝 엔진(154)에 입력하기 위한 순차 도메인 내로 놓기 위한 인리치 명령어 큐(166)가 제공된다. 포지셔닝 엔진(154)에 대한 출력은 종국 큐(168)로서, 이 역시 디스패처(156)로의 입력으로서 작용한다. 마지막으로, 복수 개의 마스터 데이터 격리 큐(170)가 디스패처(156)의 출력과, 업데이터(158)로의 복수의 입력 사이에 제공된다. 디스패처(156)로부터의 다른 출력은 답신 큐(172)로서, 이는 명령어 취급 프로세스(162)로의 실시간 메시징을 제공한다.

의심을 피하기 위하여, 초기 입력 큐(164), 인리치 명령어 큐(166), 종국 큐(168), 마스터 격리 큐(170) 및 답신 큐(172)는 도 8에서 명확한 바와 같이, 모두 복수의 인스턴스, 병렬 동작하는 복수의 큐에 의해 제공된다는 것을 이해하여야 한다.

3개의 추가 모듈이 제공되어 처리 플랫폼(150)을 통한 명령어의 흐름을 도와준다. 페이싱 모듈(174)은 명령어가 플랫폼(150)의 처리량의 가장 약한 링크 아래의 배치 프로세스(160)로부터 큐잉되고 있는 속도를 조절한다. 이와 같이 함으로써, 플랫폼(150) 내의 큐는 항상 거의 비어 있게 된다.

라우팅 프레임워크(175)가 사용되어, 명령어를 작업로드 밸런서(176)를 통해 큐로 라우팅한다. 라우팅 프레임워크는 수신된 명령어의 시퀀싱을 변화시키는 일 없이 라우팅의 상이한 양태들을 바꿀 수 있다는 점에서 융통성이 있다.

작업로드 밸런서(176)는 명령어의 작업로드를 큐의 셋트 상에 분배하고, 동일한 시퀀싱 키이(후술)를 갖고 있는 명령어/커맨드가 동일한 큐로 라우팅되는 것을 보장하는 데에 이용된다.

포지셔닝 엔진(154)에 의해 수행되고 주어진 시간 및 날짜 데드라인까지 종국 큐(168)에 기록된 모든 처리가 마스터 데이터베이스(24) 및 업데이팅을 확인하는 실시간 메시지에 반영되도록 구분자 프레임워크 모듈(178)이 이용된다.

도 9를 참조하여, 처리 플랫폼(150)의 전체 동작 프로세스(200)를 설명한다. 프로세스(200)는 단계(202)에서 비 실시간 배치 파일(160) 또는 실시간 개별 명령어 취급 프로세스(162)로부터 결제 명령어가 수신되면서 시작된다. 비 실시간 배치 파일은 예컨대, 특정의 향후 실행 날짜를 갖고 있는 명령어를 반복적으로 저장함으로써 생성될 수 있는데, 상기 배치는 상기 특정 날짜의 도래시 실행을 위해 생성된다. 여기서 사용되는 "배치'라는 용어는 레코드들이 임의의 특정 순서로 나열되어야 한다는 것을 의미하지 않는다. 본 실시예에서, 배치 내의 결제 명령어 순서는 중요하지 않다. 대신에, 상기 용어는 단순히 결제 명령어의 콜렉션을 나타내기 위하여 사용된다.

상기 프로세스(200)는 계속되어, 각 프리로더(152) 내로의 후속 입력을 위해 초기 입력 큐(164)에서, 단계(204)에서 수신 명령어가 큐잉된다. 이 큐잉(204)은 결제 명령어의 흐름을 비동기성 병렬 입력 도메인으로부터 동기성 순차 도메인으로 전환시킨다. 명령어들은 복수 개의 프리로더(152)에 의해 단계(206)에서 처리되어, 마스터 데이터베이스(24)로부터 각 명령어에 대한 참조 데이터를 얻는다. 이 프로세스는 복수의 마스터 데이터 콜렉터(182)(각 프리로더(152)에 대해 하나)를 이용하여 병렬 실행된다.

각 결제 명령어에 대하여, 결과 정보가 조합되어, 단계(208)에서 인리치 실행 명령어를 형성하는데, 이 명령어는 결제 명령어 자체와, 실행 규칙(72)을 위반하지 않으면서 상기 명령어를 실행할 수 있는지 여부를 판단하기 위해 포지셔닝 엔진이 필요로 하는 참조 마스터 데이터베이스 데이터 전체를 포함한다. 상기 인리치 실행 명령어 모두는 단계(208)에서, 인리치 명령어 큐(166) 내에 놓인다. 다시, 인리치 명령어 큐(166)는 병렬 동작하는 복수의 마스터 데이터 콜렉터(182)의 출력을 처리할 순차 인리치 결제 명령어의 리스트로 전환하는 기능을 한다.

이어서, 포지셔닝 엔진(154)은 단계(210)에서 순차적으로 각각의 큐잉된 인리치 결제 명령어를 순서대로 처리한다. 이 프로세스의 세부적인 사항은 후술한다. 그러나, 결제 명령어가 규칙(72)을 위반하지 않으면서 실행될 수 있는지 여부의 단계(212)에서의 판단은 여기에서 이루어진다. 그 대답이 부정적이라면, 결제 명령어는 단계(214)에서 리사이클되고, 통지 디스패처 메시지가 단계(216)에서 생성된다. 이 메시지는 결제 명령어가 성공하지 못했지만 향후에 리사이클 될 수 있다는 것을 나타낸다.

단계(212)에서 상기 대답이 긍정적이라면, 결제 명령어는 단계(218)에서 실행되고, 국소 저장된 업데이트된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)은 그 결제 명령어에 포함된 당사자에 대한 리소스 계정 파일(30)의 새로운 값과 집합 리소스 값(32)으로 업데이트된다. 실행된 결제 명령어는 단계(220)에서, 디스패처(156)를 피딩하고 업데이터(158)로의 후속 전달을 위해 종국 큐(168) 내에 업데이트 실행 명령어로서 저장된다. 도 9에 도시하지는 않았지만, 리사이클된 명령어는 또한 종국 큐로의 엔트리를 갖고 있다. 이들 실패한 명령어는 또한 통보 목적만을 위해 종국 큐 내에 놓이고, 업데이터(158)를 통과하지 않는다.

디스패처(156)는 종국 큐 내에 저장된 명령어를 읽고 단계(222)에서 통보 메시지를 생성하는데, 이들 메시지는 상기 명령어가 성공적인지 여부를 나타내는 것으로서, 결제 명령어에 의해 식별된 당사자에게 보내진다. 이들 메시지는 또한 단계(222)에서, 결제 명령어 당사자의 명령어 취급 프로세스(162)로의 실시간 출력을 위해 답신 큐(172)로 전송된다. 그 후에, 답신 큐 내의 메시지는 단계(224)에서 출력된다.

성공적으로 실행된 종국 큐(168) 내의 업데이트 실행 명령어에 대하여, 디스패처(156)는 단계(226)에서 이들 업데이트 명령어를 복수의 마스터 데이터 격리 큐(170)로 통과시킨다. 이러한 프로세스는 이하에서 상세하게 설명하는 바와 같이, 작업로드 밸런서(176) 및 구분자 프레임워크(178)로부터의 입력을 포함한다.

마지막으로, 각 마스터 데이터 업데이터(190)에 할당된 마스터 데이터베이스(24)의 부분(24a, 24b, 24c)은 단계(228)에서 업데이터(158)에 의해 업데이트된다.

처리 플랫폼(150)의 주요 구성 요소 및 그 기능을 좀 더 자세하게 설명한다.

초기 입력 큐(164)는 플랫폼(150)의 퍼블릭 인터페이스이다. 이는 개개의 명령어 취급 프로세스(162)-이에 대해 답신이 실시간으로 예상된다-로부터 오는 입력 흐름과, 복수의 시퀀스 파일 취급 프로세스(160)-이에 대해 매우 높은 처리량이 예상된다-로부터의 배치 흐름을 합치는 것을 가능케 한다. 페이싱 모듈(174)은 초기 입력 큐(164)로의 입력을 제어한다. 페이싱 모듈(174)은 배치 명령어의 로딩 속도를 플랫폼의 가장 낮은 처리량 구성 요소(통상, 포지셔닝 엔진(154)) 미만으로 제한한다. 배치 명령어의 경우, 로딩 속도는 초기 입력 큐(164)에서의 백로그(backlog)를 피하기 위하여 제한될 필요가 있다. 개개의 명령어 취급 프로세스(162)로부터의 로딩 속도는 신규 명령어를 입력하는 사용자 컴퓨터의 실시간 능력에 의해 제한된다. 이러한 초기 입력 큐(164)의 로딩 제어는 플랫폼(150) 내의 모든 큐에 적용된다.

페이싱 모듈(174)은 명령어 그룹(예컨대, 마스터 데이터베이스로부터 추출한 것 또는 파일 기반 배치 프로세싱)을 처리할 때 활성화된다. 도 8에서, 페이싱 모듈(174)은 흐름도의 상단, 즉 순차 파일과 초기 입력 큐(164) 사이에서 이용된다. 그 기능은 크루즈 컨트롤과 유사한데, 명령어 흐름에서 (가장 약한 링크 단계에서) 큐잉을 피하기 위하여, 초기 입력 큐(164) 내로의 배치 명령어 주입 속도를 제한한다.

플랫폼(150)에서 큐 입력 속도를 제어하는 두 가지의 기본 이유가 있다. 첫 번째 이유는 메시지 큐(164, 166, 168, 170)는 효과적인 트랜스포트 층이고 데이터 컨텐이너가 아니라는 것이다. 큐 내에 저장될 수 있는 메시지 또는 명령어의 갯수는 제한된다. 백로그를 생성하면 큐가 꽉 찬 조건이 야기될 수 있고, 이는 큐에 기록하는 로드 프로세스를 차단하게 된다. 더욱이, 메시지 큐잉 성능은 많은 수의 메시지를 큐에 저장하는 경우 감소한다. 이것은 종종 메시지 데이터의 디스크 상에의 오프로드가 필요하기 때문이다.

로드 프로세스의 속도를 제어하는 두 번째 이유는 개개의 명령어 취급 프로세스(162)로부터 오는 실시간 명령어가 배치 명령어의 셋트 뒤에서 큐잉되지 않는 것을 보장하기 위해서이다. 실시간 리퀘스트가 큐잉되면, 개개의 명령어 취급 프로세스(162)에 대한 응답 시간은 2초의 최대 응답 시간으로 설정된 실시간 응답 요구 조건과 매치될 수 없다.

페이싱은 두 후속 실행(commit) 사이의 최소 지연으로 규정된다. 실행(commit)를 수행한 후에, 실행(commit)이 수행되는 시간과 이전 실행(commit)이 수행된 시간 사이의 델타 시간이 계산된다.

예: 현재 실행(current commit)=2007-07-01-09.05.04.224335

이전 실행(previous commit) = 2007-07-01-09.05.04.100635

두 실행 사이의 경과 시간(The elapsed time between 2 commits) (delta) 은 0,123700

두 실행(commit) 사이의 페이싱이 0.5초라면, 0.3763 초의 지연이 실행될 것이다. 실행(commit) 빈도(frequency)가 50이고 페이싱이 0.5초라면, 예상되는 처리량은 100 개의 명령어이다.

초기 입력 큐(164)에의 입력은 라우팅 프레임워크(175) 및 작업로드 밸런서(176)에 의해 다루어지며, 이들은 초기 입력 메시지 큐(164)의 미리 규정된 셋트에 걸쳐 균일하게 메시지를 분배하기 위해 작업로드 밸런싱 기술적 프레임워크가 제공되는 메시지 라우팅 기능을 실현한다.

배치 파일(160)로부터 오는 명령어와 실시간 채널(162)로부터 오는 명령어 사이에 차이가 없다는 것을 인지하여야 한다. 플랫폼(150)에 대한 동작 시간 윈도우(동작 세션)의 개시시에, 저장된 모든 펜딩 중의 명령어는 시퀀싱되어 초기 입력 큐(164)로 주입된다. 시퀀싱 규칙은 또한, 개시 주입이 실행되고 있는 동안 실시간으로 들어오는 명령어에도 적용된다. 상기 실시간 명령어는 그 우선 순위에 기초하여, 초기 입력 큐(164) 내로 들어가야 한다. 동작 시간 윈도우의 개시를 위한 과정이 완료되면, 온-고잉 시퀀싱(on-going sequencing)은 시간에 기반한다. 동일 당사자의 동일 리소스 계정 파일(30)을 참조하는 두 명령어는 (하나 후에 다른 하나가 처리되도록 하기 위하여) 동일한 초기 입력 큐(164)에 주입되어야 한다.

복수의 초기 입력 큐(164)에 대하여, 이들 인스턴스를 병렬로 구동하는 것은, 예컨대 처리 세션(동작 시간 윈도우)의 개시시에 주어지는 고용량의 초기 명령어를 취급하는 데에 있어서 중요하다. 여기서, 라우팅 프레임워크(175)는 명령어를 복수의 초기 입력 큐(164)에 로딩하는 데에 책임이 있고, 이는 작업로드 밸런서(176)가 작업로드를 초기 입력 큐(164) 사이에서 균일하게 분배할 수 있도록 해준다.

각각의 프리로더(152)는 결제 명령어를 초기 입력 큐(164) 중 대응하는 큐로부터 검색하도록 구성되어 있다. 그 목적은 마스터 데이터베이스(24)로부터, 포지셔닝 엔진(154)이 결제 명령어를 실행할지 여부를 결정하는 데에 필요로 하는 모든 참조 데이터를 검색하기 위하여, 들어오는 결제 명령어를 분석하는 것이다. 참조 데이터는 결제 명령어에 포함된 리소스 계정 파일(30)의 현재의 값 및 결제 명령어에 포함되는 당사자에 대한 집합 리소스 값(32)이다. 다음에, 검색된 데이터는 들어오는 결제 명령어뿐만 아니라, 마스터 데이터베이스(24)로부터 검색된 모든 참조 데이터를 포함하는 증대된 명령어를 생성하는 데에 사용된다.

도 10은 각 프리로더(152)의 동작을 보다 세밀하게 보여준다. 명확히, 각 프리로더 인스턴스(154)는 독립적으로 동작되고, 병렬로 동작하여 더 큰 처리량을 용이하게 한다.

프리로더(154)의 동작 프로세스(240)는 단계(242)에서, 그 프리로더 인스턴스(154)의 전용 초기 입력 큐(164)로부터 결제 명령어의 판독으로 시작된다. 다음에, 프리로더 인스턴스(154)의 마스터 데이터 콜렉터(182)가 단계(244)에서, 각 당사자의 리소스 계정 파일(30)과 그 당사자에 대한 집합 리소스 값(32)의 데이터베이스 판독을 결정한다. 이들 판독된 명령어 모두가 컴퓨팅되면, 단계(246)에서 데이터베이스 판독이 순차적으로 실행된다. 그 후에, 판독된 데이터는 단계(248)에서, 프리로더 인스턴스(154)에 의해 처리되어, 그 명령어에 대한 참조 데이터의 조합 이미지(collated image)를 생성한다. 이 이미지는 단계(250)에서 원래의 명령어와 합쳐져 복합 인리치 명령어(composite enriched instruction)를 형성한다. 프리로더 동작(240)은 각 프리로더 인스턴스(154)의 복합 인리치 명령어가 단계(252)에서 싱글 인리치 명령어 큐(184)에 출력됨에 따라 마무리된다.

포지셔닝 엔진(154)은 본 실시예의 혁신적 아키텍처의 주요 요소 중 하나를 구현한다. 즉 포지셔닝 엔진(154)의 메인 로직 프로세서(184)는 명령어를 병렬 실행하지 않는다. 메인 로직 프로세서(184)가 싱글 인스턴스로서 구동하기 때문에, 그 자신에 의해 전체 처리량에 도달해야 한다. 가장 높은 가능한 처리량을 달성하기 위해 적용된 필요한 구속 사항 중 하나는 데이터베이스 액세스를 금지하여야 한다는 것인데, 왜냐하면 이러한 데이터베이스 액세스는 처리량을 저하시키기 때문이다. 메인 로직 프로세서(184)가 많이 사용된 정적 참조 데이터를 검색할 수 있는 초기 로드 이후에, 프로세서(184)로 또 프로세서(184)로부터의 외부 데이터 액세스는 입력되는 하나의 명령어 및 출력되는 하나의 처리 결과로 제한된다. 그러나, 명령어를 처리하기 위해 필요하지만 시동 상태 중에 로딩되지 않는 참조 데이터는 각 인리치 명령어의 일부로서 제공된 참조 데이터의 조합 이미지에 의해 이용 가능하게 된다. 하나의 프리로더(152)로부터 수신된 리소스 계정 파일(30)에 대한 제1 이미지의 참조 데이터만이 포지셔닝 엔진(154)에 의해, 업로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)에 저장된다. 이러한 제1 복사는 늘 유효한데, 왜냐하면 그 제1 복사는 명령어의 실시간 흐름에 의해 아직 수정되지 않았기 때문이다.

럽로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)에 이미 있는 경우, 하나의 프리로더(152)에 의해 검색된 참조 데이터의 이미지는 아마도 구식으로 되었기 때문에(포지셔닝 엔진(154)에 의해 확인된 업데이트는 마스터 데이터베이스에 아직 반영되지 않았다), 간단히 무시된다. 따라서, 리소스 계정의 값과 관련된 참조 데이터가 업로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)에서 이용 가능한 경우, 그 데이터는 인리치 명령어가 제공된 참조 데이터 이미지에 우선하여 늘 사용된다.

도 11을 참조하면, 포지셔닝 엔진(154)의 구성이 보다 상세히 도시되어 있다. 포지셔닝 엔진(154)은 인리치 명령어 큐(166)로부터 인리치 명령어를 검색하기 위한 명령어 수신 모듈(260)과, 현재의 인리치 명령어를 타임 스탬핑하기 위한 타임 스탬핑 모듈(262)을 포함한다. 포지셔닝 엔진(154)의 싱글 인스턴스 로직 프로세서(184)는 참조 데이터 검색 및 업데이팅 모듈(264), 이동 계산기 및 로컬 메모리 저장 업데이터(movement calculator and local memory store updater)(266), 명령어 처리 로직(268)을 포함한다.

참조 데이터 검색 및 업데이팅 모듈(264)은 업로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)에 저장된 데이터를 검색하고, 그 데이터가 업데이트 될지 또 업데이트 할지 여부를 결정한다. 업로드된 마스터 레코드 메모리 테이블(186)은 고속의 로컬 메모리 데이터 스토어(270)에서 싱글 인스턴스 로직 프로세서(184)에 제공되며, 이로 인해 포지셔닝 엔진(154)에 대한 읽고 쓰는 시간이 빨라진다. 따라서, 명령어 실행의 결정이 시간 소모적인 외부 데이터베이스 체크보다는, 메모리 데이터 체크에 의해 신속하게 실행될 수 있다. 데이터 스토어(270)는 또한, 나중에 결제를 위해 다시 시도될 실패한 명령어의 리사이클링 리스트(272)를 담고 있다.

상기 이동 계산기 및 로컬 메모리 스토어 업데이터(266)는 업로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a) 내에 저장된 참조 데이터를 판독하고, 명령어 정보를 이용하여 그 데이터를 어떻게 변화시킬지(이동) 또 업데이트된 참조 데이터를 다시 업로드된 마스터 레코드 메모리 테이블(186)에 기록하는 동작을 한다.

명령어 처리 로직(268)은 리소스 계정 파일(32)의 업데이트된 값과 집합 리소스 값(32)이 그 리소스 데이터에 대해 수용 가능한 위치로 있게 되는지 여부를 판단하기 위해 제공된다. 즉, 리소스 계정 파일(32)의 업데이트된 값과 집합 리소스 값(32)은 규칙(72)의 준수 여부가 평가된다.

실패한 명령어를 읽어 리사이클링 리스트(272)에 기록하기 위해 리사이클링 모듈(274)이 제공되며, 상기 리사이클링 리스트는 다시 명령어 로직 모듈(268)에 의해 판독되거나 그 로직으로부터 기록될 수 있다. 싱글 명령어 로직 프로세서(184)의 출력은 통보 모듈(276)로 보내지고, 상기 통보 모듈은 명령어 처리의 결과를 업데이트 실행 명령어로서 종국 큐(168)에 출력한다.

리사이클링은 들어오는 명령어들의 우선 순위에 기반한다. 우선 순위 그룹화(예컨대, 최상 우선 순위, 레귤러 우선 순위, 하위 우선 순위)가 이미 각 명령어에 할당되어 있다. 리사이클링 모듈(274)은 우선 순위 순서로 리사이클링 리스트를 보유하여, 리사이클링 이벤트가 발생하는 것에 대해 준비하고 있다. 상기 순서는 1차적으로 각 명령어에 할당된 우선 순위 그룹화 상에서 결정된다. 그 후에, 명령어의 크기가 우선사항 결정을 위해 이용된다. 리사이클링 리스트 내에 우선 순위를 유지함으로써, 구동 시간 중에 리사이클링이 비교적 쉽게 그리고 빠르게 실시된다. 게다가, 리사이클링 과정은 수신된 처리 명령어를 재실행하는 순서를 변화시켜 각 처리 명령어의 우선 순위를 반영할 수 있다는 점에서 동적으로 이루어진다.

리사이클링 모듈(274)은 또한 특정 명령어로 처리하기 위해 리소스 계정 파일(30)의 콘텐트를 보유하는 능력을 갖고 있다. 이는 리소스 계정 파일 내의 이용 가능한 리소스의 양이 저장된 처리 명령어(272)의 요구 사항을 만족시키는 경우 일어난다. 이러한 양을 보유함으로써, 리사이클링 모듈(274)은 우선 순위가 유지되는 것을 보장하고, 크고 우선 순위가 높은 명령어가 아니라 작고 낮은 우선 순위의 명령어를 실행하기 위해 이용 가능한 펀드가 있더라도, 작고 낮은 우선 순위의 명령어 전에 크고 높은 우선 순위의 명령어가 실행되는 것을 보장한다.

이는 포지셔닝 엔진(154) 내의 리사이클링 모듈(274)이 어떻게 수신 처리 명령어의 보유 및 우선 순위 취급을 구현하는 지를 보여주는 다음의 비제한적인 예에서 가장 잘 설명된다.

Example :

리소스 계정 파일 Acc/Sed 은 50개의 security를 담고 있다.

처리 명령어들이 순차적으로 수신되어, Acc/Sec1에 다음과 같은 영향을 준다:

Step1 Top priority Instruction 1 needs 200

Step2 Regular Instruction 2 needs 100

Step3 Regular Instruction 3 needs 150

Step4 Regular instruction 3 brings 60

Step5 Regular instruction 4 brings 290

메모리 구조(Acc/Sec1 내의 밸런스 및 리사이클링 리스트의 콘텐츠)는 다음과 같이 Acc/Sec1의 리사이클링 리스트를 나타낸다.

After Step1

Acc/Sec1

-contains 50

-Already reserved

- Instruction 1 for 50

-failed list <instruction1 >

After Step2

Acc/Sec1

-contains 50

-Already reserved

- Instruction 1 for 50

-failed list <instruction1, instruction2> (ins 2는 ins 1 보다 낮은 우선순위를 갖고 있다)

After Step3

Acc/Sec1

-contains 50

-Already reserved

- Instruction 1 for 50

-failed list <instruction1, instruction3, instruction2> (ins3는 ins 2와 동일한 우선 순위를 갖고 있지만 더 크고 따라서 더 중요하다)

After Step4: Acc/Sec1의 밸런스 증가는 실패한 명령어를 리사이클시켜, instruction1이 새로운 60 security를 그 보유분에 추가할 수 있도록 한다. 그러한 보유는 instruction 2(100 만을 필요로 한다)가, 리소스 계정에서 이용 가능한 110개의 security를 이용하는 것을 방지한다.

Acc/Sec1

-contains 110

-Already reserved

- Instruction 1 for 110

-failed list <instruction1, instruction3, instruction2>

After Step5: Acc/Sec1의 밸런스 증가는 리사이클링 프로세스를 개시한다.

리사이클링 시작 시에, 메모리는 다음과 같다:

Acc/Sec1

-contains 400

-Already reserved

- Instruction 1 for 110

-failed list <instruction1 ,instruction3,instruction2>

instruction 1(이는 리사이클링 리스트에서 첫번째이다)의 리사이클링(및 결제) 후

Acc/Sec1

-contains 200

-Already reserved

- 0

-failed list <instruction3,instruction2>

instruction 2(이는 리사이클링 리스트에서 새로운 첫번째이다)의 리사이클링(및 결제) 후

Acc/Sec1

-contains 50

-Already reserved

- 0

-failed list <instruction2>

instruction 2의 리사이클링은 실패한다(50 부족). 보유되지 않는다면, 메모리는 변하지 않은 채 남아 있다.

포지셔닝 엔진(154)의 동작(280)을 도 12를 참조하여 설명한다. 동작(280)은 단계(282)에서, 인리치 명령어 큐(166)로부터 인리치 명령어를 판독하면서 시작한다. 다음에, 판독된 명령어는 타임 스탬핑 모듈(262)에 의해 단계(284)에서 타임 스탬핑된다. 1초당 처리될 명령어의 갯수가 주어지면, 타임 스탬핑은 높은 해상도를 갖고 있으며, 통상 기록 시간을 마이크로 초로 다운시킨다.

단계(286)에서 판단되는 바와 같이, 타임 스탬핑된 인리치 명령어가 새로운 참조 데이터, 즉 업로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a) 내에 저장되지 않았던 특정 리소스 계정 파일(30)의 값을 포함하고 있다면, 미지의 참조 데이터는 업로드된 마스터 레코드 메모리 테이블(186) 내에 저장된다. 참조 데이터가 새로운 것이 아니라면, 동작(280)은 단순히 단계(290)의 국소 밸런스 업데이팅으로 이동하는데, 이동 계산기 및 로컬 메모리 저장 업데이터(266) 상에서 수행된다. 이 단계에서, 참조 데이터는 로컬 메모리 데이터 스토어(270) 내에서 업로드된 마스터 레코드 메모리 테이블(186)로부터 판독되고, 명령어에 특정된 이동은 판독된 참조 데이터에 적용되며, 참조 데이터의 결과 값은 다시, 업로드된 마스터 레코드 메모리 테이블(186)의 대응 파일(30a)에 기록된다.

후속하여, 명령어 처리 로직(268)은 단계(292)에서, 참조 데이터의 현재 값을 고려하고, 리소스 계정 파일(30)과 집합 리소스 값(32)의 결과적인 업데이트된 값이 참조 데이터의 수용 가능한 값과 관련하여 미리 정해진 규칙(72)과 부합하는지 여부를 판단한다. 부합하지 않으면, 3가지 동작이 취해진다. 먼저, 실패 이유가 단계(294)에서 통보 모듈(276)을 통해 통보된다. 두 번째로, 참조 데이터의 이전 값들이 단계(296)에서 복원된다. 마지막으로, 실패한 명령어는 단계(298)에서 나중의 결제 시도를 위해 리사이클링 리스트(272)에 저장된다.

업데이트된 참조 데이터가 미리 정해진 규칙(72)과 부합하는 경우, 결제 명령어의 성공적인 실행이 단계(300)에서 통보 모듈(276)에 의해 보고된다. 이러한 통보는 또한 그 명령어가 관련된 당사자에 대한 답신 메시지를 생성하고, 업데이터(158)에 지시하여 마스터 데이터베이스(24)를 업데이트 하도록 하는 작용을 한다. 이러한 동작의 영향은 단계(302)에서 밸런싱된다. 즉 마스터 계정 데이터에 적용 가능한 리소스 계정 이동 데이터가 생성되고, 밸런스 업데이트 메시지의 셋트가 생성된다. 이하의 예에서, 통보 메시지 및 밸런스 업데이트 메시지의 생성을 두 단계로 설명한다.

마지막으로, 리사이클링 동작이 단계(304)에서 구동되어, 수정된 참조 데이터가 이제 이전에 실패한 명령어가 실행될 수 있도록 하는지 여부를 확인한다.

물론, 업데이트된 것으로 보고된 모든 참조 데이터는, 리사이클된 명령어를 포함하는 후속 결제 명령어를 처리하는 동안에(프리로더 중 하나에 의해 제안된 동일 데이터의 구식 버전을 대체하는 동안에) 재사용하기 위해 포지셔닝 엔진(154)의 로컬 메모리(업로드된 마스터 레코드 메모리 테이블(186)) 내에 유지된다.

포지셔닝 엔진(154)의 로컬 메모리(270)의 파일(30a)에 유지되는 업데이트된 참조 데이터(30, 32)는 다시는 소거되지 않는다. 처리 기간, 예컨대 하루의 종료 시점에서, 포지셔닝 엔진(154)은 정지되어, 메모리를 완전히 리셋시킨다. 이러한 리셋은 또한, 포지셔닝 실행 중에 주요한 문제가 발생한다면 일어날 수 있다. 특정의 재시작 프로세스가 적소에 놓여져, 최종의 모든 업데이트가 마스터 데이터베이스(24)에 반영되어 있고, 복수의 프리로더(152)를 재시작하기 전에 인리치 명령어 큐(166) 내에 펜딩 중인 모든 명령어가 소거되었다는 것을 보장한다(이때, 마스터 데이터베이스는 최종 버전의 모든 밸런스를 반영한다).

복수의 프리로더(152)와 포지셔닝 엔진(154)이 함께 어떻게 동작하는지를 보여주는 비제한적인 예를 이하에 제시한다.

Example :

Instruction 1(Ins 1)은 프리로더 인스턴스1(마스터 데이터 콜렉터1)에 의해 처리된다. 이는 Sec2의 500 개의 유닛에 대해 Sec1의 10개의 security를 교환하는 리소스 계정 타입 sec1에 대한 (당사자 A)의 acc1과 (당사자 B)의 acc2 사이의 결제 명령어이다.

Instruction 2(Ins 2)는 프리로더 인스턴스2(마스터 데이터 콜렉터2)에 의해 처리된다. 이는 Sec2의 1050 개의 유닛에 대해 Sec1의 20개의 security를 교환하는 sec1에 대한 (당사자 C)의 acc3과 (당사자 B)의 acc2 사이의 결제 명령어이다.

상기 두 개의 명령어는 병렬 실행된다:

인스턴스1에 의해 생성된 메시지는 다음과 같다:

(image of the instruction) + (image of the related balances: acc1 /sec1 =1000, acc2/sec1 =300, acc1/sec2 = 25000, acc2/sec2= 30000 ...)

인스턴스2에 의해 생성된 메시지는 다음과 같다:

(image of the instruction) + (image of the related balances: acc3/sec1 =3000, acc2/sec1 =300, acc3/sec2 = 5000, acc2/sec2= 30000....).

상기 두 메시지는 포지셔닝 엔진의 증대된 명령어 큐(166)에 순차 기록된다.

acc2/sec1과 acc2/sec2는 동일한 값으로 2배 주어진다는 것은 명백하다. 이들 값을 처음(정확한 값) 수신할 때 그 값을 고려하고 나중에(대신에 메모리 복사를 재사용) 수신될 때 그 값을 폐기하는 것은 포지셔닝 엔진(154)의 담당이다.

포지셔닝의 결과는 다음과 같다:

인스턴스1로부터 먼저 오는 명령어를 처리(순서는 중요하지 않다)

결제 전 로컬 메모리(186) 내의 밸런스:

<Empty>

결제 후 메모리 내의 밸런스:

<acc1/sec1 > = 990(1000-10)

<acc2/sec1 > = 310(300 + 10)

<acc1/sec2> = 25500(25000 + 500)

<acc2/sec2> = 29500(30000 - 500)

인스턴스2로부터 오는 명령어를 처리

결제 전 메모리 내의 밸런스 (= 이전 명령어에 대한 결제 후 밸런스)

<acc1 /sec1 > = 990(1000-10)

<acc2/sec1 > = 310(300 + 10)

<acc1/sec2> = 25500(25000 + 500)

<acc2/sec2> = 29500 (30000 - 500)

결제 후 메모리 내의 밸런스

<acc1/sec1 > = 990 (unchanged)

<acc2/sec1 > = 330 (310 + 20 : 프리로더에 의해 주어진 값 300은 폐기된다)

<acc2/sec2> = 25500 (unchanged)

<acc2/sec2> = 28450 (29500-1050 : 프리로더에 의해 주어진 값은 폐기된다)

<acc3/sec1 > = 2980 (3000 - 20)

<acc3/sec2> = 6050 (5000 + 1050)

종국 큐(168)는 본 실시예의 중요한 부분이다. 이는 데이터베이스(24)의 명령어 결과 및 업데이팅의 실제 실시간 통보에 대한 규칙과 관련하여 주어진 명령어의 수용 여부에 대한 포지셔닝 엔진(154)의 결정을 디커플링하는 방식을 나타낸다. 이러한 디커플링은 포지셔닝 엔진(154)이 그 처리 작업을 최소화할 수 있도록 해주고, 따라서 그렇지 않은 경우보다 더 큰 처리량을 얻을 수 있도록 해준다.

포지셔닝 엔진(154)의 종국(스탬프는, 무슨 일이 있어도, 결제 명령어가 확인된다고 말하고 있다)은, 포지셔닝 엔진 업데이트를 마스터 데이터베이스(24)에 반영함으로써 아직 도달되지 않았고, 그러나 그 업데이트를 종국 큐(168) 내의 업데이트 실행 명령어에 로그함으로써 도달된다. 즉, 종국 명령어 레코드(업데이트 실행 명령어)는 디스패처(156)의 입력 큐인 종국 큐(168)에 기록된다. 이때, 원래의 처리 명령어는 최종인 것, 즉 실행된 것으로 간주된다. 명령어 당사자에게의 통지를 생성하고, 업데이트를 업데이터(158)의 여러 상이한 입력 큐(마스터 데이터 격리 큐(170)) 상에서 전파시키는 것은 디스패처(156)의 담당이다. 주요 목적은 작업의 동일한 논리 유닛 내에서, 데이터베이스 밸런스 업데이트와의 혼합 및 통보 활동을 피하는 것이다.

포지셔닝 엔진(154)에 의해 생성된 출력은 (하부의 명령어를 완료하기 위해 실시될 모든 마스터 데이터베이스 업데이트를 포함하는) 하나의 지속적인 메시지에 제한되기 때문에, 업데이트를 전파시키고 명령어 실행에 대한 요청 통보(예컨대, 실시간의 개별 명령어 취급 프로세스(162)에 대한 답신)를 생성하는 전용 프로세스가 디스패처(156)에 의해 제공된다. 입력에 수신된 하나의 메시지에 대하여, 디스패처(156)는 출력을 기록할 것이다(업데이트된 리소스 당 하나, 생성된 통보 당 하나). 전체 처리량 요구 조건을 다루기 위해, 이러한 디스패칭 로직은 병렬 구동된다. 디스패처(156)는 확장 가능하다(하나 이상의 프로그램 복사를 구동함으로써 처리량은 증대된다).

디스패처(156)에 의해 생성된 통보 메시지의 포맷은 단순히 구조화된 텍스트 메시지이다. 그러나, 이러한 포맷은 필요하다면 외부, 즉 ISO 포맷을 이용하기 위해 변경될 수 있다. 상기 디스패처는 또한 처리 세션 통보를 생성하도록 구성되는데, 상기 통보는 상기 처리 세션 중에 발생한 모든 트랜잭션을 리스팅하고 있으며, 포함된 각 당사자에 대한 리소스 계정 파일(30)의 값과 집합 리소스 값(32)에 미친 결과를 리스팅하고 있다.

상기 디스패처(156)는 어느 마스터 데이터 업데이터(190)에 명령을 하여 업데이트를 수행해야 하는지를 판단하지는 않는다. 대신에, 이것은 라우팅 프레임워크(175)에 대해 남겨져 있으며, 작업흐름 밸런스(176)를 이하에서 설명한다.

라우팅 프레임워크(175)는 작업흐름 밸런싱을 보조하기 위해 제공된다. 초기 입력 큐(164)로의 입력과, 마스터 격리 큐(170)로의 업데이터(158)를 향한 디스패처 프로그램(188)의 출력은 라우팅 프레임워크(175) 및 작업로드 밸런서(178)를 통해 전송된다. 디스패처 프로그램(188)은 명령어의 정확한 목적지(마스터 격리 큐(170))에 대한 지식 없이 명령어를 라우팅 프레임워크(175)로 전송한다. 라우팅 프레임워크(175)의 목적은 플랫폼 상에서 동시 동작하는 복수 개의 가능한 큐 중 어느 하나로의 특정 라우팅을 위해 명령어를 준비하는 것이다. 이 실시예에서, 라우팅 프레임워크는 복수의 초기 입력 큐(164) 중 어느 하나 또는 마스터 데이터 격리 큐(170) 중 어느 하나로의 라우팅을 위해 명령어를 준비한다. 라우팅 프레임워크(175)는 두 개의 기술적 필드, 즉 메시지 이름과 작업로드 밸런싱 키이를 추가한다. 메시지 이름은 메시지에 포함된 정보의 타입을 기술하며, 작업로드 밸런싱 키이는 명령어 ID에 할당되는데, 이는 두 개의 후속하는 실행 시도가 동일한 통보 시퀀스로 통보되어, "명령 결제"를 통보에 이어, 예컨대 시퀀싱 이슈로 인한 "명령어 실패"가 후속하는 것을 회피하는 것을 보장한다. 이는 내부 룩업 테이블(internal look up table)을 통해 수행된다.

라우팅 프레임워크(175)는 또한, 새로운 프로세스를 명령어 흐름에 추가하여, 프로세스 사이에서의 명령어 라우팅을 변화시키는 능력을 갖고 있다. 라우팅 프레임워크는 또한, 새로운 명령어를 명령어 흐름에 추가하고, 프로세스로부터 명령어의 전송을 억제하며, 필요하다면 명령어를 복제할 수도 있다. 메시지 이름과 작업로드 밸런싱 키이가 구비된 명령어는 후술하는 바와 같이, 작업흐름 밸런서(176)에 의해 다루어진다.

플랫폼(150)의 동작에서, 처리 명령어가 누구에게, 어느 포맷으로 그리고 (병렬 처리를 위해) 어느 인스턴스 상에서 전송되어야 하는지를 결정하는 것은 라우팅 프레임워크(175)의 담당이다. 라우팅 프레임워크(175)는, 한 명령어에 대한 통보가 동일 명령어에 대한 이전의 통보 후에 이루어지는 것을 보장하기 위해 이용된다. 예컨대, 명령어가 최종 수용되기 전에 몇 번 실패한 경우에, 그 처리 명령어가 성공적으로 실행되었다는 것을 통보하는 것은 동일 명령어(156)에 대한 실패한 결제 통보 메시지에 후속하여야 한다. 또한, 각 실패한 명령어의 통보는 순차적으로 전송되어, 명령을 한 당사자가 명령 실패에 정확히 반응할 수 있도록 해준다.

Example. 제1 명령어 처리 시도는 실패를 제공한다. 이유=>당사자 A의 리소스 계정의 레벨이 그 명령어를 지원할 만큼 충분하지 못하다(당사자 A는 일부 액션을 취할 수 있다). 다음에, 제2 명령어 처리 시도 역시 실패한다. 이유=> 당사자 B의 리소스 계정의 레벨이 그 명령어를 지원할 만큼 충분하지 않다(당사자 B는 일부 액션을 취할 수 있다). 이러한 것을 통보할 때, 당사자 A의 리소스 계정 실패 메시지에 후속하여 당사자 B의 리소스 계정 실패 메시지가 뒤따르도록 하는 것이 중요하다. 디스패처 모듈을 병렬로 구동하는 경우, 디스패처(156)의 동일한 인스터스 상에서 하나의 명령어에 대한 모든 통보를 전송하는 것(명령어 식별자 상에서의 작업로드 밸런싱)은 라우팅 프레임워크(175)의 담당이다.

작업로드 밸런서(176)는, 각 명령어를 독특하게 기술하기 위하여 처리 플랫폼(150)에 의해 함께 고려되는 명령어 이름과 밸런싱 키이(도시 생략)에 기반하여, 명령어의 최종 목적지를 결정한다. 상기 메시지 이름은 타겟 마스터 데이터 격리 큐(170)를 식별하는데 이용되는데, 이 큐는 다시 특정 마스터 데이터 업데이터(190)(각 마스터 데이터 업데이터(190)가 어떻게 특정 형태의 업데이트를 하게 되는지에 대해서는 이하의 설명 참조)를 공급한다. 상기 밸런싱 키이는 특정 인스턴스(마스터 데이터 격리 큐(170))를 컴퓨팅하는 데에 이용된다. 작업로드 밸런서(176)는 동일 키이에 대하여, 항상 동일한 인스턴스(마스터 데이터 격리 큐(170))를 선택하는 것을 보장해준다.

Example :

메시지 이름 = 'SECURIT_BALANCE_UPDAT' => Security balance updater

밸런싱 키이 = security id = 13

병렬 구동되는 시큐리티 업데이터의 총 개수 = 3

선택된 인스턴스 = 13 - (integer(13/3) * 3) + 1

= 13 - (4 * 3) + 1

= 13 - 12 + 1 = 2

=> 매번 업데이트는 security id 13에 대해 행해지고, 인스턴스 번호 2가 선택된다(메시지 라우팅).

각각의 마스터 데이터 격리 큐(170)는 단순히, 라우팅 프레임워크(175) 및 작업로드 밸런서(176)에 의해 상기 큐(170)에 특정적으로 라우팅된 명령어를 디스패처 프로그램(178)으로부터 수신한다. 각 마스터 데이터 격리 큐(170)는 특정 마스터 데이터 업데이터(190)와 관련되어 있는데, 이 업데이터는 다시 마스터 데이터베이스(24)의 특정 부분(24a, 24b, 24c) 상에서 동작한다.

업데이터(158)는 전적으로 마스터 데이터베이스(24)의 하나의 특정 파티션(24a, 24b, 24c)에서, 포지셔닝 엔진(156)에 의해 최종인 것으로 선언된 업데이트 명령어를 반영하도록 되어 있다. 각 마스터 데이터 업데이터(190)는 독특한 데이터베이스 파틴션과는 독립적으로 동작하고 있으므로, 다른 업데이팅 프로세스에 의해 생성된 임의의 잠재적 로킹에 의해 영향받지 않는다. 더욱이, 각 업데이터(190)는 오로지 그 업데이터가 관리하는 참조 데이터 셋트만을 업데이트하므로, 각 업데이터는 업데이트 명령어의 네팅(netting)을 수행할 수 있다. 업데이터의 각 인스턴스는 그 자신의 키이 범위(명령어가 라우팅되는 업데이터를 식별하기 위해 사용된다)에서 동작하여, 해당 키이가 마스터 데이터베이스의 특정 부분에 고립되어 있는지 여부를 판단한다.

업데이터(158)가 구체적으로 구현되는 방법과 관련하여 두 가지 실시예가 있다. 한 가지 실시예에서, 업데이트 명령어(업데이트)는 델타, 즉 계정 파일의 값의 변화에 의해 도큐먼트화된다. 다른 실시예에서, 업데이트는 리소스 계정 팡리의 마지막 값에 의해 도큐먼트화된다. 이들 두 실시예를 이하에서 설명하는데, 네팅이 수행되는 방식을 달성한다.

업데이트가 델타에 의해 도큐먼트화되면, 마스터 데이터 업데이터(190)에 의해 실시되는 네팅 알고리듬(도시 생략)은 주어진 리소스 계정 파일(30)로의 싱글 업데이트를 실행하기 전에, 그 리소스 계정 파일(30)에 대한 각 명령어의 이동을 요약하는 것을 포함한다. 업데이트가 마지막 값에 의해 도큐먼트화되면, 네팅 프로세스는 그 값이 더 큰 업데이트 타임스탬프를 갖도록 하고, 업데이트 진술서의 "where" 절(이하의 예 참조)에 그 타임스탬프 유효성을 추가하는 것을 포함한다.

구체적으로, 마지막 값 모델에서, 네팅 프로세스는 마지막 업데이트를 포지셔닝 엔진(154)에 의해 수행하려고 한다. 업데이트 시퀀스가 보장되지 않음에 따라, 네팅 알고리듬은 12:45:03에서 마지막 값을 이미 수신한 후에 12:45:01에서 마지막 값을 수신할 수 있다. 업데이트를 실시하기 위해, 12:45:03에서의 마지막 값만이 참작되어야 한다. 물론, 12:45:06에서의 마지막 값이 이미 데이터베이스에 반영되어 있다면, 12:45:03에서의 값은 무시되어야 한다. 이는 마스터 데이터를 이하에서와 같이 업데이트할 때 타임스탬프를 이용하여 행해질 수 있다.

EXEC SQL UPDATE PP_SEC_BAL

SET BALANCE_VALUE = Last value received in input,

Balance timestamp = Last value positioning timestamp

Where Balance ID = Balance id from the update request AND

Balance Timestamp (in DB) < Last value positioning timestamp

업데이터에 의해 수신된 업데이트 메시지는 최종의 것(어떤 식으로든지 적용된다)이다. 이것은 동일 키이에 대한 두 후속 업데이트 명령어가 마스터 데이터 업데이터(190)에 의해 단일의 물리적 업데이트로 번역되도록 메시지가 함께 그룹화될 수 있다는 것을 의미한다.

마지막 값 실시예와 델타 값 실시예가 어떻게 동작하는 가를 보여주는 예를 이하에서 설명한다.

Example for Last Value

업데이터는 다음의 입력을 순차적으로 수신한다:

Balancel 10000 2007-08-01 -09.01.01.112335 (time in micro seconds)

Balancel 12500 2007-08-01 -09.01.02.100475

Balancel 25000 2007-08-01 -09.01.01.875221

Balancel 12500 2007-08-01 -09.01.02.077054

마스터 데이터 업데이터(190)는 모든 업데이트를 순차적으로 검색한다.

첫 번째 것에 대하여, 값을 유지한다(처음에, 밸런스는 작업의 동시적 노리 유닛에서 참조된다)

두 번째 것에 대하여, 이전의 값을 메모리 내에 덮어쓴다(리퀘스트는 향후 첫번째 것과 비교된다).

세 번째 것에 대하여, 그것을 폐기하는데, 왜냐하면 두 번째 값 전에 리퀘스트가 생성되었기 때문이다

네 번째 것에 대하여, 그것을 폐기하는데, 왜냐하면 두 번째 값 전에 리퀘스트가 생성되었기 때문이다.

commit time(commit freqeuncy)에서, 물리적 업데이트가 생성된다:

EXEC SQL UPDATE SET Balance value = 12500, Timestamp = 2007-08-01 - 09.01.02.100475

여기서, balance id = balance 1 and Timestamp < 2007-08-01-09.01 .02.100475

타임스탬프 조건은, 데이터베이스 내의 이미지가 이미, 제안된 것과 향후 비교된다면, 업데이트 리퀘스트를 중단시킬(abort) 것이다.

Example for Delta

마스터 데이터 업데이터(190)는 다음의 입력을 순차적으로 수신한다:

Balance1 10000 2007-08-01-09.01.01.112335 {time in micro second)

Balance1 12500 2007-08-01-09.01.02.100475

Balance1 25000 2007-08-01-09.01.01.875221

Balance1 12500 2007-08-01-09.01.02.077054

마스터 데이터 업데이터(190)는 모든 업데이트를 순차적으로 검색한다.

첫 번째 것에 대하여, 그 값을 유지한다(처음에, 밸런스는 작업의 동시적 노리 유닛에서 참조된다)

두 번째 것에 대하여, 델타 10000을 추가한다(delta 10000+12500=22500)

세 번째 것에 대하여, 델타 22500을 추가한다(delta 22500+25000=47500)

네 번째 것에 대하여, 델타 47500을 추가한다(delta 47500+12500=60000)

commit time(commit freqeuncy)에서, 물리적 업데이트가 생성된다:

EXEC SQL UPDATE SET Balance value = Balance value + 60000

여기서, balance id = balance1

페이싱 모듈(174)에 의해 큐가 보통 비어 있도록 하는 것은, 플랫폼을 통한 명령어의 흐름 상에서 수행되는 유일한 제어는 아니다. 실시간 처리 중에, 구분자 프레임워크(178)는 처리 세션의 종료 전에 수행된 모든 업데이트가 정확하게 마스터 데이터베이스(24)에 반영되어, 디스패처(156)에서 활동을 통보하는 처리 세션의 끝을 시작할 수 있도록 한다.

업데이트 실행 명령어를 종국 큐(168)에 기록하는 것은, 마스터 데이터베이스 업데이트가 아직 실행되지 않았더라도, 플랫폼(150)에 의해 명령어의 최종 실행인 것으로 고려될 수 있다. 그러나, 기술적 관점에서, 업데이트 실행 명령어가 실제, 마스터 데이터베이스 리소스 계정(30)의 값에 의존하기 전에 마스터 데이터베이스(24) 내에서 실행되는 것이 필요하다.

이러한 목적을 달성하기 위해, 구분자 프레임워크(178)는 리퀘스트/답신 메시지를 종국 큐의 상단에 기록하는 기본적인 기능을 제공한다. 답신이 수신되면, 이는 종국 큐에 이전에 기록된 모든 명령어가 실행되었다는 것을 의미한다.

플랫폼(150) 내에서의 명령어 처리 흐름은 순차적으로 실행된 프로세스들의 셋트 상에서 구성된다. 특히, 마스터 데이터 격리 큐(170)는 업데이트 실행 명령어가 종국 큐(168)를 통과한 후에만 업데이트 실행 명령어를 다룬다. 따라서, 답신이 종국 큐로부터 수신되자마자, 새로운 리퀘스트/답신 메시지가 순서상 다음 큐, 즉 마스터 데이터 격리 큐(170)로 전송된다. 각 큐는 FIFO 시퀀싱을 동작시킨다.

구분자 프레임워크(178)의 기능은 마스터 데이터베이스가 그 데이터베이스 내에 정확한 업데이트된 데이터를 갖고 있다는 것을 체크하는 것이 아니라, 모든 업데이트 실행 명령어가 순서대로 실행되었는지를 체크하는 것이며, 이러한 체크는 시스템의 상이한 처리 스테이지를 통해 순차적으로 실행된다.

병렬성이 구현되면, 프로세스는 복수의 큐 상에서 병렬로 구동될 수 있다. 모든 큐가 그 백로그를 처리하였다는 것을 확실히 하기 위하여, 리퀘스트/답신 메시지는 그 큐 중 하나뿐만 아니라 모든 큐에 기록되어야 한다. 메시지가 프로세스의 n개의 인스턴스에 전송되어야 한다는 것을 검출하는 것은 라우팅 프레임워크(175)의 담당이고, 다음 프로세스를 구분하기 전에 n개의 답신이 수신될 때까지 대기하는 것은 구분자 프레임워크의 담당이다.

다음의 예는 구분자 프레임워크(178)가, 처리 세션의 종료 후에 업데이터(158)에 의해 업데이트 실행 명령어의 실행을 보장하도록 어떻게 동작하는 가를 보여준다.

Example :

특정 시간에서, 예컨대 4PM에서, 플랫폼(150)은 명령어를 실행하기 위한 데드라인을 규정한다. 데드라인에 도달하자마자, 처리 세션 활동에 관심 있는 당사자에게 전송될 순차적인 통보 파일을 구축하기 위하여, 실행된 모든 명령어를 마스터 데이터베이스에 추출하는 통보 프로세스가 이루어진다.

4PM에서, 스케줄러는 통보 프로세스를 시작한다.

프로세스의 제1 단계로서, 구분자 커넬(delimiter kernel)(도시하지 않았지만 구분자 프레임워크(178)의 일부이다)에게 구분자 메시지를 생성하여 전송하기 위해 구분자 유틸리티(도시하지 않았지만, 구분자 프레임워크(178)의 일부이다)가 이용된다. 수신된 메시지에 기초하여, 구분자 커넬은, 포지셔닝 엔진(154)에 의해 최종인 것으로 선언된 모든 업데이트가 마스터 데이터베이스(디스패처(188) 및 업데이터(190))에 반영되도록 하기 위하여, 구분되는 여러 상이한 프로세스에 메시지를 작성하는 것을 시작한다.

통보 프로세스의 두 번째 단계로서, 구분자 완료 체크 유틸리티(도시하지 않았지만, 구분자 프레임워크(178)의 일부이다)가 실행된다. 이는, 구분자 프로세스가 구분자 커넬에 의해 완료된 것으로 선언될 때까지 통보 프로세스를 계속 유지한다. 이것이 행해지면, 통보 프로세스의 실행은 다음 단계에서 재개된다.

통보 프로세스의 제3 단계로서, 디스패처(188) 내의 통보 작업 로직(reporting business logic)이 마스터 데이터 내에 포함된 정확한 데이터에 기초하여 실행된다.

추출 통보 작업은 구분자 프레임워크(178)에게, 4PM 데드라인 전에 도달한 업데이트 실행 명령어가 통보 목적을 위해 디스패처(158)에 의해 처리되고, 그 명령어가 또한 마스터 데이터베이스(24)에 적용되는 것을 보장할 것을 요구한다. 이것이 행해지면, 마스터 데이터베이스(24) 스테이터스는 데드라인 전에 확인된 모든 활동을 반영하고, 추출 통보는 상기한 바와 같이 정확히 생성될 수 있다.

도 8 내지 도 12의 실시예와 관련하여 상기한 특징은 첨부한 청구항에 기재되어 있다. 상기한 특징의 하위 특징을 이용하여 본 발명의 추가 실시예를 고안할 수 있다는 것을 이해하여야 한다. 예컨대, 추가의 실시예는 상기한 리사이클링 특징을 이용하지 않고, 공지의 다른 것을 이용할 수 있다. 유사하게, 상기 페이싱 모듈은 다른 솔루션을 제공하도록 수정 또는 제거될 수 있다. 그러나, 대안적인 데이터 처리 구조의 선택시, 처리량에 미치는 영향을 고려하여야 한다. 본 경우에, 청구항 처리 구조는 가능한 최상의 처리량을 제공하는 최적의 구조이다. 페이싱 모듈과 같은 특징은 간단하게 처리량을 증대시킨다.

본 발명의 특정 실시예를 설명하였지만, 당해 실시예는 예시적인 것이고, 당업자는 첨부한 청구항에 개시된 본 발명의 사상 및 범위를 벗어나지 않으면서 여러 변형 및 수정을 할 수 있다는 것을 이해하여야 한다.

Claims (27)

1. 처리 세션 중에 매우 많은 수의 처리 명령어를 실시간으로 처리하고 다루기 위한 시스템으로서, 각각의 처리 명령어는 리소스 계정 데이터 파일을 특정하며, 상기 데이터 파일은 두 상이한 당사자 및 두 데이터 파일 사이에서 교환되는 리소스의 양 및 타입과 관련되며, 상기 시스템은,
   복수 개의 프리로더로서, 각 프리로더는 상기 명령어와 관련된 참조 데이터를 얻도록 구성되며, 상기 참조 데이터는 특정된 각 리소스 계정 데이터 파일의 현재 값을 나타내며, 상기 복수 개의 프리로더는 복수 개의 각 수신된 명령어에 대하여 마스터 데이터베이스로부터 상기 참조 데이터를 읽도록 병렬 동작하게 구성되어 있는 것인, 상기 복수 개의 프리로더와;
   각 프리로드된 참조 데이터와 함께 복수 개의 처리 명령어를 큐잉하기 위한 인리치 명령어 큐와;
   상기 수신된 참조 데이터를 이용하여, 각각의 수신된 명령어가 관련 리소스 계정 파일의 현재 값 하에서 실행될 수 있는지, 각각의 실행 가능한 명령어가 업데이팅 커맨드를 생성할 수 있는지를 순차적으로 결정하도록 구성된 실행 엔진과;
   상기 실행 엔진으로부터의 업데이팅 커맨드에 응답하여, 각 실행 가능한 명령어의 결과로 상기 마스터 테이터베이스를 업데이트하는 복수 개의 업데이터
   를 포함하고, 상기 업데이터의 동작은 상기 실행 엔진의 동작과는 디커플링되어 있는 것을 특징으로 하는 시스템.
2. 청구항 1에 있어서, 복수 개의 상이한 소스로부터 실시간 명령어 및 배치 명령어를 수신하도록 구성되고, 상기 복수 개의 프리로더에 대한 입력을 위해 상기 명령어를 큐 하도록 되어 있는 초기 입력 큐를 더 포함하는 시스템.
3. 청구항 2에 있어서, 상기 초기 입력 큐는 복수 개의 초기 입력 큐를 포함하며, 각각의 큐는 상기 복수 개의 프리로더 중 대응하는 하나의 프리로더에 전용의 입력을 제공하도록 구성되는 것인 시스템.
4. 청구항 2 또는 청구항 3에 있어서, 상기 초기 입력 큐는 각각의 들어오는 명령어에 우선 순위를 할당하도록 구성되는 것인 시스템.
5. 청구항 1 내지 청구항 4 중 어느 한 항에 있어서, 상기 실행 엔진에서 저장되고, 상기 업데이트된 리소스 계정 파일 각각의 업데이트된 실시간 값의 표현이 얻어지도록 상기 리소스 계정 파일 상에서 실행된 명령어의 결과로 업데이트되도록 구성되어 있는 현재 조건 테이블을 더 포함하고, 상기 실행 엔진은, 명령어의 후속되는 순차 처리를 위해, 특정 리소스 계정 파일에 대한 프리로더로부터의 참조 정보에 우선하여, 상기 현재 조건 테이블 내의 정보를 이용하도록 구성되는 것인 시스템.
6. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서, 각 프리로더는 마스터 데이터 콜렉터를 포함하며, 각 마스터 데이터 콜렉터는 상기 명령어에서 식별된 리소스 계정 파일의 값과, 집합 리소스 값을 상기 마스터 데이터베이스로부터 읽도록 구성되며, 상기 마스터 데이터베이스로부터 읽은 데이터를 포함하는 인리치 처리 명령어를 컴파일 및 출력하도록 구성되는 것인 시스템.
7. 청구항 1 내지 청구항 6 중 어느 한 항에 있어서, 상기 실행 엔진은 상기 현재 조건 테이블을 저장하기 위한 고속의 로컬 데이터 메모리를 포함하는 것인 시스템.
8. 청구항 1 내지 청구항 7 중 어느 한 항에 있어서, 상기 실행 엔진은 저장되어 있는 미리규정된 규칙의 셋트를 참조함으로써, 현재의 명령어가 관련 리소스 계정 파일의 현재 값 하에서 실행될 수 있는지 여부를 판단하도록 구성되는 것인 시스템.
9. 청구항 1 내지 청구항 8 중 어느 한 항에 있어서, 상기 실행 엔진은 타임-스탬핑 모듈을 포함하고, 이 모듈은 상기 처리 명령어 중 하나의 수신 시간을 결정하고, 타임스탬프를 생성하여 처리 명령어에 적용하도록 구성되는 것인 시스템.
10. 청구항 1 내지 청구항 9 중 어느 한 항에 있어서, 상기 실행 엔진은 실패한 처리 명령어 리스트를 고속 로컬 데이터 스토어에 저장하고, 그 실패한 처리 명령어에 의해 식별된 리소스 계정 파일 내에서 업데이트가 발생한 후에, 상기 실패한 처리 명령어가 재실행을 위해 제공되는 리사이클링 과정을 실행하기 위한 리사이클링 모듈을 포함하는 것인 시스템.
11. 청구항 10에 있어서, 상기 리사이클링 모듈은 상기 실패한 명령어를 그 우선 순위의 순서로 저장하고, 상기 리사이클링 과정 중에, 재실행을 위해 가장 높은 우선 순위의 명령어를 먼저 제공하도록 구성되는 것인 시스템.
12. 청구항 10 또는 청구항 11에 있어서, 상기 리사이클링 모듈은 명령어에 대한 리소스 계정 파일의 현재 값을 상기 리스트에 보유하고, 이 보유된 양을 상기 리사이클링 과정 중에 명령어의 요구 조건을 이행할 때 이용하도록 구성되는 것인 시스템.
13. 청구항 10 내지 청구항 12 중 어느 한 항에 있어서, 상기 리사이클링 모듈은 미리 정한 최대 횟수만큼 재실행을 위해, 실패한 처리 명령어를 제공하도록 구성되고, 처리 명령어가 여전히 실행되지 않은 경우, 상기 리사이클링 모듈은 그 실패한 명령어를 취소하도록 구성되는 것인 시스템.
14. 청구항 1 내지 청구항 13 중 어느 한 항에 있어서, 상기 실행 엔진은 수신된 명령어의 실행의 결과를 통보하기 위한 통보 모듈을 포함하고, 상기 통보 모듈은 실행될 수 있다고 결정된 각 명령어에 대한 업데이트 명령어, 각 실패한 명령어에 대한 통지 명령어를 출력하도록 구성되는 것인 시스템.
15. 청구항 14에 있어서, 상기 통보 모듈은 commit 이벤트가 발생할 때까지 복수 개의 업데이팅 커맨드를 일시적으로 저장하도록 구성되고, commit 이벤트의 발생시 상기 저장된 복수 개의 업데이팅 커맨드를 출력하도록 구성되며, 상기 commit 이벤트는 상기 실행 엔진에 의한 작업의 한 물리적 단위의 완료를 나타내는 것인 시스템.
16. 청구항 1 내지 청구항 15 중 어느 한 항에 있어서, 상기 통보 모듈로부터의 통지 명령어 및 업데이트 명령어를 수신하여 큐 하도록 구성된 종국 큐를 더 포함하는 시스템.
17. 청구항 1 내지 청구항 16 중 어느 한 항에 있어서, 각각의 업데이터는 병렬동작하는 복수 개의 업데이팅 인스턴스를 포함하고, 각 인스턴스는 상기 마스터 데이터베이스의 독특한 부분 상에서 동작하는 것인 시스템.
18. 청구항 17에 있어서, 각 업데이팅 인스턴스에 대해 격리 입력 큐를 더 포함하고, 각 격리 큐는, 대응 업데이팅 인스턴스에 의해 업데이트된 마스터 데이터베이스의 특정 부분에 관련된 복수 개의 업데이팅 커맨드를 수신하도록 구성되는 것인 시스템.
19. 청구항 18에 있어서, 각 격리 입력 큐는 업데이팅 커맨드가 상기 동일한 참조 계정 파일과 관련되는 경우 상기 업데이팅 커맨드를 네팅하도록 구성되는 것인 시스템.
20. 청구항 18 또는 청구항 19에 있어서, 특정 격리 큐로의 각 업데이팅 커맨드의 라우팅을 결정하고, 실행 명령어의 실패 또는 성공이 기술되는 통보 메시지를 상이한 당사자에 대해 생성하도록 구성되는 디스패처 모듈을 더 포함하는 시스템.
21. 청구항 3을 인용하는 청구항 18 내지 청구항 20 중 어느 한 항에 있어서, 라우팅 프레임워크를 더 포함하고, 상기 라우팅 프레임워크는 동시에 동작하는 복수 개의 초기 입력 큐 또는 격리 입력 큐에 명령어를 분배하도록 구성되는 것인 시스템.
22. 청구항 21에 있어서, 상기 라우팅 프레임워크는 명령어가 관련된 정보의 타입을 기술하는 명령어 이름과, 상기 명령어를 식별하는 독특한 키이를 제공하는 작업로드 밸런서 키이를 상기 명령어에 할당하도록 구성되는 것인 시스템.
23. 청구항 22에 있어서, 상기 라우팅 프레임워크는 작업로드 밸런서를 포함하고, 이 밸런서는 라우팅 프레임워크와 조합하여, 상기 수신된 명령어 이름과 작업로드 밸런서 키이를 이용하여, 상기 복수 개의 초기 입력 큐 또는 격리 입력 큐 중 하나를 선택하도록 구성되는 것인 시스템.
24. 청구항 20을 인용하는 청구항 23에 있어서, 상기 작업로드 밸런서는 주어진 작업로드 밸런서 키이를 동일한 특정 목적지에 링크하여, 특정 리소스 계정 데이터 파일과 관련된 모든 명령어가 항상 복수 개의 큐 중 동일한 하나의 큐에 라우팅되도록 구성되는 것인 시스템.
25. 청구항 1 내지 청구항 24 중 어느 한 항에 있어서, 구분자 프레임워크를 더 포함하며, 이는 주어진 시간에서 상기 처리 세션이 닫혀지는 것에 응답하여, 상기 실행 엔진의 출력에 주어진 큐의 입력에 메시지를 전송하고, 그 응답을 대기하며, 추가의 메시지를 복수 개의 업데이터 중 하나의 입력 큐에 전송하고 그 응답을 기다리도록 구성되며, 상기 순차적 응답의 수신은 상기 처리 세션이 닫혀지기 전에 실행된 모든 처리 명령어의 결과로 상기 마스터 데이터베이스의 업데이트를 나타내는 것인 시스템.
26. 청구항 20을 인용하는 청구항 25에 있어서, 상기 구분자 프레임워크는 또한, 상기 디스패처 모듈의 입력 큐에 메시지를 전송하고, 상기 처리 세션이 닫혀지기 전에 실행된 처리 명령어에 대한 통보 메시지가 모두 전송되었다는 것을 확인해 주는 응답 피드백을 기다리도록 구성되는 것인 시스템.
27. 청구항 1 내지 청구항 26 중 어느 한 항에 있어서, 상기 실행 엔진의 처리 명령어 처리량을 결정하고, 대기 상태를 임의의 큐에 적용하여 처리 명령어의 로딩 속도를 상기 실행 엔진의 처리량 미만으로 저하시키기 위한 페이싱 모듈을 더 포함하는 시스템.

Images