KR101315330B1

KR101315330B1 - 대용량 데이터베이스와 인터페이스하기 위한 다 계층소프트웨어 시스템에서 캐쉬 콘텐츠의 일관성을 유지하는시스템 및 방법

Info

Publication number: KR101315330B1
Application number: KR1020087010801A
Authority: KR
Inventors: 브누와 쟈넹; 헤미 골르; 뤽 이스나르디; 뤼디 다니엘로; 바인 뤼방스타인
Original assignee: 아마데우스 에스.에이.에스.
Priority date: 2005-10-03
Filing date: 2006-09-27
Publication date: 2013-10-08
Also published as: EP2169909B1; ES2363796T3; JP2009510578A; CN101278540B; EP1770954A1; BRPI0616685A2; EP1932322B1; US20080235292A1; EP1932322A1; AU2006298750A1; WO2007039535A1; US8364650B2; CN101278540A; ES2391157T3; PL2169909T3; JP5080478B2; EP2169909A1; CA2621756A1; DE602006020892D1; ZA200802801B

Abstract

다 계층화된 서버 구조에서 캐쉬 콘텐츠의 일관성을 유지하는 방법 및 시스템이 기술된다. 이것은 로컬 캐쉬를 각각 운영하는 위성 서버의 전방 계층, 및 중앙 캐쉬를 각각 운영하는 중앙 서버의 중간 계층을 포함한다. 중앙 서버는 객체를 작성하는데 사용되는 데이터 요소를 회수하기 위해 데이터베이스 서버를 통해 데이터베이스와 인터페이스하며, 객체를 중앙 캐쉬에 저장한다. 일단 작성되면, 객체는 유지시간(TTL)을 부여받고 중앙 캐쉬에 저장되며, 객체를 요청했던 소프트웨어 애플리케이션으로 전송되기 전에 객체가 로컬 캐쉬에 저장되는 위성 서버로 포워드된다. 객체는 오래되면 무효화되고, 중앙 서버로부터 재작성되어 모든 중앙 캐쉬 및 객체를 필요로 하는 로컬 캐쉬로 포워드된다.

다 계층 구조, 캐쉬 콘텐츠 일관성, 중앙 데이터 서버, 객체 재작성.

Description

대용량 데이터베이스와 인터페이스하기 위한 다 계층 소프트웨어 시스템에서 캐쉬 콘텐츠의 일관성을 유지하는 시스템 및 방법{SYSTEM AND METHOD TO MAINTAIN COHERENCE OF CACHE CONTENTS IN A MULTI-TIER SOFTWARE SYSTEM AIMED AT INTERFACING LARGE DATABASES}

본 발명은 일반적으로 다 계층(multi-tier) 클라이언트/서버 소프트웨어 구조(architecture)에 관한 것으로, 더 상세하게는 전반적인 성능을 개선하기 위해 전방 및 중간 계층 장치에서 실행되는 캐쉬 콘텐츠 사이의 일관성을 유지하는 방법 및 시스템에 관한 것이다.

1980년대 후반에 나타난 클라이언트/서버 모델은 그 당시 표준이었던 시분할 방식 집중형 메인프레임(centralized mainframe, time sharing computing)과 비교할 때, 유용성, 융통성, 상호 운용성, 범위성(scalability)을 개선하기 위한 다기능 및 모듈러 소프트웨어 구조이다. 클라이언트는 서비스의 요청자이고 서버는 그러한 서비스의 공급자이다. 소프트웨어 구성에 따라, 동일한 장치가 클라이언트와 서버 모두가 될 수 있다.

클라이언트/서버 구조는 모든 지능이 중앙 호스트 컴퓨터 내에 있고 사용자가 단지 키스트로크를 캡처하고 그 정보를 호스트에 전송하는 덤 터미널을 통해 호스트와 상호작용하는 앞의 메인프레임 소프트웨어 구조를 점진적으로 대체하고 있다. 잘 알려진 메인프레임 소프트웨어 구조의 한계는 그것이 그래픽 유저 인터페이스(GUI) 또는 지리적으로 분산된 지점으로부터 다중 데이터베이스에 액세스를 용이하게 지원하지 않는다는 것이다. 그러나 메인프레임은 여전히 분산형 클라이언트/서버 구조에서 강력한 서버로 사용된다.

클라이언트/서버 구조는 파일 서버 역할을 하는 데이터베이스 서버를 도입한다. 이 구조에서, 사용자 조회는 관계형 데이터베이스 관리 시스템(RDBMS)을 이용하여 직접 응답된다. 네트워크 트래픽은 항상 완전한 파일을 전송하기 보다는 조회 응답을 제공함으로써 줄어든다. 그것은 또한 GUI 전단을 통해 공유 데이터베이스로 다 사용자 업데이트(multi-user update)를 개선한다. 클라이언트/서버 구조에서는 클라이언트와 서버 사이의 데이터 교환을 위해 일반적으로 구조화 조회 언어(SQL) 문장이 사용된다.

도 1에 도시된 두 계층 클라이언트/서버 구조(100)에서, 사용자 시스템 인터페이스는 사용자의 데스크탑(102) 환경에 위치하고 데이터베이스 관리 서비스는 많은 클라이언트에게 서비스할 수 있는 서버(104)에 위치한다. 프로세싱 관리는 사용자 시스템 인터페이스 환경과 데이터베이스 관리 서버 환경 사이에서 분할된다. 주로 구내 정보 통신망(LAN)(108)에서 단일/다중 서버(도시되지 않음)와 인터페이스하는 단일/다중 클라이언트를 포함하는 망 형태의 모든 결합도 명백히 가능하다.

전통적인 두 계층 구조에서는, 제1 계층인 클라이언트(102)가 사용자 인터페이스, 메인 비지니스 및 데이터 프로세싱 로직을 보유한다. 제1 계층은 사용자 입력의 구문을 채택 및 체크하고, 애플리케이션 로직을 처리하며, 데이터베이스 요청(request)을 발생시켜 그것들을 서버로 전송하며, 응답을 사용자 태스크로 다시 보낸다. 제2 계층인 데이터베이스 서버(104)는 클라이언트로부터의 데이터베이스 요청을 채택 및 처리하고, 인가를 체크하며, 통합성 제약(integrity constraint)이 위반되지 않게 보장하고, 조회/업데이트 처리를 수행하며, 응답을 클라이언트에게 전송한다. 또한, 제2 계층은 시스템 목록을 유지하고, 병행 데이터베이스 액세스를 제공하며, 복구 제어를 수행한다.

두 계층 클라이언트/서버 구조는 LAN에서 동시에 상호작용하는 작업 그룹이 100명을 초과하지 않을 때 분산 컴퓨팅을 위한 뛰어난 솔루션이라고 증명되었다. 그러나, 사용자의 숫자가 늘어날 때, 아무런 작업이 행해지지 않는데도 "연결 유지" 메시지를 통해 각 클라이언트와의 접속을 유지하는 서버로 인해 성능은 악화되기 시작한다. 두 계층 구조의 두 번째 한계는 공급자 소유 데이터베이스(vendor proprietary database) 절차를 사용하는 프로세싱 관리 서비스의 실행이 융통성과 애플리케이션을 위한 RDBMS의 선택을 제한한다는 것이다. 또한, 두 계층 구조는 프로그램 기능성을 서버로부터 다른 서버로 이동(분배)시키는데 있어 융통성이 제한되는 수단임이 증명되었다.

이후, 1990년대에 이르러 상기 한계를 극복하기 위해 세 계층 구조(120) 및 다 계층 변형체가 나타났다. 세 계층 구조에서는 사용자 시스템 인터페이스 클라이 언트 환경(122)과 데이터베이스 관리 서버 환경(124) 사이에 중간 계층(126)이 더해진다. 상기 구조와 중간 계층을 구현하는 방식은 다양하지만, 이 중간 계층은 주로 대기(queue), 애플리케이션 이행, 및 데이터베이스 스테이징(staging)을 담당한다. 일반적으로, 중간 계층은 데이터를 액세스하고 그 대답을 클라이언트에게 돌려보내기 때문에, 클라이언트는 그 요청을 중간층에 전송하고 접속을 끊는다. 또한, 중간층은 진행중인 작업을 위한 스케쥴링(scheduling)과 우선순위 선정(prioritization) 기능을 더한다.

위의 세 계층 구조의 변형체에서는, 클라이언트인 제1 계층이 단지 사용자 인터페이스 역할, 즉 입력을 검증하는 역할만을 수행할 수도 있다; 이 경우 서버인 제3 계층이 데이터 검증(data validation)을 실행하고 데이터베이스 액세스를 제어하는 동안, 중간 계층은 모든 비지니스 로직(business logic)을 보유하고 데이터 처리를 한다.

세 계층 클라이언트/서버 구조는 많은 수의 사용자(일반적으로 천 명까지, 즉 두 계층 구조의 10배)가 있는 그룹에 대한 성능을 개선하는 것으로 알려져 있고, 특히 애플리케이션 코드가 층 사이에서 공유될 필요가 없어 두 계층 접근법과 비교할 때 융통성을 개선한다. 세 계층 클라이언트/서버 구조는 서버에 클라이언트가 직접 접속되는 두 계층 구조보다 상당히 더 범위성이 있는(scalable) 환경을 갖는다. 이 구조는 다양한 별개의 RDBMS를 단일 트랜잭션으로 업데이트하는 능력을 제공하고, 플랫 파일(flat file), 비 관계형 데이터베이스 관리 시스템을 포함하는 다양한 데이터 소스 및 최근 강력한 데이터베이스 서버로 자주 사용되는 메인프레 임에도 접속할 수 있다. 세 계층 및 다 계층 구조는 이처럼 다수의 분산형 클라이언트/서버 환경에 가장 적합하다. 예를 들면, 항공 예약 회사들이 그들의 고객(즉, 이종의 데이터베이스(즉, 항공기 요금 및 이용가능성 데이터베이스) 및 프로세싱 규칙과 같은 공유되는 리소스가 필요한 전세계의 여행사)에게 제공되도록 배포해야 하는 것들.

다 계층 데이터 센터(data-center)가 이러한 서비스를 제공하는데 있어 핵심적인 요건이라면, 계산과 통신 오버헤드를 줄이는 것은 성능과 범위성을 더욱 개선하는데 있어 중요하다. 더 많은 고객이 동시에 제공될 수 있도록 하기 위해, 동적 콘텐츠(dynamic content)를 다 계층 데이터 센터의 다양한 계층에 캐싱(caching)하는 것은, 적중(hit)의 경우에 데이터가 상부 계층으로부터 다시 인출(fetch)될 필요가 없으므로 계산과 통신 오버헤드를 줄일 수 있는 잘 알려진 방법이다. 그러나, 중간 계층과 전방 계층에 캐싱하는 것은 그 자체로 문제점이 있다. 캐쉬 일치성(consistency) 및 캐쉬 일관성(coherence)이 이에 따라 다루어져야 할 문제의 핵심이다. 특히, 오래된 항공기 이용가능 값이 용인되지 않는 항공기 예약 분야에서는, 강한 일치성과 일관성이 필수적이다.

따라서, 본 발명의 일반적인 목적은 다 계층 소프트웨어 구조에서 동적인 캐쉬 콘텐츠의 일관성을 유지하는 방법 및 시스템을 제공하는 것이다.

본 발명의 더 상세한 목적은 이러한 방법 및 시스템이, 항공기 예약 시스템을 위해 배포되고, 클라이언트 측으로부터의 매우 높은 레벨의 트랜잭션(transaction) 및 항공 회사와 이러한 서비스의 다른 제공자가 제공하는 요금과 이용가능성 데이터베이스의 매우 빈번한 업데이트로 특징되는 구조와 같은 다 계층 구조에 적합하게 하는 것이다.

본 발명의 또 다른 목적, 특징, 및 장점은 첨부한 도면에 관한 아래의 설명을 검토함에 따라 당해 기술분야에서 통상의 지식을 가진 자에게 명백해질 것이다. 추가적인 장점들도 여기에서 구체화될 것이다.

다 계층 소프트웨어 구조에서 캐쉬 콘텐츠의 일관성을 유지하는 방법 및 시스템에 대하여 설명한다. 이것은 각각 로컬 캐쉬를 운영하는 위성 서버의 전방 계층, 및 각각 중앙 캐쉬를 운영하는 중앙 서버의 중간 계층을 포함한다. 중앙 서버는 객체(object)를 작성(construct)하는데 사용되는 데이터 요소를 회수(retrieve)하기 위해, 데이터베이스 서버를 통해 데이터베이스와 인터페이스한다. 일단 작성되면, 객체는 유지시간(TTL)이 부여되고 중앙 캐쉬에 저장되며, 객체를 요청(request)했던 소프트웨어 애플리케이션에 전송되기 전에 객체가 로컬 캐쉬에 저장되는 장소인 위성 서버로 포워드된다. 위성 서버로부터의 요청은 모든 이용가능한 중앙 서버에 부하 균형(load balance)된다. 요청마다 이를 다루는 하나의 중앙 서버가 선택된다. 새롭게 작성된 객체는 상기 선택된 중앙 서버로부터 모든 다른 중앙 서버에 복제된다. 객체가 로컬 캐쉬에서 부적중(miss)이거나 오래되었다면(outdated), 객체는 선택된 중앙 캐쉬로부터 요청된다. 요청된 객체가 선택된 중앙 캐쉬에서 부적중이라면, 선택된 중앙 서버에서 요청된 객체의 작성이 일어난다. 요청된 객체가 중앙 캐쉬에 이미 존재하고 오래되지 않았다면 작성이 생략(skip)된다. 하나의 중앙 서버는 메인 중앙 서버로 지정되고, 모든 다른 중앙 서버들은 백업 중앙 서버로 지정된다. 요청된 객체가 오래되었다고 판명되면, 메인 중앙 서버에서 무효화 조정기(invalidation handler)로부터 작성이 일어난다. 오래되었다고 판명된 객체의 TTL은 요청한 위성 서버로 포워드되기 전에 낮은 값으로 맞추어진다. 중앙 캐쉬 및 로컬 캐쉬에 저장된 객체들을 작성하는데 사용되는 하나 이상의 데이터 요소가, 어떤 객체들이 충돌(impact)되는지 측정하여 모든 중앙 서버 무효화 조정기로 무효화 명령을 브로드캐스트(broadcast)하는 데이터베이스에서 수정될 때, 중앙 캐쉬 및 로컬 캐쉬에 저장된 객체들은 무효화된다. 무효화 조정기는 중앙 캐쉬에서 대응하는 객체를 무효화하고, 모든 로컬 캐쉬로 무효화 명령을 전파(propagate)하여, 로컬 캐쉬에서 대응하는 객체를 무효화하고 삭제(delete)한다. 중앙 캐쉬의 무효화된 객체는 삭제되거나 재작성(reconstruct)된다. 재작성되는 경우, 재작성된 객체는 모든 백업 중앙 캐쉬에 복제된다.

도 1은 종래 기술, 즉 2 계층 소프트웨어 구조 및 다 계층 소프트웨어 구조를 도시한 도면이다.

도 2는 본 발명이 가장 잘 적용되는 다 계층 소프트웨어 구조를 전반적으로 도시한 도면이다.

도 3은 애플리케이션 프로그램에 의한 최종 사용자 요청의 처리로부터 유발 된 객체 인출의 다양한 경우와, 중앙 서버에서의 객체 작성을 도시한 도면이다.

도 4는 로컬 및 중앙 캐쉬에서 객체의 에이징을 도시한 도면이다.

도 5는 데이터베이스에서 데이터 요소가 수정되었을 때 캐쉬 내 객체의 무효화를 도시한 도면이다.

도 6은 무효화된 객체의 재작성을 도시한 도면이다.

도 7은 중앙 캐쉬에서 제거되어야하는 오래되지 않은 객체를 보조 메모리에 저장하는 것을 도시한 도면이다.

아래에서는 첨부된 도면을 참조하여 본 발명을 상세하게 설명한다. 설명 중에는 예시적인 실시예들이 포함되지만, 또 다른 실시예도 가능하며, 본 발명의 취지 및 범위를 벗어남이 없이 실시예의 변형도 가능하다.

도 2는 본 발명이 가장 잘 적용되는 다 계층 소프트웨어 구조(multi-tier software architecture)를 전반적으로 도시한 것이다.

상부 계층(200)은 일반적으로 하나 이상의 데이터베이스 서버(202)가 다중 데이터베이스(204)에 인터페이스하는 궁극적인 데이터 소스로서, 상기 다중 데이터베이스는 세계 전역으로부터 여행사 및 이와 유사한 서비스의 제공자가 제공하는 이용가능성 및 요금 데이터베이스 등으로 구성된다. 이러한 데이터베이스는 여행사 등의 사용자(즉, 그들의 콘텐츠(206)를 업데이트하고 유지하는 담당자)에 의해, 주로 인터넷을 포함하는 개인 및 공공 네트워크(208)의 결합을 통해 빈번하게 업데이 트된다. 일반적으로 하루를 기준으로 할 때, 부피가 큰 데이터를 포함하는 수백만 개의 트랜잭션(transaction)이 기록된다.

여기에서 중간 계층(210)은 두 개의 서버(이하, 중앙 데이터 서버 또는 CDS라고 칭함)로 구성되도록 도시하였다. 일반적으로는 예비(redundancy)를 위해, 메인 서버(main server)(212)와 백업 서버(backup server)(214)가 존재한다. 그러나, 하나의 서버(예비 없음) 내지 다수의 서버로 구성되는 임의의 설정도 가능하다. 또한, 시스템의 유지를 용이하게 하기 위해 또는 지정된 메인 CDS의 고장으로 인해, 중앙 서버가 때때로 독립형(standalone) 서버로 설정되어야만 할 수도 있다. 지정된 백업 서버도 필요시에는 일시적으로 메인 서버로 작용해야만 할 수도 있다. 이는 아래 본 발명의 설명에서 더 논의된다.

중간 계층에 다중 서버를 갖는 것은 이 구조의 일반적인 모습이다. 메인 서버와 동일한 역할을 하는 하나 이상의 예비 서버, 또는 별개의 애플리케이션 프로그램을 실행하는 특수 서버가 있을 수 있다. 더 많은 처리 능력이 요구될 때, 범위성(scalability)을 달성하는 하나의 방법은 중간 서버를 추가하여, 전방 계층(220) 요청(request)이 더 많아진 중간 계층 서버로 부하 균형(load balance)을 이루게 됨으로써 더 많은 클라이언트 트랜잭션이 취급될 수 있게 하는 것이다. 따라서, 각 CDS는 항상 일관된 콘텐츠를 보유해야하는 그 자신의 캐쉬(중앙 캐쉬라고 칭함)(216, 218)를 갖는다.

본 발명이 고려하는 애플리케이션의 종류에서는, 캐쉬에 존재하는 데이터 엔티티(data entity)는 아래에서 대체로 소프트웨어 객체 또는 단순히 객체(object) 라고 인용한다. 일반적으로, 조회(query)를 통해 데이터베이스로부터 얻어진 많은 데이터 요소들은 객체를 만들어내도록 짜맞추어야(put together) 한다. 여기에서, 본 발명에 따른 객체는 데이터베이스 서버(202)를 통해 데이터베이스(204)에서 얻어진 데이터 요소들로부터 일단 CDS에 의해 작성(construct)되어지는 특정한 운행 요금 등일 수 있다. 배경기술 부분에서 논의된 바와 같이, 데이터베이스가 관계형 데이터베이스라면, 이는 객체(예컨대, 이 특정 예에서는 운행 요금)를 작성하는데 필요한 모든 데이터 요소들이 결국 CDS에 모일 수 있도록, 하나 이상의, 일반적으로는 더 많은 SQL 요청을 데이터베이스에 발급함으로써 달성된다. 이와 같이 본 발명에 따른 객체는 처리 능력을 필요로 하고, 사용가능한 형태가 되기 위해 데이터 서버와 통신 대역폭(communication bandwidth)을 사용하는 복잡한 객체라고 가정된다. 객체를 형성하는데 사용된 소스 정보가 데이터베이스에서 수정되지 않는 동안에는, 객체가 캐쉬에 남아있을 수 있다. 재작성(reconstruction)은 처리 능력을 소비하고 데이터베이스 및 데이터베이스 서버와의 이용가능한 통신 대역폭 부분을 사용하므로, 손실이 크다. 일관성에 관한 한, 메인 CDS의 중앙 캐쉬(216) 등에 있는 특정 객체는 백업 CDS 중앙 캐쉬(218)에 있는 그 클론(clone)과 정확히 동일해야 하며, 그 콘텐츠는 객체가 작성되었던 데이터베이스(204)의 데이터 요소들과 일치해야 한다. 이는 아래 본 발명의 설명에서 더 논의된다.

전방 계층(220)은 최종 사용자(end-user)를 위해 소프트웨어 애플리케이션을 실행하는 다수의 위성 서버(satellite server)로 구성된다. 본 발명을 설명하는데 사용된 예에서, 소프트웨어 애플리케이션은 일반적으로 가격결정 또는 요금 검색 엔진이 된다. 이 소프트웨어 애플리케이션은 개인 또는 공공 네트워크(예컨대, 표준 브라우저와 가장 널리 유포된 인터넷 애플리케이션인 월드-와이드-웹 또는 웹을 사용하는 인터넷)(228)를 통해 원거리 사용자(226)로부터 교대로 액세스되는 서버 팜(farm of server)(225)을 포함하는 독립적인 전방 계층 위성 서버(224)에서 실행되거나, 또는 위성 클라이언트 서버(222)에서 직접 실행될 수 있다. 두 경우 모두, 모든 위성 서버가 접속되는 중간 계층의 CDS와 전방 계층 사이의 통신 오버헤드(communication overhead)를 줄이기 위해, 애플리케이션은 필수적으로 로컬 캐쉬(230)를 이용한다. 위에서 논의된 객체는 필요시에는 이와 같이 다양한 로컬 캐쉬로도 보내진다. 따라서, 요청된 객체가 실제로 로컬 캐쉬에 있다면, 로컬 애플리케이션은 CDS 또는 데이터 서버에 액세스할 필요가 없다. 이는 데이터베이스 서버(202)를 보호할 수 있는 중요한 이점을 제공하는데, 즉, 그렇지 않으면 데이터베이스 서버에 도달했을 최종 사용자(226)로부터의 무수한 요청을 데이터베이스 서버가 받지 않도록 한다.

소프트웨어 애플리케이션은 뛰어난 캐쉬 적중률(cache hit ratio)을 달성할 목적으로 안출되었으므로, 성능이 극적으로 개선되는 것을 볼 수 있다. 또한, 계층 사이의 통신 오버헤드가 상당히 감소하여, 결국 동일한 기반구조(infrastructure)에 더 많은 최종 사용자를 수용할 수 있게 한다. 이미 상술한 바와 같이, 이 모든 것은 아래 도면에서 더 논의되는 것처럼 캐쉬 일관성(cache coherence)이 유지된다는 것을 가정한 것이다.

도 3은 애플리케이션 프로그램에 의한 최종 사용자 요청의 처리로부터 유발 된 객체 인출의 다양한 경우를 도시한 것이다.

전방 계층 서버에 위치한 가격결정 프로그램(300) 등과 같은 애플리케이션 프로그램이 운행 요금을 연산할 객체(305)를 필요로 할 때에는, 우선 로컬 캐쉬에 질문(interrogate)(310)된다. 적중(hit)이 있다면, 객체는 로컬 캐쉬로부터 간단하게 회수(retrieve)된다(315). 이는 전체 처리과정이 단지 애플리케이션을 실행하는 서버 만을 포함하므로, 객체를 회수하는 가장 효율적인 방법이다.

그러나, 요청된 객체가 로컬 캐쉬에 존재하지 않는다면, 부적중(miss)(320)이 있다. 객체는 가져와져야만 하는데, 우선 여기에서는 객체가 부하 균형 기능(이후에 더 논의함)을 통해 요청이 발급된(issue)(390) 메인 CDS의 중앙 캐쉬(340)에 존재한다고 가정한다. 실제로 이러한 경우(345)라면, 데이터 조정기(data handler)(350)는 객체를 포워드(330)하는 중앙 캐쉬로부터 객체가 저장되는 요청 서버의 로컬 캐쉬까지 객체를 회수하도록 기능한다. 회수 과정이 종료된 후, 요청된 객체는 결국 애플리케이션 프로그램으로 전달된다. 따라서, 로컬 캐쉬는 가능하게는 추가적인 요청에 사용될 수 있는 하나 더 많은 객체(325)를 포함한다.

요청된 객체가 로컬 캐쉬에 존재하지 않고(350), 메인 CDS의 중앙 캐쉬에도 존재하지 않는 경우(355), 객체는 CDS에서 작성되어야 하고 중앙 캐쉬에 저장되어야한다. 이것은 요청된 객체(355)를 작성하는데 필요한 모든 데이터 요소들(360)을 데이터베이스(365)로부터 수집해야만 하는 상술한 데이터 조정기(350)에 의해 달성된다. 객체의 작성은 많은 요청(예컨대: SQL 조회)을 데이터베이스에 발급할 필요가 있는 복잡한 프로세스일 수 있다. 일단 객체가 짜맞추어지면, 객체가 요청한 애 플리케이션에 의해 실제로 사용할 수 있는 것인지 확인하기 위해 객체의 철저한 체킹이 수행된다. 상기 체킹은 애플리케이션 샘플 코드(sample code)로의 테스트와 함께 객체 기술 언어(object description language)의 구문(syntactic) 및 의미(semantic) 체킹을 포함한다. 새로운 객체가 이 검증(validation) 국면을 통과한다면(대체로 통과함), 중앙 캐쉬에 저장된다. 저장에 앞서, 유지시간(time-to-live)(TTL) 또는 유효기간이 그 객체에 첨부되어, 도 4에서 더 논의되는 바와 같이, 그 객체가 오래되었을 때(outdated) 제거될 수 있다. 일단 저장되면, 새로운 객체는 객체를 요청했던 서버의 로컬 캐쉬로 포워드되어 저장되며, 이후 객체를 필요로 하는 소프트웨어 애플리케이션에 전송(375)된다. 그러나, 새로 작성된 객체의 검증이 실패한다면, 그것은 거부(reject)되므로 중앙 캐쉬에 저장되지 않거나 로컬 캐쉬에 포워드되지 않는다(357).

새로운 객체가 메인 CDS에 생성되면, 이 새로운 객체가 또 다른 중앙 서버 캐쉬에서도 회수(retrieve)될 수 있도록 백업 중앙 서버(342)에도 복제(380)된다. 앞에서 논의된 것처럼, 예비(redundancy)와 범위성(scalability)을 위해, 전방 계층 서버의 요청이 이용가능한 중앙 데이터 서버 세트로 부하 균형될 수 있도록, 많은 중간 계층 서버들이 동시에 활성화(active)될 수 있다. 잘 알려진 순환 순서(round-robin) 기능만큼 간단할 수 있는 알고리즘이나 특정 로직(logic)에 따라 전방 계층 요청(390)을 배정(dispatch)하는 부하 균형 기능(385)이 있다는 사실을 제외하고는, 본 발명의 범위를 넘어서는 도 3에 약기된 부하 균형에 대해 더 이상 논의하지 않는다. 이 경우, 유입한 전방 계층 요청은 마지막 중앙 서버에 이를 때 까지 연속적으로 각각의 활성(active) 중앙 서버에 차례차례 보내진다. 그 다음의 요청은 다시 처음에 번호 메겨진 중앙 서버 등으로 보내진다. 이 단순한 알고리즘은 종종 매우 효과적이다. 그러나, 각 서버의 실제적인 부하를 측정하여 유입한 요청을 가장 덜 바쁜 서버로 보내는 것과 같이 더 복잡한 알고리즘도 있다.

따라서, 부적중 객체(missing object)가 메인 CDS 캐쉬로부터 요청된다는 앞의 기술은 수정되어야 한다. 부하 균형 기능(385)에 의한 결정에 따라 부적중 객체는 백업 중앙 캐쉬로부터도 요청될 수도 있는데, 이는 새롭게 작성된 객체가 활성 서버에 복제(380)되기 때문이다. 그러나, 이 경우 객체가 선택된 백업 중앙 캐쉬에 존재하지 않는다면, 객체는 상술한 것과 같이 메인 CDS가 선택된 것처럼 작성되어야 한다. 이 경우, 백업 서버는 일시적으로 메인 CDS처럼 작용하는데, 이는 일단 작성된 객체가 백업 중앙 캐쉬로부터 모든 활성 CDS 캐쉬로 복제되어, 새로운 객체가 모든 중간 계층 중앙 캐쉬에서 이용가능함을 의미한다. 백업 CDS가 일시적으로 메인 CDS처럼 작용할 수도 있다는 본 발명의 이러한 측면은 도 6에서도 논의된다.

도 4는 캐쉬내 객체의 에이징(aging)에 대해 논의한다. 상술한 바와 같이, 오래된(outdated) 요소들이 캐쉬로부터 제거될 수 있고 메모리에 영구적으로 남아있지 않도록 하기 위해, 모든 작성된 객체들은 한정된 유지시간(TTL) 또는 유효기간이 첨부되어 있다.

소프트웨어 애플리케이션(400)이 로컬 캐쉬에서 오래된 객체(405)를 인출하면, 객체가 제거되어 요청한 애플리케이션으로 반환되지 않는다. 이는 중간 계층 CDS(도 3에서 설명한 것과 같이, 부하 균형 기능으로 선택된 것, 도시되지 않음)의 질문(interrogation)을 유발한다. 객체가 중앙 캐쉬에 존재하고(445) 오래되지 않았다면, 객체는 상술한 것처럼 데이터 조정기(450)에 의해, 객체가 저장되는(425) 호출(calling) 애플리케이션의 로컬 캐쉬로 포워드되어 요청한 애플리케이션에 전송(435)될 수 있다. 이로써 로컬 캐쉬 내의 오래된 객체를 대체하는 프로세스는 종료된다. 요청된 객체의 신규 복사본을 중앙 캐쉬에서 즉시 이용할 수 있다면, 이는 대체로 또 다른 로컬 캐쉬를 이용하는 별개의 애플리케이션이 이전에 CDS에서 재작성(reconstruct)된 동일한 객체를 이미 필요로 하였기 때문이다.

그러나, 다른 경우에는, 즉 요청된 객체가 중앙 캐쉬에서도 오래되었다면(455), 객체는 재작성되어야 한다. 이는 도 3에서 설명한 것처럼, 무효화 조정기(invalidation handler)(460) 기능을 통해 오래된 객체의 무효화(invalidation)도 요청하는(470) 데이터 조정기에 의해 데이터베이스(465)로부터 수행된다. 따라서, 오래된 객체는 결국 중앙 캐쉬에서 새롭게 작성된 객체(475)로 대체되며, 또한 도 3에서 설명한 것처럼 모든 중간 계층 CDS 캐쉬에 복제된다. 여기에서 주목할 것은, 도 3에서 언급된 부하 균형 기능에 의한 선택의 결과로, 오래된 객체(455)가 요청된 CDS가 메인 CDS가 아닌 백업 CDS라면, 재작성은 실제로 백업 데이터 조정기에 의해 수행되지 않는다는 것이다. 객체 무효화 요청은 오히려 메인 CDS 무효화 조정기로 포워드(480)되어, 메인 CDS가 재작성을 대신 수행하고, 결국 원래 요청을 받았던 CDS를 포함한 모든 중간 계층 CDS 캐쉬가 업데이트되도록 재작성된 객체를 모든 백업CDS 캐쉬에 복제한다.

재작성은 매우 긴 프로세스일 수 있으므로, 요청한 애플리케이션(400)이 멈 추지 않도록 하기 위해, 오래되었지만 원래 요청되었던 객체(455)를 요청한 로컬 캐쉬로 전송(485)한다. 다만 전송에 앞서, 객체의 TTL은 매우 낮은 값으로 맞추어진다. 따라서, 상술한 것처럼 재작성이 진행중인 동안에도, 객체는 여전히 현재의 요청을 위해 사용할 수 있다. 이 짧은 TTL이 만료된 후 받은 뒤따른 요청은 새롭게 재작성된 객체를 이용할 것이다. 이러한 운영 방식은, 새로운 일련의 항공 요금을 광범위한 네트워크에 배포하는데 상당한 시간이 걸려, 규칙적이지만 탄력적으로 업데이트되는 항공 요금과 같이, 본 발명이 고려하는 애플리케이션 종류에 적합하다.

도 5는 데이터 요소들이 데이터베이스에서 수정되었을 때(500), 캐쉬 내 객체의 무효화를 도시한다. 이는 데이터베이스가 사용자(505), 즉 콘텐츠를 업데이트하고 관리하는 담당자에 의해 업데이트될 때 일어난다. 데이터 베이스 서버는 객체를 형성하는데 사용된 데이터 요소가 변경된 것을 탐지할 수 있다. 충돌된(impacted) 객체 세트는, 무효화되고 가능하게는 중앙 캐쉬에서 재작성되도록 결정된다. 이를 위해, 데이터베이스는 모든 CDS, 즉 메인 CDS 및 백업 CDS로 객체 무효화 명령을 브로드캐스트(broadcast)(510)하며, CDS의 모든 충돌된 객체는 무효화(515, 525)된다.

메인 CDS(520)에서, 무효화 조정기(530)는 우선 무효화된 객체가 삭제(delete)되어야 하는지 또는 재작성되어야 하는지 결정해야 한다. 실제로는, 중앙 캐쉬에 존재하는 객체는 재작성될 만한 가치가 없을 수도 있다. 예를 들면, 객체가 장기간 사용되지 않았거나, 거의 사용되지 않은 경우, 또는 빈번하게 무효화되는 경우라면, 캐쉬 메모리를 무익하게 차지하지 않게 하고 재작성에 필요한 통신 대역폭(communication bandwidth)과 처리 능력을 절약하기 위해, 무효화 조정기는 단순히 객체를 삭제하도록 결정할 수 있다. 이 결정은 미리 정해진 설정에 따라 이루어진다. 무효화 조정기의 거동은 CDS 관리자(administrator)에 의해 정의되고 설정된다.

객체를 삭제하도록 결정된다면, 대응하는 캐쉬 메모리 공간은 자유롭게 된다. 그러나, 무효화 조정기가 객체가 재작성되어야 한다고 결정하면, 이는 도 3에서 설명된 것과 유사한 방식으로 데이터베이스로부터 이루어진다. 일단 재작성(535)되면, 객체는 모든 CDS 캐쉬에 복제(540)되어, 동기화(synchronize)되고 모든 중앙 캐쉬(545)에서 신규 복사본을 이용할 수 있다.

객체의 삭제 또는 재작성 중 어느 경우든지, 메인 CDS 무효화 조정기는 전방 계층 서버의 소프트웨어 애플리케이션(555)이 오래된 객체(560)를 사용하지 못하도록, 모든 위성 서버에 객체 무효화 명령을 전파(propagate)(550)한다. 소프트웨어 애플리케이션이 로컬 캐쉬에서 더 이상 이용할 수 없는 무효화된 객체를 다시 필요로 할 때에는, 도 3에 설명한 것처럼, CDS로부터 객체의 인출 및 가능하게는 재작성이 이루어질 것이다.

또한, 객체의 삭제 또는 재작성이 완료될 때, 무효화 명령이 메인 CDS에서 백업 CDS로 통지(570)된다. 이는 다음 도면에서 논의되는 것처럼, 무효화 조정기에 의해 사용되는 진행 테이블(in-progress table)의 관리를 처리하기 위한 것이다.

도 6은 무효화된 객체의 재작성에 대해 더 논의한다.

도 5에서 설명된 것처럼 무효화된 객체를 재작성해야 하는 경우, 객체 무효 화 요청을 받을 때 업데이트되는 진행 테이블(600)이 CDS에 있다. 진행중인 연산(operation), 즉 무효화된 객체의 재작성(605)은 메인 CDS의 테이블에 기록(log)(610)되고, 백업 진행 테이블에도 포워드(625)된다. 또한, 무효화된 현재 객체의 TTL 또는 유효기간이 낮은 값으로 변경되어, 상술한 것처럼 새로운 객체가 재작성되는 동안에도 이 객체를 사용할 수 있다.

이 연산의 정상적인 완료는 객체가 정상적으로 재작성되고 모든 확인(verification) 및 체킹(640)을 통과하는 것이다. 이 경우, 상술한 것과 같이, 객체를 모든 중앙 캐쉬에서 이용할 수 있도록 하기 위해 객체가 백업 CDS 캐쉬로 포워드(615)된다. 동시에, 진행중인 연산의 기록은 재작성된 객체를 받은(615) 백업 CDS의 진행 테이블(620)은 물론 메인 진행 테이블에서도 소거된다.

그러나 이 연산은 장기적으로 보아 CDS의 뛰어난 연산에 영향을 미치지 않고는 정상적으로 종료되지 않을 수 있다.

고려되는 제1 상황은, 필요한 데이터 요소 일부가 데이터베이스로부터 적절하게 전송되지 않는(630) 등으로 인해, 메인 CDS에서 객체가 완전하게 재작성될 수 없는 경우이다. 그 시작(start)이 진행 테이블(600)에 기록되었던 재작성 연산이 재시도되어야 한다. 이 보류중인(pending) 연산은, 진행 테이블을 모니터하고 주기적으로 검사하는 스캐빈저 프로세스(scavenger process)(635)에 의해 탐지된다. 진행 테이블에 기록된 보류중인 연산을 위해 무효화 조정기에 의해 시도되는 재시행(retry)의 횟수에는 명백히 제한이 있다. 정상적인 조건에서는, 상기 재시행중 한번은 성공적이므로 연산은 상술한 것처럼 정상적으로 재시작한다.

고려되는 제2 상황은 재작성된 객체(610)가 백업 CDS들 중 어느 것에도 정상적으로 전송되지 않은 경우이다. 모든 백업 CDS도 진행 테이블(620)을 가지고 있기 때문에, 이는 메인 CDS에서와 유사한 방식으로 탐지된다. 따라서, 백업 스캐빈저 프로세스는, 데이터베이스로부터 객체 무효화 브로드캐스트의 결과로 기록되었던 보류중인 연산을 탐지한다. 메인 CDS가 무효화된 객체를 재작성할 것으로 예상되므로 백업 CDS는 정상적으로는 어떠한 객체 재작성도 맡지 않는다. 그러나, 이는 스캐빈저가 문제를 보고하는 경우, 백업 무효화 조정기(650)에 의해 예외적으로 일어날 수 있다. 이 경우, 백업 무효화 조정기는 결국 자기의 캐쉬를 위해 무효화된 객체를 재작성(655)하며, 이는 일시적으로 메인 CDS처럼 작용하는 것이다. 여기에는 데이터베이스로부터 필요한 데이터 요소의 (백업 CDS로의)재전송이 요구된다. 그후 진행 테이블의 보류중인 항목은 소거될 수 있고 연산은 가장된(affected) 백업 CDS를 위해 정상적으로 재시작될 수 있다.

도 7은 본 발명의 선택적인 특징을 간결하게 도시한다.

캐쉬는 그것이 설치되는 중앙 서버의 이용가능한 활성 메모리(active memory)로 형성되므로, 필연적으로 한정된 크기를 갖는다. 따라서 캐쉬가 꽉 찰 수도 있다: 새로 요청된 객체를 작성하기에 충분한 메모리가 남아있지 않다. 따라서, 새로운 객체를 위한 공간(room)을 만들기 위해 최근 최저 사용된(least recently used)(LRU) 객체를 제거하는 것이 캐쉬의 표준 관행이다. 다른 대체 알고리즘이 적용될 수도 있다. 어떠한 알고리즘이 사용되든지, 최근에 사용되지 않아 제거되도록 선택된 객체는 여전히 유효한 객체, 즉 오래되지 않은 객체일 수 있다. 이미 지적 된 것처럼 본 발명에 따른 객체는, 작성시 서버 중앙처리장치(CPU)로부터 상당한 처리 능력이 필요하고, 또한 백그라운드 데이터베이스(700)에 다중 액세스가 필요한 복잡한 객체이다. 이와 같이 객체의 재작성은 손실이 크므로, 객체를 캐쉬에서 제거하는 경우 객체가 오래되지 않았다면 폐기(discarding)는 회피되어야 한다.

메인 CDS의 중앙 캐쉬(720) 또는 백업 CDS의 중앙 캐쉬(730)가 꽉 차고(760), LRU 객체 등이 제거되도록 선택(770)된 경우, 그 객체가 오래되지 않았다면(792), 이 LRU 객체는 폐기(780)되는 대신에, 서버로부터 용이하게 액세스할 수 있는 보조 메모리(740, 750)에 저장(775)될 수 있다. 그러나, 객체가 오래되었다면(794) 폐기되어야 한다. 보조 메모리는 일반적으로 서버에 부착된 하드 디스크의 전용 메모리 공간이다. 따라서, 오래되지 않은 객체의 재작성은 회피될 수 있다. 이를 위해, CDS는 보조 메모리에 저장된 객체를 추적한다. 애플리케이션이 이 객체들 중의 하나를 다시 필요로 하는 경우, 이 객체는 재작성되는 대신에 대응하는 보조 메모리로부터 회수된다. 상술한 메카니즘이 적용되는데, 즉, 검색(search)이 성공적이지 않거나 보조 메모리에 저장된 이후로 객체가 오래되어 재작성되는 경우에 앞서, 우선 보조 메모리에서 검색된 요청된 객체를 위한 공간을 만들기 위해 LRU 객체가 캐쉬로부터 제거된다.

Claims

캐쉬 콘텐츠의 일관성을 유지하는 방법으로서,

다 계층 소프트웨어 구조를 이용하는 단계로서, 상기 다 계층 소프트웨어 구조는 각각 로컬 캐쉬를 운영하는 하나 이상의 위성 서버를 포함하는 전방 계층을 포함하고, 상기 다 계층 소프트웨어 구조는 중앙 캐쉬를 각각 운영하는 하나 이상의 중앙 서버를 포함하는 중간 계층을 포함하고, 상기 하나 이상의 중앙 서버 각각은 하나 이상의 데이터베이스 서버를 통해 하나 이상의 데이터베이스와 인터페이스하고, 상기 하나 이상의 데이터베이스는 데이터 요소를 포함하며, 상기 데이터 요소는 상기 하나 이상의 중앙 서버 각각으로부터 상기 하나 이상의 데이터베이스 서버로 발급되는 조회에 의해 회수되는, 다 계층 소프트웨어 구조를 이용하는 단계와;

상기 하나 이상의 중앙 서버에서, 상기 하나 이상의 위성 서버로부터 나오는 객체에 대한 요청을 수신하는 단계와;

상기 하나 이상의 중앙 서버에서 객체를 작성하는 단계로서:

상기 하나 이상의 데이터베이스로부터 데이터 요소를 회수하는 단계와;

복수의 상기 데이터 요소로부터 각각의 객체를 구축하는 단계와;

상기 객체를 검증하는 단계와;

상기 객체에 유지시간(TTL)을 부여하는 단계; 및

상기 하나 이상의 중앙 서버의 중앙 캐쉬에 상기 객체를 저장하는 단계;를 포함하는, 객체를 작성하는 단계와;

상기 중앙 캐쉬로부터 상기 객체를 요청하는 위성 서버들 중 하나 이상의 위성 서버에게 상기 객체를 포워드하는 단계로서:

상기 객체를 요청하는 위성 서버들 중 하나 이상의 위성 서버의 상기 로컬 캐쉬에 상기 객체를 저장하는 단계;와

상기 객체를 요청하는 하나 이상의 위성 서버의 로컬 캐쉬로부터 상기 위성 서버에서 실행하고 상기 객체를 요청하는 소프트웨어 애플리케이션에 상기 객체를 전송하는 단계;를 더 포함하는 객체를 포워드하는 단계;를 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제1항에 있어서,

복수의 위성 서버로부터 객체에 대한 복수의 요청을 중간 계층에서 수신하는 단계를 포함하고, 상기 중간 계층은 복수의 중앙 서버를 포함하고, 상기 위성 서버로부터의 요청은 모든 이용가능한 상기 중앙 서버에서 부하 균형이 실행되고, 요청시마다 상기 중앙 서버 중 하나가 선택되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제2항에 있어서,

상기 객체를 작성하는 단계는, 상기 선택된 중앙 서버로부터 모든 다른 상기 중앙 서버에서, 작성된 객체를 복제하는 단계를 더 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제1항에 있어서,

상기 하나 이상의 위성 서버의 상기 로컬 캐쉬에서 객체가 부적중인 경우, 객체가 상기 하나 이상의 중앙 캐쉬로부터 요청되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제1항에 있어서,

하나 이상의 위성 서버가 상기 객체를 요청하고 상기 객체가 상기 하나 이상의 중앙 캐쉬에서 부적중이면, 상기 객체를 작성하는 단계가 상기 하나 이상의 중앙 서버에서 객체에 대하여 시작되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제1항에 있어서,

상기 유지시간(TTL)을 부여하는 단계 및 상기 객체를 저장하는 단계는, 상기 객체를 검증하는 단계가 상기 객체를 검증하는데 실패하는 경우 상기 객체를 거부하는 단계로 대체되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제2항에 있어서,

요청된 객체가 상기 하나 이상의 중앙 캐쉬에 이미 존재하고 객체의 유지시간(TTL)이 만료되지 않았다면, 상기 객체를 작성하는 단계가 상기 하나 이상의 중앙 서버에서 생략되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제1항에 있어서,

상기 중간 계층은 복수의 중앙 서버를 포함하고, 하나의 상기 중앙 서버는 메인 중앙 서버로 지정되고, 그 밖의 모든 중앙 서버는 백업 중앙 서버로 지정되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제8항에 있어서,

상기 요청된 객체가 다른 중앙 서버에서 객체의 유지시간(TTL)이 만료되었다고 판명되면, 상기 객체를 작성하는 단계가 상기 메인 중앙 서버에서 무효화 조정기로부터 시작되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제9항에 있어서,

만료된 객체의 유지시간(TTL)은, 상기 요청하는 위성 서버로 포워드되기 전에 감소되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제8항에 있어서,

상기 중앙 서버는 각각 무효화 조정기를 포함하고, 상기 객체를 작성하는데 사용되는 하나 이상의 상기 데이터 요소가 상기 데이터베이스에서 수정되자마자, 상기 중앙 캐쉬 및 상기 로컬 캐쉬에 저장된 객체가 무효화되는 캐쉬 콘텐츠의 일관성을 유지하는 방법으로서,

어떤 객체가 충돌되는지 측정하는 단계;

무효화 명령을 상기 중앙 서버들의 모든 무효화 조정기로 브로드캐스트하는 단계;

상기 중앙 캐쉬에서 대응하는 객체를 무효화하는 단계;

상기 무효화 명령을 모든 상기 로컬 캐쉬로 전파하는 단계;

상기 로컬 캐쉬에서 대응하는 객체를 무효화하는 단계로서, 상기 객체를 삭제하는 단계를 더 포함하는, 객체를 무효화하는 단계;를 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제11항에 있어서,

상기 중앙 캐쉬에서 대응하는 객체를 무효화하는 단계는 상기 객체를 삭제하는 단계를 더 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제12항에 있어서,

상기 객체를 삭제하는 단계는 상기 메인 중앙 서버에서 상기 객체를 재작성하는 단계로 대체되고, 상기 재작성된 객체를 모든 상기 백업 중앙 서버로 복제하는 단계를 더 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제13항에 있어서,

상기 중앙 서버 각각은 객체 재작성 진행 테이블 및 상기 진행 테이블로부터 상기 객체 재작성을 모니터하는 스캐빈저 프로세스를 포함하는 캐쉬 콘텐츠의 일관성을 유지하는 방법으로서,

객체 재작성의 시작 및 종료를 상기 진행 테이블에 기록하는 단계;

상기 객체 재작성의 완료를 탐지하기 위해 상기 진행 테이블을 검사하는 단계로서, 성공적으로 완료한 객체 재작성의 테이블 엔트리를 소거하는 단계를 더 포함하는 진행 테이블을 검사하는 단계;

실패한 진행 객체 재작성을 탐지하는 단계;

실패한 객체 재작성을 재시도하는 단계;를 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제14항에 있어서,

상기 객체 재작성은 상기 메인 중앙 서버에서 수행되고, 상기 진행 테이블에 기록하는 단계는 객체 재작성 시작을 상기 백업 중앙 서버의 모든 진행 테이블에 포워드하는 단계를 더 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제15항에 있어서,

메인 중앙 서버로부터 포워드된 객체를 받을 때, 객체 재작성 종료가 백업 중앙 서버의 상기 진행 테이블에 기록되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제14항에 있어서,

상기 탐지하는 단계 및 상기 재시도하는 단계는 상기 백업 중앙 서버들 중 하나에서 수행되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제1항에 있어서,

상기 객체를 작성하는 단계는,

예비단계로서,

상기 중앙 캐쉬가 꽉 차 있는지 아닌지 체크하는 단계; 및

상기 객체의 유지시간(TTL)이 만료되었는지 아닌지 체크하는 단계;를 포함하고,

상기 중앙 캐쉬가 꽉 차 있는지 아닌지 체크하는 단계에서는, 상기 중앙 캐쉬가 꽉 차 있지 않다면, 상기 객체를 작성하는 단계로 즉시 진행하고, 상기 중앙 캐쉬가 꽉 차 있다면, 상기 중앙 캐쉬에서 최근 최저 사용된 객체를 선택하며,

상기 객체의 유지시간(TTL)이 만료되었는지 아닌지 체크하는 단계에서는, 상기 객체의 유지시간(TTL)이 만료되지 않았다면 상기 최근 최저 사용된 객체를 보조 메모리에 저장하고, 상기 객체의 유지시간(TTL)이 만료되었다면 상기 객체를 폐기하며, 두 경우 모두에, 상기 객체를 작성하는 단계로 진행하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
제13항에 있어서,

상기 재작성하는 단계로 진행하기 전에, 보조 메모리가 요청되는 객체를 위해 더 검색되는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하는 방법.
다 계층화된 서버 구조에서 캐쉬 콘텐츠의 일관성을 유지하기 위한 시스템으로서,

상기 시스템은 다 계층 소프트웨어 구조를 포함하고, 상기 다 계층 소프트웨어 구조는 각각 로컬 캐쉬를 운영하는 하나 이상의 위성 서버를 포함하고 있는 전방 계층을 포함하고, 하나 이상의 위성 서버를 포함하는 전방 계층을 포함하는 다 계층 소프트웨어 구조를 포함하고, 상기 다 계층 소프트웨어 구조는 중앙 캐쉬를 각각 운영하는 하나 이상의 중앙 서버를 포함하는 중간 계층을 포함하고, 상기 하나 이상의 중앙 서버 각각은 하나 이상의 데이터베이스 서버를 통해 하나 이상의 데이터베이스와 인터페이스하고, 상기 하나 이상의 데이터베이스는 데이터 요소를 포함하며, 상기 데이터 요소는 상기 하나 이상의 중앙 서버 각각으로부터 상기 하나 이상의 데이터베이스 서버로 발급되는 조회에 의해 회수되고,

상기 하나 이상의 위성 서버와 상기 하나 이상의 중앙 서버 및 상기 하나 이상의 데이터베이스는:

상기 하나 이상의 중앙 서버에서, 상기 하나 이상의 위성 서버로부터 나오는 객체에 대한 요청을 수신하는 단계와;

상기 하나 이상의 중앙 서버에서 객체를 작성하는 단계로서:

상기 하나 이상의 데이터베이스로부터 데이터 요소를 회수하는 단계와;

복수의 상기 데이터 요소로부터 각각의 객체를 구축하는 단계와;

상기 객체를 검증하는 단계와;

상기 객체에 유지시간(TTL)을 부여하는 단계; 및

상기 하나 이상의 중앙 서버의 중앙 캐쉬에 상기 객체를 저장하는 단계;를 포함하는, 객체를 작성하는 단계와;

상기 중앙 캐쉬로부터 상기 객체를 요청하는 위성 서버들 중 하나 이상의 위성 서버에게 상기 객체를 포워드하는 단계로서:

상기 객체를 요청하는 위성 서버들 중 하나 이상의 위성 서버의 상기 로컬 캐쉬에 상기 객체를 저장하는 단계; 및

상기 객체를 요청하는 하나 이상의 위성 서버의 로컬 캐쉬로부터 상기 위성 서버에서 실행하고 상기 객체를 요청하는 소프트웨어 애플리케이션에 상기 객체를 전송하는 단계;를 더 포함하는, 객체를 포워드하는 단계;를 실행하도록 프로그램되어 있는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하기 위한 시스템.
제20항에 있어서,

하나 이상의 데이터베이스의 데이터 요소로 객체를 작성하는 수단과, 객체의 유지시간(TTL)이 만료되었을 때 상기 데이터 객체를 무효화하는 수단, 및 유지시간(TTL)이 만료된 객체의 재작성을 관리하는 수단을 포함하는 것을 특징으로 하는 캐쉬 콘텐츠의 일관성을 유지하기 위한 시스템.
하나 이상의 컴퓨터가 다 계층 소프트웨어 시스템에서 캐쉬 콘텐츠의 일관성을 유지하는 방법을 운영할 수 있게 하는, 컴퓨터로 판독 가능한 코드 수단을 포함하는, 컴퓨터 프로그램이 저장된 컴퓨터로 판독 가능한 영구 저장 매체로서,

다 계층 소프트웨어 구조를 이용하고, 상기 다 계층 소프트웨어 구조는 각각 로컬 캐쉬를 운영하는 하나 이상의 위성 서버를 포함하는 전방 계층을 포함하고, 상기 다 계층 소프트웨어 구조는 중앙 캐쉬를 각각 운영하는 하나 이상의 중앙 서버를 포함하는 중간 계층을 포함하고, 상기 하나 이상의 중앙 서버 각각은 하나 이상의 데이터베이스 서버를 통해 하나 이상의 데이터베이스와 인터페이스하고, 상기 하나 이상의 데이터베이스는 데이터 요소를 포함하며, 상기 데이터 요소는 상기 하나 이상의 중앙 서버 각각으로부터 상기 하나 이상의 데이터베이스 서버로 발급되는 조회에 의해 회수되고,

상기 하나 이상의 위성 서버와 상기 하나 이상의 중앙 서버 및 상기 하나 이상의 데이터베이스 서버는:

상기 하나 이상의 중앙 서버에서, 상기 하나 이상의 위성 서버로부터 나오는 객체에 대한 요청을 수신하는 단계와;

상기 하나 이상의 중앙 서버에서 객체를 작성하는 단계로서:

상기 하나 이상의 데이터베이스로부터 데이터 요소를 회수하는 단계와;

복수의 상기 데이터 요소로부터 각각의 객체를 구축하는 단계와;

상기 객체를 검증하는 단계와;

상기 객체에 유지시간(TTL)을 부여하는 단계; 및

상기 하나 이상의 중앙 서버의 중앙 캐쉬에 상기 객체를 저장하는 단계;를 포함하는, 객체를 작성하는 단계와;

상기 중앙 캐쉬로부터 상기 객체를 요청하는 위성 서버들 중 하나 이상의 위성 서버에게 상기 객체를 포워드하는 단계로서:

상기 객체를 요청하는 위성 서버들 중 하나 이상의 위성 서버의 상기 로컬 캐쉬에 상기 객체를 저장하는 단계; 및

상기 객체를 요청하는 하나 이상의 위성 서버의 로컬 캐쉬로부터 상기 위성 서버에서 실행하고 상기 객체를 요청하는 소프트웨어 애플리케이션에 상기 객체를 전송하는 단계;를 더 포함하는 객체를 포워드하는 단계;를 실행하도록 프로그램되어 있는 것을 특징으로 하는 컴퓨터 프로그램이 저장된 컴퓨터로 판독 가능한 영구 저장 매체.