ドキュメントサーバー:同時保存の処理

Question

ドキュメントサーバーを実装しています。現在、2 人のユーザーが同じドキュメントを開いて変更し、変更を保存した場合、ドキュメントの状態は未定義になります (最初のユーザーの変更が永続的に保存されるか、2 番目のユーザーの変更が永続的に保存されます)。これはまったく満足のいくものではありません。この問題を解決するために、次の 2 つの可能性を考えました。

1 つ目は、誰かが初めてドキュメントを開いたときにドキュメントをロックし、閉じたときにロックを解除することです。しかし、サーバーへのネットワーク接続が突然中断されると、ドキュメントは永久にロックされた状態のままになります。明らかな解決策は、定期的に ping をサーバーに送信することです。サーバーが特定のクライアントから連続して K ping (K > 1) を受信しない場合、このクライアントによってロックされているドキュメントのロックが解除されます。そのクライアントが再度表示されると、誰かがまだロックしていなかった場合、ドキュメントは再びロックされます。これは、クライアント アプリケーション (Web ブラウザで実行されている) が予期せず終了し、「終了、ドキュメントのロックを解除」信号をサーバーに送信できなくなった場合にも役立ちます。

2 つ目は、異なるユーザーが保存した同じドキュメントの複数のバージョンを保存することです。ドキュメントへの変更が立て続けに行われた場合、システムはバージョンをマージするか、優先バージョンを選択するかを提案します。ストレージスペースを最適化するには、(ソース管理ソフトウェアと同様に) ドキュメントの差分のみを保持する必要があります。

サーバーへの接続に影響を与える可能性があることを考慮して、どの方法を選択する必要がありますか? 時々 遅くて無反応ですか？パラメーター (ping 間隔、高速連続間隔) はどのように決定すればよいですか?

追伸残念ながら、ドキュメントをデータベースに保存することはできません。

Answer 1

私の提案はあなたの最初の提案のようなものです。最初のユーザー (ボブ) がドキュメントを開くと、他のユーザーは現在のドキュメントのみを読み取ることができるようにロックを取得します。ユーザーがドキュメントを使用中に保存すると、ロックが保持されます。彼が文書を終了した場合にのみ、文書のロックが解除され、他の人が編集できるようになります。

ボブがロックしているときに 2 番目のユーザー (ケイト) が文書を開くと、ケイトは文書が編集できないことを示すメッセージを受け取りますが、ロックが解除されるまでは文書を読むことができます。

それでは、Bob がロックを取得し、おそらくドキュメントを 1 回か 2 回保存した後、ロックがハングしたままアプリケーションを終了すると、何が起こるでしょうか?

あなた自身が言ったように、ロックを持つクライアントに特定の頻度で ping を送信するように要求するのがおそらく最良の選択肢です。一定時間クライアントから ping を受信しない場合、これは事実上、クライアントが応答しなくなったことを意味します。これが Web アプリケーションの場合は、ping に JavaScript を使用できます。最後に保存されたドキュメントのロックが解放され、Kate はそれを取得できるようになります。

ping にはクライアントがロックしているドキュメントの名前を含めることができ、サーバーはそのドキュメントに対する最後の ping がいつ受信されたかを計算できます。

Answer 2

あなたが説明した最初のオプションは本質的に悲観的なロックモデルですが、2番目のオプションは楽観的なモデルです。どちらを選択するかは実際には多くの要因によって決まりますが、本質的にはビジネスがどのように機能したいかによって決まります。たとえば、編集する必要があるドキュメントが別のユーザーによってロックされていた場合、ユーザーは不当に不便になりますか?ドキュメントがロックされており、誰かがクライアントに接続したまま休暇に出た場合はどうなりますか?各文書について考えられる争点は何ですか - つまり同じドキュメントが 2 人のユーザーによって同時に変更される可能性はどのくらいですか?、変更が 1 つのドキュメント内でどの程度局所化される可能性がありますか?(同じセクションが定期的に変更される場合、マージを実行すると、単に変更を再度行うよりも時間がかかることがあります)。

競合が比較的低い、および/または各変更のサイズがかなり小さいと仮定すると、おそらく自動または手動マージを使用して競合を解決する楽観的なモデルを選択するでしょう。ドキュメントのコンテンツのバージョン番号またはチェックサムを使用して、マージが必要かどうかを判断できます。

Answer 3

現在、文書は限られたグループによって公開されており、それぞれが別のテーマに取り組んでいます。したがって、ロックによってもたらされる不便は最小限に抑えられます。ほとんどの場合、既存のドキュメントを拡張し、その間違いを修正します。

悲観的なモデルについて言えば、「クライアントが N 日間接続されたままになる」シナリオは、ロックの有効期限を、たとえばロックの開始日の 1 日前に設定することで回避できます。編集されるドキュメントは決してミッション クリティカルなものではなく、複数のユーザーによって変更されることはめったにないため、これで十分な場合があります。

次に、楽観的なモデルを考えてみましょう。文書に規則的な (たとえば、階層的な) 構造がある場合、差異はどのように検出されるべきでしょうか?そうでない場合は?このような場合、自動マージが成功する可能性はどのくらいでしょうか?

一部のドキュメント (「admins」ユーザー グループによって編集) には重要な構成情報 (ドキュメントのグローバル インデックス、ユーザー ロールなど) が含まれているため、状況はさらに複雑になります。私の考えでは、この種の情報は毎日変更されないため、ロックの方が有利です。したがって、いくつかのハイブリッド ソリューションが受け入れられる可能性があります。

どう思いますか？