【文献】
Around25,How to Build a Trading Engine,2018年07月11日,https://web.archive.org/web/20180711142748/https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/,検索日:2020年7月16日
(58)【調査した分野】(Int.Cl.,DB名)
前記第1マッチングサーバーから受信した締結情報に基づいてストップ取引の注文に対応する条件が満たされれば、指定価取引の注文及び市場価取引の注文の少なくとも一つにストップ取引の注文を変換するストップオーダーサーバーをさらに含み、
前記アドミッションサーバーは、獲得した注文の種類を識別し、前記注文の種類がストップ取引であれば前記注文を前記ストップオーダーサーバーに伝達し、前記ストップオーダーサーバーから指定価取引及び市場価取引の少なくとも一つの取引を要請する注文を獲得する、請求項4に記載の仮想貨幣取引システム。
前記注文の記録のためのデータベースと通信し、前記注文の処理のためのデータのリース(lease)要請を受信するキャッシュサーバーをさらに含む、請求項1に記載の仮想貨幣取引システム。
仮想貨幣取引を要請する注文の処理のために前記注文とともに締結される他の注文をマッチングして取引対を生成する第1マッチングサーバーと、前記第1マッチングサーバーから前記取引対に対する締結要請を受信して前記取引対を締結し、前記取引対の締結結果によって、更新されたデータをデータベースに記録するコミットサーバーを含む仮想貨幣取引システムが仮想貨幣を取引する方法であって、
前記第1マッチングサーバーの障害の際、第2マッチングサーバーを登録して前記注文を処理する段階を含み、
前記注文を処理する段階は、
前記第2マッチングサーバーが、前記第1マッチングサーバーによって要請された締結要請に対する応答を前記コミットサーバーに要求する段階と、
前記コミットサーバーが、前記第2マッチングサーバーの要請に応じて、前記第1マッチングサーバーによって要請された締結要請の中で、締結できなかった状態の取引対があれば、締結できなかった状態の取引対を締結して前記第2マッチングサーバーの要請に応答する段階と、
前記第2マッチングサーバーが、前記コミットサーバーからの応答を獲得すれば、前記第1マッチングサーバーによってキューイングされた注文をデータベースから復旧する段階を含む、仮想貨幣取引方法。
【発明を実施するための形態】
【0026】
以下では添付図面に基づいて多様な実施例を詳細に説明する。以下で説明する実施例は様々な相異なる形態に変形されて実施されることもできる。実施例の特徴をより明確に説明するために、以下の実施例が属する技術分野で通常の知識を有する者に広く知られている事項についての詳細な説明は省略する。そして、図面で実施例の説明に関係ない部分は省略し、明細書全般にわたって類似の部分に対しては類似の図面符号を付けた。
【0027】
明細書全般で、ある構成が他の構成と連結されていると言うとき、これは直接的に連結されている場合だけではなく、その中間に他の構成を挟んで連結されている場合も含む。また、ある構成が他の構成を含むというとき、特に反対の記載がない限り、さらに他の構成を除くものではなくて他の構成をさらに含むこともできることを意味する。
【0028】
以下、添付図面に基づいて実施例を詳細に説明する。
【0029】
図1〜
図3は一実施例による仮想貨幣取引システムの構成を示す図である。
【0030】
因みに、仮想貨幣とはコンピュータなどに情報形態として残って実物なしにサイバー上で取引される電子マネーの一種で、暗号貨幣ともいう。
【0031】
仮想貨幣取引システム(説明の便宜上、以下では取引システムという)100は、ユーザーから仮想貨幣の取引(例えば、仮想貨幣の売渡し、仮想貨幣の買受など)を要請されれば、前記取引を注文と認識し、注文を処理して取引が完了するようにする。
【0032】
図1を参照すると、一実施例による取引システム100はマッチングサーバー120を含む。
【0033】
また、一実施例によるアドミッションサーバー(admission server)110、コミットサーバー130、キャッシュサーバー140及びデータベース150を含むことができる。
【0034】
一実施例によるアドミッションサーバー110は、取引システム100の外部システム(図示せず)と通信して外部システム(図示せず)からユーザーの仮想貨幣売渡し要請又は買受要請を受ける。
【0035】
アドミッションサーバー110は、外部システムから受信した前記売渡し/買受の要請を‘注文’として処理することができる。例えば、アドミッションサーバー110は、1個のビットコインを100ウォンの価格で買収することを要請する注文を獲得することができる。ここで、注文は他の注文と区別可能な識別子を有し、前記識別子は各注文を唯一に認識することができるようにする。
【0036】
ここで、アドミッションサーバー110は注文の種類を区別することができる。注文は、例えば、決まった金額のみで買受又は売渡しするようにする‘指定価取引’、要請された時点に市場で取引が締結されている金額で買受又は売渡しするようにする‘市場価取引’、及び特定の条件が満たされるとき又は特定の条件が満たされるまでだけ買受/売渡しするようにする‘ストップ取引’があり得る。アドミッションサーバー110は、注文の種類を区別し、要請された注文の少なくとも一部が締結されるようにすることができる。
【0037】
アドミッションサーバー110は、獲得された注文の種類を区別し、注文が‘指定価取引’又は‘市場価取引’と判断されれば、前記注文をマッチングサーバー120に伝達することができる。また、注文が‘ストップ取引’と判断されれば、後述するストップオーダーサーバー160に前記注文を伝達することができる。ここで、‘ストップ取引’はストップオーダーサーバー160を経て‘指定価取引’又は‘市場価取引’として再獲得されることができ、再獲得された注文をマッチングサーバー120に伝達することができる。
【0038】
アドミッションサーバー110は、注文を獲得すれば、キャッシュサーバー140に要請してユーザーデータを獲得することができる。
【0039】
ここで、ユーザーデータは仮想貨幣の取引に必要な情報としてユーザーについての諸般情報を含み、例えば、ユーザーの残高についての情報などを含むことができる。また、例えば、ユーザーデータは、要請された注文を記録するか注文処理完了による注文削除を記録するオーダーブック(order book)などを含むことができる。
【0040】
ユーザーデータの獲得のために、一実施例によれば、アドミッションサーバー110はユーザーデータに対してキャッシュサーバー140にリース(lease)要請することができるが、ユーザーデータを獲得するための方法は上述した例に制限されるものではなく、例えばアドミッションサーバー110はユーザーデータに対してロック(lock)要請をすることができる。
【0041】
前記ユーザーデータを獲得したアドミッションサーバー110は、ユーザーデータを参照して、注文を要請したユーザーが前記注文を処理するための残高を持っているかを確認することができる。
【0042】
そして、残高があると判断されれば、アドミッションサーバー110は、リース要請したデータをキャッシュサーバー140に返還しながら注文についての情報もともに伝達することができる。以下でより詳細に敍述するキャッシュサーバー140は、前記注文情報を獲得するとともに、データベース150に記憶されたユーザーのオーダーブックに注文を記録することができる。また、アドミッションサーバー110は、注文情報をキャッシュサーバー140に伝達しながら自分の識別子(例えば、サーバーID)もともに伝達してサーバーの識別子がデータベース150に記憶されるようにすることができる。
【0043】
そして、アドミッションサーバー110は、外部システム(図示せず)に注文に対する結果値を伝達することができる。
【0044】
また、アドミッションサーバー110は、注文をマッチングサーバー120にキューイング(queuing)することができる。
【0045】
上述したアドミッションサーバー110は一つ以上のインスタンス(instance)で具現することができ、インスタンスを増加させながらスケールアウト(scale−out)することができる。
【0046】
一実施例によるマッチングサーバー120は、キューイングされた注文をマッチングして取引対を生成する。
【0047】
すなわち、マッチングサーバー120は、アドミッションサーバー110から注文を獲得することができ、獲得された注文を互いにマッチングし、取引が締結できると判断されれば、締結可能な注文対を取引対としてコミットサーバー130に伝達することができる。後述するコミットサーバー130は取引対についての情報をデータベース150に記録することができる。これにより、マッチングサーバー120が直接締結される取引対を処理するためにデータベース150にアクセスしなくても良く、これはマッチングサーバー120で発生し得るI/O瓶首効果を最小化する。
【0048】
マッチングサーバー120は、取引対を生成すれば、前記取引対に含まれた注文をキューから削除することができる。
【0049】
また、マッチングサーバー120は、取引対が締結されたことについての情報である締結情報をストップオーダーサーバー160に伝達することができる。ここで、締結情報はコミットサーバー130から受信でき、コミットサーバー130はマッチングサーバー120から伝達された締結要請に応答して締結情報をマッチングサーバー120に伝達することができる。
【0050】
一方、マッチングサーバー120は、アドミッションサーバー110に障害があることを感知することができ、アドミッションサーバー110に障害があると判断すれば、データベース150のオーダーブックでアドミッションサーバー110のサーバー識別子を有する注文のうち自分が知っていない注文をアドミッションサーバー110が伝達したもののように処理するためにキューイングさせることができる。
【0051】
また、マッチングサーバー120は、コミットサーバー130に障害があることを感知することができ、コミットサーバー130に障害があると判断すれば、コミットサーバー130から承認を受けることができなかった注文に対してデータベース150上のオーダーブックとトランザクション履歴を参考して、データベース150上に処理が完了したかを判断し、完了していなければ他のコミットサーバーに前記注文を処理するように要請することができる。
【0052】
上述したマッチングサーバー120は一つ以上のインスタンスで具現されることができ、一つ以上のインスタンスの中で一つのインスタンスをマスター(master)に選定し、アドミッションサーバー110から注文をキューイングされ、コミットサーバー130と通信しながら注文を処理するようにすることができる。
【0053】
ここで、インスタンスが複数であれば、前記複数のインスタンスは物理的に区分されたサーバーごとに組み込まれるか一つの物理的サーバーに組み込まれることができる。したがって、インスタンスがマスターインスタンスに選定されれば、前記インスタンスに対応する物理的なサーバーがマッチングサーバーとして動作し、前記物理的なサーバーは障害が発生したサーバーと異なるか同じサーバーであり得る。好ましくは、障害に柔軟に対応するために、インスタンス別に異なる物理サーバーに位置することができる。
【0054】
一方、マスターに選定されたインスタンス以外のインスタンスはスレーブ(slave)に設定することができる。ここで、マスターインスタンスに障害が生じてマッチングサーバー120として動作することができなければ、スレーブインスタンスの一つがマスターインスタンスになることができる。仮想貨幣取引の特性上、取引が順次締結されることを考慮すれば、一つのマッチングサーバーのみ動作しなければならないが、マッチングサーバーに発生し得る障害に対する対処のために複数のインスタンスの中で一つのインスタンスのみがマッチングサーバーとして動作するようにすることができる。
【0055】
ここで、一つ以上のインスタンスの中でマスターインスタンスを選定する方法は多様であり得る。
【0056】
一実施例によれば、スレーブインスタンスの中でランダムに選択されたスレーブインスタンスがマスターインスタンスになることができる。
【0057】
また、他の実施例によれば、スレーブインスタンスの中で一番先にマッチングサーバーとして登録されたスレーブインスタンスがマスターインスタンスになることができる。
【0058】
因みに、
図3に示したように、取引システム100はコーディネーション装置170をさらに含むことができる。コーディネーション装置170は、分散型構成サービス、同期化サービス及びネーミングレジストリ(naming registry)の少なくとも一つを提供し、取引システムを構成するサーバー間の情報共有、サーバーの状態チェック又はサーバー間の同期化を遂行することができる。したがって、システムで新しく登録されようとするサーバーはコーディネーション装置170が感知することができ、コーディネーション装置(170)はサーバーを登録することができる。このようなコーディネーション装置(170)は、例えばアパッチズーキーパー(apache zookeeper)で具現可能であり、あるいはアパッチズーキーパーと置換可能な任意のソリューションでも具現可能である。
【0059】
したがって、例えば、スレーブインスタンスの中で先にコーディネーション装置(170)にマッチングサーバーとして登録したインスタンスがマスターインスタンスになることができる。
【0060】
上述した例によってマスターインスタンスが変更されれば、新しくマスターになるマッチングサーバーはコミットサーバー130に直前のマスターインスタンスから締結要請を受けたが締結できなかった状態の取引対があれば、前記取引対を締結して応答することを要請することができる。前記要請に応じてコミットサーバー130は締結されなかった取引対を締結して新しいマスターインスタンスに応答することができる。その後、新しいマスターインスタンスはデータベース150上のオーダーブックに記録された注文を参照して、以前マスターインスタンスが処理することができなかった注文を復旧することができる。復旧しているうちに新しいマスターインスタンスはアドミッションサーバー110から新しい注文を受信することができ、新しい注文はペンディングされていて、処理することができなかった注文が復旧完了した後、復旧した注文と重複しなければ、キューイングされることができる。
【0061】
一方、一実施例によるコミットサーバー130は、マッチングサーバー120から獲得された取引対に対して締結処理を行う。
【0062】
すなわち、コミットサーバー130は、マッチングサーバー120から取引対を受信して締結処理しながら、締結結果によって、更新されたデータをキャッシュサーバー140を介してデータベース150に記録することができる。
【0063】
コミットサーバー130は、取引対締結のためのユーザーデータに対し、キャッシュサーバー140にリース要請することによって獲得することができる。獲得したユーザーデータを用いて、コミットサーバー130は取引対に含まれた注文に対応するユーザーが前記注文を処理するための残高を持っているかを確認することができる。このように処理することにより、アドミッションサーバー110の確認後に変更されたかも知れないユーザーの残高を再び確認することができる。
【0064】
そして、残高があると判断されれば、コミットサーバー130は、リース要請したデータをキャッシュサーバー140に返還しながら、キャッシュサーバー140を介してデータベース150に記憶されたユーザーのオーダーブックに記録された注文情報を削除し、残高についての情報を変更することができる。
【0065】
コミットサーバー130は、締結処理が成功すれば、締結情報をマッチングサーバー120に伝達することができる。
【0066】
コミットサーバー130は、マッチングサーバー120との通信を介して、取引対の締結要請を受信するか締結処理の成功を承認しながら応答することができ、よってマッチングサーバー120がコミットサーバー130の障害を感知することができる。例えば、マッチングサーバー120が取引対についての締結要請を伝達したが前記要請に対する承認を受けることができなければ、コミットサーバー130に障害が発生したことを感知することができる。コミットサーバー130に障害が発生することを感知すれば、マッチングサーバー120は承認を受けることができなかった注文に対し、データベース150上のオーダーブックとトランザクション履歴を参考してデータベース150上に処理が完了したかを判断し、完了しなかったら、他のコミットサーバーに前記注文の処理を要請することができる。
【0067】
コミットサーバー130は、マッチングサーバー120と非同期方式で通信することができ、また一つ以上のインスタンスで具現できるので、インスタンスを増加させながらスケールアウト(scale−out)することができる。
【0068】
一方、一実施例によるキャッシュサーバー(cache server)140は、アドミッションサーバー110、マッチングサーバー120、コミットサーバー130又はストップオーダーサーバー160とデータベース150との間に位置して、アドミッションサーバー110、マッチングサーバー120、コミットサーバー130又はストップオーダーサーバー160がデータベース150に直接アクセスしないようにする。
【0069】
キャッシュサーバー140は、ユーザーデータの要請を受けたとき、前記ユーザーデータをキャッシングしていなければ、前記ユーザーデータをデータベース150から獲得してキャッシングすることができる。
【0070】
キャッシュサーバー140は、アドミッションサーバー110又はコミットサーバー130がオーダーブックに記録/削除の要請をするか、あるいはユーザーデータを更新するか要請するとき、キャッシングされたデータを更新するかデータベース150のデータを更新することができる。
【0071】
キャッシュサーバー140は、データベース150への反映が完了したデータに対してはトランザクション履歴に追加することによって管理することができ、好ましくはデータ更新とアトミック(atomic)にトランザクション履歴を管理することができる。
【0072】
キャッシュサーバー140はデータに対してリース要請を受けることができる。例えば、アドミッションサーバー110、コミットサーバー130又はストップオーダーサーバー160からリース要請を受けることができる。ただ、キャッシュサーバー140はデータに対してロック要請を受けることもできる。
【0073】
キャッシュサーバー140は、リース要請されたデータを管理することができる。したがって、キャッシュサーバー140に障害が発生するとき、アドミッションサーバー110は注文の識別子に対応するデータがオーダーブックにあるかを確認し、コミットサーバー130はトランザクション履歴を参照して注文が存在するかを確認する。確認の後、アドミッションサーバー110又はコミットサーバー130はまたリース要請することにより、障害が復旧されたキャッシュサーバー140が前記要請に応じて動作することができる。
【0074】
キャッシュサーバー140は、I/Oによる瓶首効果を無くすために、シャーディング(sharding)を支援することができる。
【0075】
また、キャッシュサーバー140は、更新されるデータの遺失を防止するために、ライトスルー(write−through)方式で動作することができる。
【0076】
一実施例によるデータベース150は取引システム100の動作に必要なデータを記憶する。
【0077】
例えば、データベース150はユーザーデータを記憶することができる。例えば、ユーザーの残高についての情報、ユーザーのオーダーブックなどを記憶することができる。
【0078】
一方、
図2を参照すると、一実施例による取引システム100は、追加的にストップオーダーサーバー160をさらに含むことができる。
【0079】
一実施例によるストップオーダーサーバー160は‘ストップ取引’の注文を受けたときに動作することができる。
【0080】
アドミッションサーバー110の獲得した注文が‘ストップ取引’の場合、ストップオーダーサーバー160はアドミッションサーバー110から注文を受信することができる。
【0081】
ストップオーダーサーバー160は注文を記憶していながら前記注文をデータベースに記録することができる。
【0082】
また、ストップオーダーサーバー160は、注文が取引に処理できる条件が満たされれば、前記注文を‘指定価取引’注文又は‘市場価取引’注文に変更してアドミッションサーバー110に伝達することができる。
【0083】
すなわち、ストップオーダーサーバー160は、注文を獲得すれば、注文にマッチングするユーザーのユーザーデータをキャッシュサーバー140にリース要請することによって獲得することができ、獲得したユーザーデータを用いて、注文に対応するユーザーが前記注文を処理するための残高を持っているかを確認することができる。残高があると判断されれば、ストップオーダーサーバー160は注文の処理が可能であると判断することができ、アドミッションサーバー110に応答を送り、リース要請したデータをキャッシュサーバー140に返還しながら、データベース150に記憶されたユーザーのオーダーブックに注文情報を記録することができる。また、ストップオーダーサーバー160は、マッチングサーバー120から締結情報を獲得して特定条件が満たされたかを判断することができる。特定の条件が満たされたと判断されれば、ストップオーダーサーバー160は‘ストップ取引’の注文を‘指定価取引’又は‘市場価取引’の注文に変更してアドミッションサーバー110に伝達することができる。
【0084】
上述したストップオーダーサーバー160は一つ以上のインスタンスで具現されることができ、一つ以上のインスタンスの中で一つのインスタンスをマスターに選定し、アドミッションサーバー110から注文を受けて処理できるようにすることができる。
【0085】
したがって、マスターに選定されることができなかったインスタンスはスレーブに設定される。このとき、マスターインスタンスに障害が生じてストップオーダーサーバー160として動作することができなければ、スレーブインスタンスの中で一つがマスターインスタンスになることができる。
【0086】
ここで、一つ以上のインスタンスの中でマスターインスタンスを選定する方法は多様であり得るが、スレーブインスタンスの中でランダムに選択されたスレーブインスタンスがマスターインスタンスになるか、スレーブインスタンスの中で一番先にストップオーダーサーバーとして登録されたインスタンスがマスターインスタンスになることができる。
【0087】
上述したアドミッションサーバー110、マッチングサーバー120、コミットサーバー130、キャッシュサーバー140及びストップオーダーサーバー160のそれぞれは制御部(図示せず)、通信部(図示せず)及びメモリ(図示せず)を含むことができる。
【0088】
制御部(図示せず)は装置の全体的な動作を制御し、CPUなどのプロセッサを含むことができる。例えば、制御部(図示せず)は、メモリ(図示せず)に記憶されたプログラムを実行させるか、メモリ(図示せず)に記憶されたデータを読み取るか、新しいデータをメモリに記憶することもできる。
【0089】
通信部(図示せず)は他のデバイス又はネットワークと有無線通信を行うことができる。このために、通信部(図示せず)は多様な有無線通信方法の少なくとも一つを支援する通信モジュールを含むことができる。例えば、通信モジュールはチップセット(chipset)の形態に具現できる。
【0090】
通信部(図示せず)が支援する無線通信は、例えばWi−Fi(Wireless Fidelity)、Wi−Fi Direct、ブルートゥース(登録商標)(Bluetooth(登録商標))、UWB(Ultra Wide Band)又はNFC(Near Field Communication)などであってもよい。また、通信部が支援する有線通信は、例えばUSB又はHDMI(登録商標)(High Definition Multimedia Interface)などであってもよい。
【0091】
通信部(図示せず)は有無線通信方法によってRPC(remote procedure call)通信することができ、RPC情報はコーディネーション装置170に記憶できる。コーディネーション装置170は、新しいサーバーの登録時、RPC情報を獲得してRPCチャネルを生成することにより、システム内の他のサーバーが新しいサーバーの登録を認知するようにすることができ、RPCチャネルが切れることからサーバーに障害があることを判断するようにすることができる。
【0092】
メモリ(図示せず)には、ファイル、アプリケーション及びプログラムなどの多様な種類のデータが組み込まれて記憶されることができる。制御部(図示せず)はメモリ(図示せず)に記憶されたデータに接近してこれを用いるか、あるいは新しいデータをメモリ(図示せず)に記憶することもできる。また、制御部(図示せず)はメモリ(図示せず)に組み込まれたプログラムを実行することもできる。例えば、メモリ(図示せず)には仮想貨幣取引方法を遂行するためのプログラムが組み込まれることができる。
【0093】
一方、取引システム100は、追加的に取引システム100の動作をモニタリングすることができるダッシュボードサーバー(図示せず)をさらに含むことができる。
【0094】
また、取引システム100は、追加的に取引システム100を管理する管理サーバー(図示せず)をさらに含むことができる。管理サーバー(図示せず)は、管理用APIを処理することができ、例えば、取引所システムの動作を中止させるか、新しい貨幣の追加、既存貨幣の削除、交換可能対象貨幣の追加(ビットコインを購買しようとするとき、ビットコインを購買することができる貨幣の種類を追加すること)などの動作を遂行するとき、他のサーバーを制御することができる。ダッシュボードサーバー又は管理サーバーのそれぞれはシステムを構成する他のサーバーと通信することができる。
【0095】
一方、
図4〜
図6は一実施例による仮想貨幣取引方法を説明するためのフローチャートである。
【0096】
図4〜
図6に示した実施例による取引方法は、
図1〜
図3に示した取引システム100で時系列的に処理される段階を含む。よって、以下で省略した内容であると言っても、
図1〜
図3に示した取引システム100について以上で記述した内容は
図4〜
図6に示した実施例による取引方法にも適用可能である。
【0097】
図4に示したように、アドミッションサーバー110は、外部システム(図示せず)から注文を獲得することができ、前記注文の種類を区分することができる(S401)。注文の種類を区分したアドミッションサーバー110は、注文が‘市場価取引’又は‘指定価取引’であれば、前記注文のためのユーザーの残高程度を確認するために、キャッシュサーバー140にユーザーデータをリース要請することができる(S402)。ユーザーに残高があって注文が処理可能であることが確認されれば(S403)、アドミッションサーバー110はリース要請したデータをキャッシュサーバー140に返還しながら注文についての情報もともに伝達することができる(S404)。注文情報を受信したキャッシュサーバー140は自分がキャッシングしたユーザーデータを更新しながら、データベース150に記憶されたユーザーのオーダーブックに注文を記録することができる(S405)。その後、アドミッションサーバー110は外部システム(図示せず)に注文に対する結果値を伝達することができる(S406)。したがって、仮にアドミッションサーバー110に障害が発生すれば、外部システムは注文に対する結果値を獲得することができないので、外部システムはアドミッションサーバー110の障害発生を感知して注文を再要請することができる。
【0098】
その後、アドミッションサーバー110は注文をマッチングサーバー120にキューイングすることができる(S407)。仮に、アドミッションサーバー110の障害が発生すれば、前記障害をマッチングサーバー120はRPCで感知することができ、データベース150に記憶された注文情報を読んで来て注文が処理できるようにすることができる。
【0099】
一方、マッチングサーバー120は、キューイングされた注文をマッチングして取引対を生成し(S408)、取引対をコミットサーバー130に伝達することができる(S409)。コミットサーバー130は、マッチングサーバー120から獲得した取引対に対して締結処理を遂行し、このためにキャッシュサーバー140にユーザーデータをリース要請することができる(S410)。コミットサーバー(130)は、取引対処理のための残高があると判断されれば(S411)、リース要請したデータをキャッシュサーバー140に返還しながら、キャッシュサーバー140にキャッシングされた注文情報を削除し、残高についての情報を変更することによってユーザーデータを更新することができる(S412)。そして、キャッシュサーバー140もデータベース150に記憶されたユーザーのオーダーブックに記録された注文情報を削除してユーザーデータを更新し、トランザクション履歴に取引対処理についての情報を追加することができる(S413)。
【0100】
一方、段階S401で、アドミッションサーバー110が外部システム(図示せず)から注文を獲得したとき、前記注文が‘ストップ取引’であれば、
図5で各段階を遂行した後、
図4の段階S402に進むことができる。
【0101】
すなわち、アドミッションサーバー110はストップ取引である注文をストップオーダーサーバー160に伝達することができる(S501)。注文を受信したストップオーダーサーバー160は、前記注文のためのユーザーの残高程度を確認するために、キャッシュサーバー140にユーザーデータをリース要請することができる(S502)。ユーザーに残高があって注文が処理可能であることが確認されれば(S503)、ストップオーダーサーバー160は、キャッシュサーバー140を介して(S504)、データベース150に注文を記録することができる(S505)。そして、ストップオーダーサーバー160はアドミッションサーバー110に注文要請に対する応答を伝達することができる(S506)。
【0102】
その後、ストップオーダーサーバー160はマッチングサーバー120から締結情報を実時間で受けることができ(S507)、締結情報に基づいてストップ取引の特定の条件が満たされることを判断すれば(S508)、ストップ取引を指定価取引又は市場価取引の少なくとも一つに変換してアドミッションサーバー110に伝達することができる(S509)。前記変換された注文はアドミッションサーバー110に伝達され、取引システム100は段階402〜段階413の各段階を実行することができる。
【0103】
一方、取引システム100はコーディネーション装置170をさらに含み、マッチングサーバー120の障害を感知すれば、コーディネーション装置170にとって新しいマッチングサーバー120が動作するようにして、順次処理されるべき仮想貨幣取引を正確に処理するようにする。
【0104】
すなわち、
図6に示したように、取引システム100は一つ以上のスレーブインスタンスを浮かべることができる。したがって、取引システム100がマッチングサーバーの障害を感知すれば(S610)、一つ以上のスレーブインスタンスの中で一つを選択することができる(S620)。このとき、選択されるインスタンスは、一番先に登録を要請したインスタンスであるか、ランダムに選択されたインスタンスであり得る。取引システム100は、選択されたインスタンスをマスターインスタンスにして新しいマッチングサーバーとして動作するようにすることができ、障害が発生した既存のマスターサーバーは動作を中断させることができる(S630)。
【0105】
上述したように、新しいマッチングサーバーが取引システム100に登録されれば、新規に登録されたマッチングサーバーは、障害が発生した障害マッチングサーバーによって過去に要請された締結要請に対する応答をコミットサーバー130から獲得することにより、要請された締結要請の処理が完了したことを確認することができる。その後、新規のマッチングサーバーは、障害マッチングサーバーがキューイング又は取引対を生成したが処理することができなかった注文をデータベース150から復旧することができる。コミットサーバー130から締結要請に対する応答を受信するかデータベース150から注文を復旧するうち、新規のマッチングサーバーはアドミッションサーバー110からの注文をペンディングし、障害マッチングサーバーによって処理することができなかった注文をデータベースから復旧することを完了すれば、ペンディングされた注文をキューイングすることができる。
【0106】
以上の実施例で使われる‘〜部’という用語はソフトウェア又はFPGA(field programmable gate array)又はASICのようなハードウェア構成要素を意味し、‘〜部’はある役割をする。しかし、‘〜部’はソフトウェア又はハードウェアに限定される意味ではない。‘〜部’はアドレス可能な記憶媒体にあるように構成されることもでき、一つ又はそれ以上のプロセッサを再生させるように構成されることもできる。よって、一例として、‘〜部’はソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラム特許コードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。
【0107】
構成要素及び‘〜部’内で提供される機能はより小さな数の構成要素及び‘〜部’と結合するか追加的な構成要素及び‘〜部’から分離されることができる。
【0108】
それだけでなく、構成要素及び’〜部’はデバイス又は保安マルチメディアカード内の一つ又はそれ以上のCPUを再生させるように具現されることもできる。
【0109】
図4〜
図6に基づいて説明した実施例による取引方法は、コンピュータによって実行可能な命令語及びデータを記憶する、コンピュータ可読の媒体の形態にも具現されることができる。ここで、命令語及びデータはプログラムコードの形態として記憶されることができ、プロセッサによって実行されたとき、所定のプログラムモジュールを生成して所定の動作を行うことができる。また、コンピュータ可読の媒体はコンピュータによってアクセス可能な任意の可用媒体であってもよく、揮発性及び非揮発性媒体、分離型及び非分離型媒体のいずれも含む。また、コンピュータ可読の媒体はコンピュータ記録媒体であってもよい。コンピュータ記録媒体はコンピュータ可読の命令語、データ構造、プログラムモジュール又はその他のデータのような情報の記憶のための任意の方法又は技術によって具現された揮発性及び非揮発性、分離型及び非分離型媒体のいずれも含むことができる。例えば、コンピュータ記録媒体は、HDD及びSSDなどのマグネチック記憶媒体、CD、DVD及びブルーレイディスクなどの光学的記録媒体、又はネットワークを介して接近可能なサーバーに含まれるメモリであってもよい。
【0110】
また、
図4〜
図6に基づいて説明した実施例による取引方法はコンピュータによって実行可能な命令語を含むコンピュータプログラム(又はコンピュータプログラム商品)で具現されることもできる。コンピュータプログラムはプロセッサによって処理されるプログラミング可能な機械命令語を含み、高レベルプログラミング言語(High−level Programming Language)、オブジェクト指向プログラミング言語(Object−oriented Programming Language)、アセンブリー言語又は機械言語などで具現されることができる。また、コンピュータプログラムは類型のコンピュータ判読可能記録媒体(例えば、メモリ、ハードディスク、磁気/光学媒体又はSSD(Solid−State Drive)など)に記録できる。
【0111】
したがって、
図4〜
図6に基づいて説明した実施例による取引方法は上述したようなコンピュータプログラムがコンピュータ装置によって実行されることによって具現されることができる。コンピュータ装置は、プロセッサと、メモリと、記憶装置と、メモリ及び高速拡張ポートに接続している高速インターフェースと、低速バスと記憶装置に接続している低速インターフェースの少なくとも一部を含むことができる。このような成分のそれぞれは多様なバスを用いて互いに接続されており、共通マザーボードに搭載されるか他の適切な方式で装着できる。
【0112】
ここで、プロセッサはコンピュータ装置内で命令語を処理することができる。このような命令語としては、例えば高速インターフェースに接続されたディスプレイのように外部入力及び出力装置上にGUI(Graphic User Interface)を提供するためのグラフィック情報を表示するためにメモリ又は記憶装置に記憶された命令語を有することができる。他の実施例として、多数のプロセッサ及び/又は多数のバスが適切に多数のメモリ及びメモリ形態と一緒に用いられることができる。また、プロセッサは独立的な多数のアナログ及び/又はデジタルプロセッサを含むチップからなるチップセットで具現されることができる。
【0113】
また、メモリはコンピュータ装置内に情報を記憶する。一例として、メモリは揮発性メモリユニット又はそれらの集合で構成されることができる。他の例として、メモリは不揮発性メモリユニット又はそれらの集合で構成されることができる。また、メモリは、例えば磁気又は光ディスクのような他の形態のコンピュータ可読の媒体であってもよい。
【0114】
そして、記憶装置はコンピュータ装置に大容量の記憶空間を提供することができる。記憶装置はコンピュータ可読の媒体であるかこのような媒体を含む構成であってもよく、例えばSAN(Storage Area Network)内の装置又は他の構成も含むことができ、フロッピーディスク装置、ハードディスク装置、光ディスク装置、又はテープ装置、フラッシュメモリー、それと類似した他の半導体メモリ装置又は装置アレイであってもよい。
【0115】
上述した実施例は例示のためのものであり、上述した実施例が属する技術分野の通常の知識を有する者は上述した実施例が有する技術的思想又は必須な特徴を変更しなくて他の具体的な形態に易しく変形可能であることを理解することができるであろう。したがって、上述した実施例は全ての面で例示的なもので、限定的なものではないことを理解しなければならない。例えば、単一型として説明されている各構成要素は分散されて実施されることもでき、同様に分散されたものとして説明されている構成要素も結合された形態に実施されることができる。
【0116】
本明細書によって保護を受けようとする範囲は前記詳細な説明よりは後述する特許請求範囲によって決定され、特許請求範囲の意味及び範囲とその均等な概念から導出される全ての変更又は変形の形態を含むものに解釈されなければならない。