7

私の質問は memcached に関するものです。Facebook は、構造化データのキャッシュとして memcached を使用して、ユーザーの待ち時間を短縮しています。Linux で UDP を使用して memcached のパフォーマンスを最適化しました。http://www.facebook.com/note.php?note_id=39391378919

しかし興味深いことに、彼らはまだセット操作に TCP を使用していますが、取得操作には UDP を使用しています。

なぜ彼らはそうするのでしょうか？セット操作にもUDPを使用しないのはなぜですか？UDP は、オペレーティング システムで維持する必要がある状態が少ないため、TCP よりも優れています。

ありがとう、

4

3 に答える 3

5

この文は、問題と解決策をほぼ明らかにしています。

TCP を使用してメモリ効率を改善しましたが、get 操作を UDP に移行して、ネットワーク トラフィックを削減し、マルチ get (数百のキーを並行して取得) 用のアプリケーション レベルのフロー制御を実装しました。

TCP もフロー制御であり、Memcacheマルチ取得の場合はかなりシリアルです。接続を開き（またはプールし）、キーのリストをクエリし、待機してから、すべての値のリストで結果を取得します。代わりに、コネクションレスの並列 UDP getsの上に、アプリケーション レベルのフロー制御自体を実装しました。FBサイズのソフトウェアで見られるUDPの利点は次のとおりです。

  • 接続を開いたり、プールしたり、追加のラウンドトリップ、セッション、ハンドシェイク、キープアライブなどを行う必要はありません。
  • 複数の分散型 Memcache サーバーとインデックスを並行してクエリできます。これは、マイクロサービスの精神とサービスとしての「マイクロキャッシュ」に適しています。
  • UDP パケットをマルチキャストして、冗長性、負荷分散、動的ルーティング、さらにはシャーディングを備えた高可用性を提供できます - 最初の応答が勝ちます!
  • 個々の取得タイムアウトおよび再試行ポリシーは、アプリケーション レベルで実装できます。
  • ロジックは、部分的に完全なデータが利用可能になるとすぐに実行できます。完全なマルチ取得結果を待つ必要はありません。

一方、一貫性のためにTCP経由で書き込みを行うと思います。TCP と memcached は、リクエストが送信され、レスポンスがキャッシュの更新を確認するトランザクションを提供します。UDPでそれを再実装しても、あまりメリットはないと思います。

于 2016-12-17T21:23:59.303 に答える
2

各 UDP データグラムには単純なフレーム ヘッダーが含まれ、その後に上記の TCP プロトコルと同じ形式のデータが続きます。現在の実装では、要求は単一の UDP データグラムに含まれている必要がありますが、応答は複数のデータグラムにまたがる場合があります。(複数のデータグラムにまたがる唯一の一般的な要求は、巨大なマルチキーget要求とset 要求であり、どちらも信頼性の理由から TCP トランスポートに適しています。)

https://github.com/memcached/memcached/blob/master/doc/protocol.txt

于 2013-04-22T14:56:48.493 に答える
0

パケット損失を理解するには、これが最善の方法だと思います。例えばフェイスブックのチャットだと、文が来なかったらわかるけど、Ymsgではわからない。

于 2013-04-21T19:56:41.743 に答える