# TSO の割り当て：時間ウィンドウ

![`smart`](TSOTimeWindow_aa_001_20220509.png)

------------------------------------------------------------------------------
最初に解決する必要があるのは、単一のタイムスタンプ生成における単一障害点の問題です。

PDクラスタは、主ノードがダウンした後すぐに新しいLeaderが選出されるように、Raft分散合意アルゴリズムを使用して、タイミングサービスが短期間で回復するようにします。

それから、以前のLeaderのTSOを保存する必要があり、保存も非常に信頼性が高い必要があるため、TiDBはetcdを使用します。 TSOを生成するレートはディスクのIO能力に関連しており、ボトルネックが発生する可能性があります。 TiDBはパフォーマンスの問題を解決するために事前アロケーション時間ウィンドウを使用します。

図に示すように、現在のPD LeaderのTSOは700（これは説明のしやすさのための想定値です）であり、PDはetcdから時間ウィンドウを要求しています。時間ウィンドウの範囲はパラメーターで指定できます。システムのデフォルトの時間ウィンドウ構成は3秒です。

デフォルトの設定を使用しているので、このウィンドウの始点はTSO 700、終点はTSO 703です。etcdが正常に書き込まれた後、PDは700から703までの時間ウィンドウを取得します。この時間ウィンドウ内で、PDはシステムの物理時間を高い位置として使用し、メモリ内に蓄積した論理時間を連結し、クライアントにタイムスタンプを割り当てることができます。

このデザインは、すべてのPD割り当てられたタイムスタンプ、または物理時間の最高点が、etcdに格納された最大値よりも常に小さいことを意味します。そして、PD Leaderがダウンした場合、新しいLeaderはetcdに格納された最大値を読み取り、それに基づいて新しい時間ウィンドウを申請できるため、新しいLeaderは以前のLeaderよりも常に大きなTSOを割り当てることができます。また、通信オーバーヘッドを減らすために、各クライアントは一度に複数のTSOを要求でき、TSOの数はクライアントからPDへのパラメータとして渡されます。

しかし、TSOがクライアントにキャッシュされた後は、複数のクライアント間の時計はもはや厳密な単調増加ではなくなります。