0

これは、重複するものではなく、this problemを解決する別の方法です。複数のクライアントの同期にSQL Serverデータベースの時間を使用できますか?

私はAzureの役割をreprocess data in case of sudden failuresにします。私は以下のオプションを考えます。

処理するデータブロックごとにデータベーステーブルの行があり、「処理ノードからの最後のpingの時間」を意味する列を追加できます。したがって、ノードが処理のためにデータブロックをつかむと、それは「処理中」の状態とその時間を「現在の時間」に設定し、ノードの責任はその時間を更新することです。次に、定期的に、あるノードが「処理状態と10分を超えるピング時間を持つすべてのブロック」を要求し、それらのブロックを放棄し、何らかの理由でそれらを再処理のために待ち行列に入れます。

私は非常に深刻な懸念があります。上記のアプローチは、ノードがほぼ同じ時間を有することを必要とする。私は地球規模の時間について仮定するべきではないように見えます。

しかし、すべてのノードが非常に同じデータベースと通信します。もし私がそのデータベースを使用すると、GETUTCDATE()のような機能をSQLリクエストで実行すると、私は計画したのと全く同じことをしますが、ノード時間が同期しているかどうかは気にしません。

データベース時間関数を使用すると、このアプローチは確実に機能しますか?

答えて

1

一般的なルールとして、このアプローチが有効です。現在の時刻のソースが1つしかない場合は、時刻同期の問題は影響を与えません。

しかし、データベースサーバーがダウンするとどうなるか考えなければなりません。 Azureは、別のラックの別のサーバ上の別のコピーに切り替えることができます。このデータベースサーバは、少なくとも元のサーバとの時間的な同期は保証されていません。

データベースをスケールアウトしなければならない場合でも、この方法も間違いなく困ってしまいます。

私はまだキューベースのアプローチを好むと思います。

関連する問題