FTPサーバーの信頼性
Ftpサーバーが実装されています。マネージャーはそれに信頼性を追加したいと考えています。彼は、サーバーのハードディスクに書き込む前に、受信ストリームを高速で信頼性の高いシステム（hbaseやredisなど）に書き込むことを望んでいます。彼のポイントは、ファイルを保存する前にサーバーがクラッシュした場合（停電など）、信頼できるシステムにそのコピーが1つあるということです。
しかし、この方法は冗長で役に立たないと思います。クライアントファイルを永続化したい場合は、最初にディスクに書き込むだけでよいからです。また、ftpサーバーの速度が低下します（2つの異なる場所にデータを書き込む必要があるため）。
だから私は間違っているのですか、それとも彼は間違っていますか？そして、私が間違っている場合、信頼性バックエンドとして使用するための最良の解決策は何ですか？
それは冗長で役に立たない。
ファイル転送中にサーバーがクラッシュした場合、ファイルはせいぜい半分になります。これは、ほとんどの場合、ファイルがまったくない場合よりもはるかに優れているわけではありません。この構成がcould helpである唯一の状況は、最後のバイトを受信してからディスクに書き込むまでの間にクラッシュが発生する状況です。ファイルを受信しながらディスクにストリーミングしていると仮定します（転送が完了した後にファイルをバッファに保存して書き込むのとは対照的ですが、複数の大きなファイルがにアップロードされるとメモリが使い果たされる可能性があるため、それはばかげています同時に）、ここではミリ秒（SSDではマイクロ秒）について話します。
FTPサーバーにネットワーク経由でSANまたはNASディスクにファイルを保存させることで、その時間枠をさらに短縮できます。これらのシステムのほとんどは、ファイルストリームをそれらをディスクに書き込む前のメモリ。つまり、提案されたメモリ内データベースとほとんど同じように動作します。
この計画は実際にはreduce信頼性になります。これは、hbase/redisを使用すると、システムに別のコンポーネントがあり、障害が発生したりバグが発生したりする可能性があるためです。
しかし、妥協案として提案できるのは次のとおりです。
- 冗長性のために、受信したファイルを複数のファイルの場所に同時に保存する機能。管理者は、必要な数の場所を構成できます。
- Redis/hbaseをファイルの場所として扱うためのアダプター
そうすれば、マネージャーはcouldファイルをredis/hbaseとファイルシステムの両方に書き込む構成をセットアップします（信頼性の観点からは無意味かもしれません）が、賢明な人々は他に2つの便利な機能を利用できます。
- FTPサーバーをオフサイトの場所（オフサイトのバックアップ場所やグローバルコンテンツ配信ネットワークなど）に自動的に複製します
- FTPサーバーをミドルウェアとして使用して、「通常の」ファイルシステムを経由せずに、お気に入りのNoSQLデータベースにファイルを直接ダンプします。これは、FTPのみを話すシステムをNoSQLデータベースと統合する場合に役立ちます。