Twemproxyキャッシュエージェントサーバ
8549 ワード
Twemproxyキャッシュエージェントサーバ
Twemproxyの概要
Twemproxy(nutcrackerとも呼ばれる)は、バックエンドキャッシュサーバへの接続数を減らすために主に使用される軽量レベルのRedisおよびMemcachedエージェントです.TwemproxyはTwitterからオープンソースされたキャッシュサーバクラスタ管理ツールで、主にRedis/Memcachedのクラスタ管理の不足を補うために使用されています.
antirez(Redis著者)はtwemproxyの紹介を書いたことがある.彼はtwemproxyが現在のRedisスライス管理の最良の方案であると考えている.antirezのRedis clusterは実現中であり、それに期待をかけているが、既存のcluster実現からはclusterはRedisの複雑さを増加させる以外に、クラスタの管理にtwemproxyからの軽量さと有効さはないと考えている.
クラスタ管理といえば、データのスライス管理(shard)と言わざるを得ません.データの増加と拡張性を満たすために、データストレージシステムは一般的に、従来のMySQLのように横分割テーブルと縦分割テーブルを行い、アプリケーションが正しい場所にアクセスするには正しいテーブルを探す必要があります.この場合、このデータの指向性作業には一般的に3つの位置があります.データストレージシステム自体がサポートされており、Redis Clusterは典型的にデータストレージシステム上でスライスをサポートしようとしている. クライアントのサポート、Memcachedのクライアントのスライスに対するサポートはクライアントレベルである. エージェントサポート、twemproxyはサーバ側とクライアントの間にエージェントサポートを構築しようとしています.
3つのシナリオでは、
1、クライアントスキームは適切ではないと思います.これは、各クライアントが一定のサーバ情報を維持する必要があるためですが、ノードを動的に増加または減少させるには、各クライアントの構成を書き換える必要があります.
2、サーバ側でクラスタ管理を増やすことは使用者に有利であり、使用者が理解しなければならないものを減らし、クラスタ管理を統合することで他の方案よりも性能が高いが、欠点はコードの複雑度を深刻に増加させ、サーバ側のコードが爆発することである.
3、中間層エージェントを採用する方式は最も優雅で有効だと思います.サーバー側のプログラムを変更しない場合、twemproxyはクラスタ管理をより簡単にし、サポートされていない操作と合併を除去すると同時に、複数のバックエンドサービスをサポートし、接続数を大幅に減らすことができます.しかし、欠点も明らかです.マルチキー演算や範囲検索操作など、クラスタの優位性をより効果的に利用することはできません.これは、サーバ側のプログラム自体のサポートが必要です.
Twemproxyインストール
ソースからインストール:
twemproxyコマンドラインオプション:
-h,–help:ヘルプドキュメントの表示,コマンドオプションの表示-V,–version:nutcrackerバージョンの表示-t,–test-conf:構成スクリプトの正確性のテスト-d,–daemonize:デーモンで実行-D,–describe-stats:印刷状態記述-v,–verbosity=N:ログレベルの設定(default:5,min:0,max:11)-o,–output=S:ログ出力パスの設定,デフォルトは標準エラー出力(default:stderr)-c,-conf-file=S:プロファイルパス(default:conf/nutcracker.yml)-s、–stats-port=N:ステータスモニタポートの設定、デフォルト22222(default:22222)-a、–stats-addr=S:ステータスモニタIPの設定、デフォルト0.0.0.0(default:0.0.0.0)-i、–stats-interval=N:ステータス集約間隔の設定(default:30000 msec)-p、–pid-file=S:プロセスpidファイルパスの指定、デフォルトクローズ(default:off)-m、-mbuf-size=N:mbufブロックサイズを設定し、デフォルト64 K、意味は以下のゼロコピーを参照してください.
ゼロコピー(Zero Copy)はtwemproxyで、要求と応答はmbufというメモリに割り当てられ、要求を受信したmbufはbackendに転送するために同時に使用され、同様にbackendから応答を受信したmbufはclientに転送するためにも使用され、メモリコピーを回避する.また、mbufはメモリプールを使用し、割り当てが完了すると解放されなくなり、リクエストが終了すると、使用したmbufはメモリプールに戻されます.1つのmbufは16 Kを占め、このサイズはI/O性能と接続コンカレント数の間で取捨選択する必要があり、mbufサイズが大きいほどsocketの読み書きシステムへの呼び出し回数は少なくなるが、システム全体でサポートできるコンカレント数も小さくなる.より高いクライアント同時リクエスト数をサポートする場合は、mbufのサイズを小さく設定できます(-mオプション).
Twemproxy構成
TwemproxyはYAMLファイルで構成されています.たとえば、次のようになります.
説明:
Listen twemproxyはアドレスを傍受し、UNIXドメインソケットをサポートする.
hashが選択できるkey値のhashアルゴリズム: one_at_a_time md5 crc16 crc32 (crc32 implementation compatible with libmemcached) crc32a (correct crc32 implementation as per the spec) fnv1_64 fnv1a_64、デフォルトオプション fnv1_32 fnv1a_32 hsieh murmur jenkins
hash_tag hash_tagは、keyの一部に基づいてkeyのhash値を計算することを可能にする.hash_tagは2文字で構成され、1つはhash_tagの始まり、もう一つはhash_tagの終わりはhash_tagの開始と終了の間は、keyのhash値の計算に使用される部分であり、計算結果はサーバの選択に使用されます.
例:hash_の場合tagは「{}」と定義され、key値は「user:{user 1}:ids」および「user:{user 1}:tweets」のhash値が「user 1」に基づいており、最終的には同じサーバにマッピングされる.一方、「user:user 1:ids」はkey全体を使用してhashを計算し、異なるサーバにマッピングされる可能性があります.
distributionにはketama、modula、randomの3つのオプションの構成があります.その意味は以下の通りです. ketama,コンシステンシhashアルゴリズムは,サーバに基づいてhash ringを構築し,ring上のノードにhash範囲を割り当てる.ketamaの利点は、単一のノードが追加、削除された後、クラスタ全体でキャッシュされたkey値を最大限に再利用できることです. modulaは、key値のhash値に基づいて型を取り、型取りの結果に基づいて対応するサーバを選択する. randomは、key値のhashが何であるかにかかわらず、key値操作のターゲットとしてサーバをランダムに選択する.
timeout
単位はミリ秒で、serverに接続されたタイムアウト値です.デフォルトは永続的な待機です.
backlogはTCPのbacklog(接続待ちキュー)の長さをリスニングし、デフォルトは512です.
preconnectはboolean値で、twemproxyがpoolのserverにプリコネクションすべきかどうかを示します.デフォルトはfalseです.
redisはboolean値であり、サーバの通信プロトコルがredisであるかmemcachedであるかを識別するために使用されます.デフォルトはfalseです.
server_Connectionsサーバごとに開くことができる接続数.デフォルトでは、各サーバに接続があります.
auto_eject_hostsはboolean値で、twemproxyがserverの接続状態に基づいてクラスタを再構築すべきかどうかを制御します.この接続ステータスはserver_failure_limitバルブ値で制御します.デフォルトはfalseです.
server_retry_timeout単位はミリ秒で、auto_でサーバ接続の時間間隔を制御します.eject_hostがtrueに設定されたときに作用します.デフォルトは30000ミリ秒です.
server_failure_Limitは、auto_でサーバに接続する回数を制御します.eject_hostがtrueに設定されたときに作用します.デフォルトは2です.
servers poolのサーバのアドレス、ポート、および重みのリスト.オプションのサーバの名前が含まれます.サーバの名前が指定されると、サーバの順序が決定され、対応するコンシステンシhashのhash ringが提供されます.そうでない場合、serverで定義された順序が使用されます.
Twemproxyモニタ
Twemproxyモニタポートのデフォルトは22222で、30 sおきに情報が収集されます.
レポートの情報は次のとおりです.
Pipelining
Twemproxyは、多くのclient側の要求を同時に受信し、1つまたは複数の接続のみを介してソースに戻すことができ、このような構造は、ストリームラインを用いて要求および応答を処理し、TCP往復時間を節約するのに適している.たとえば、Twemproxyは、「get keyr'、'set key 0 0 3rvalr'、'delete keyr'」の3つのクライアント側のリクエストを同時にエージェントしています.Twemproxyは、この3つのリクエストをバックエンドのredis:'get keyrset key 0 0 3rvalrdelete keyr'にパッケージ化することができます.
pipeliningもTwemproxyの高性能の原因の一つです.
Twemproxyの概要
Twemproxy(nutcrackerとも呼ばれる)は、バックエンドキャッシュサーバへの接続数を減らすために主に使用される軽量レベルのRedisおよびMemcachedエージェントです.TwemproxyはTwitterからオープンソースされたキャッシュサーバクラスタ管理ツールで、主にRedis/Memcachedのクラスタ管理の不足を補うために使用されています.
antirez(Redis著者)はtwemproxyの紹介を書いたことがある.彼はtwemproxyが現在のRedisスライス管理の最良の方案であると考えている.antirezのRedis clusterは実現中であり、それに期待をかけているが、既存のcluster実現からはclusterはRedisの複雑さを増加させる以外に、クラスタの管理にtwemproxyからの軽量さと有効さはないと考えている.
クラスタ管理といえば、データのスライス管理(shard)と言わざるを得ません.データの増加と拡張性を満たすために、データストレージシステムは一般的に、従来のMySQLのように横分割テーブルと縦分割テーブルを行い、アプリケーションが正しい場所にアクセスするには正しいテーブルを探す必要があります.この場合、このデータの指向性作業には一般的に3つの位置があります.
3つのシナリオでは、
1、クライアントスキームは適切ではないと思います.これは、各クライアントが一定のサーバ情報を維持する必要があるためですが、ノードを動的に増加または減少させるには、各クライアントの構成を書き換える必要があります.
2、サーバ側でクラスタ管理を増やすことは使用者に有利であり、使用者が理解しなければならないものを減らし、クラスタ管理を統合することで他の方案よりも性能が高いが、欠点はコードの複雑度を深刻に増加させ、サーバ側のコードが爆発することである.
3、中間層エージェントを採用する方式は最も優雅で有効だと思います.サーバー側のプログラムを変更しない場合、twemproxyはクラスタ管理をより簡単にし、サポートされていない操作と合併を除去すると同時に、複数のバックエンドサービスをサポートし、接続数を大幅に減らすことができます.しかし、欠点も明らかです.マルチキー演算や範囲検索操作など、クラスタの優位性をより効果的に利用することはできません.これは、サーバ側のプログラム自体のサポートが必要です.
Twemproxyインストール
ソースからインストール:
git clone [email protected]:twitter/twemproxy.git
cd twemproxy
autoreconf -fvi
./configure --enable-debug=full
make
src/nutcracker -htwemproxyコマンドラインオプション:
Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
[-c conf file] [-s stats port] [-a stats addr]
[-i stats interval] [-p pid file] [-m mbuf size]-h,–help:ヘルプドキュメントの表示,コマンドオプションの表示-V,–version:nutcrackerバージョンの表示-t,–test-conf:構成スクリプトの正確性のテスト-d,–daemonize:デーモンで実行-D,–describe-stats:印刷状態記述-v,–verbosity=N:ログレベルの設定(default:5,min:0,max:11)-o,–output=S:ログ出力パスの設定,デフォルトは標準エラー出力(default:stderr)-c,-conf-file=S:プロファイルパス(default:conf/nutcracker.yml)-s、–stats-port=N:ステータスモニタポートの設定、デフォルト22222(default:22222)-a、–stats-addr=S:ステータスモニタIPの設定、デフォルト0.0.0.0(default:0.0.0.0)-i、–stats-interval=N:ステータス集約間隔の設定(default:30000 msec)-p、–pid-file=S:プロセスpidファイルパスの指定、デフォルトクローズ(default:off)-m、-mbuf-size=N:mbufブロックサイズを設定し、デフォルト64 K、意味は以下のゼロコピーを参照してください.
ゼロコピー(Zero Copy)はtwemproxyで、要求と応答はmbufというメモリに割り当てられ、要求を受信したmbufはbackendに転送するために同時に使用され、同様にbackendから応答を受信したmbufはclientに転送するためにも使用され、メモリコピーを回避する.また、mbufはメモリプールを使用し、割り当てが完了すると解放されなくなり、リクエストが終了すると、使用したmbufはメモリプールに戻されます.1つのmbufは16 Kを占め、このサイズはI/O性能と接続コンカレント数の間で取捨選択する必要があり、mbufサイズが大きいほどsocketの読み書きシステムへの呼び出し回数は少なくなるが、システム全体でサポートできるコンカレント数も小さくなる.より高いクライアント同時リクエスト数をサポートする場合は、mbufのサイズを小さく設定できます(-mオプション).
Twemproxy構成
TwemproxyはYAMLファイルで構成されています.たとえば、次のようになります.
alpha:
listen: 127.0.0.1:22121
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 127.0.0.1:6379:1
beta:
listen: 127.0.0.1:22122
hash: fnv1a_64
hash_tag: "{}"
distribution: ketama
auto_eject_hosts: false
timeout: 400
redis: true
servers:
- 127.0.0.1:6380:1 server1
- 127.0.0.1:6381:1 server2
- 127.0.0.1:6382:1 server3
- 127.0.0.1:6383:1 server4
gamma:
listen: 127.0.0.1:22123
hash: fnv1a_64
distribution: ketama
timeout: 400
backlog: 1024
preconnect: true
auto_eject_hosts: true
server_retry_timeout: 2000
server_failure_limit: 3
servers:
- 127.0.0.1:11212:1
- 127.0.0.1:11213:1
delta:
listen: 127.0.0.1:22124
hash: fnv1a_64
distribution: ketama
timeout: 100
auto_eject_hosts: true
server_retry_timeout: 2000
server_failure_limit: 1
servers:
- 127.0.0.1:11214:1
- 127.0.0.1:11215:1
- 127.0.0.1:11216:1
- 127.0.0.1:11217:1
- 127.0.0.1:11218:1
- 127.0.0.1:11219:1
- 127.0.0.1:11220:1
- 127.0.0.1:11221:1
- 127.0.0.1:11222:1
- 127.0.0.1:11223:1
omega:
listen: /tmp/gamma
hash: hsieh
distribution: ketama
auto_eject_hosts: false
servers:
- 127.0.0.1:11214:100000
- 127.0.0.1:11215:1説明:
Listen twemproxyはアドレスを傍受し、UNIXドメインソケットをサポートする.
hashが選択できるkey値のhashアルゴリズム:
hash_tag hash_tagは、keyの一部に基づいてkeyのhash値を計算することを可能にする.hash_tagは2文字で構成され、1つはhash_tagの始まり、もう一つはhash_tagの終わりはhash_tagの開始と終了の間は、keyのhash値の計算に使用される部分であり、計算結果はサーバの選択に使用されます.
例:hash_の場合tagは「{}」と定義され、key値は「user:{user 1}:ids」および「user:{user 1}:tweets」のhash値が「user 1」に基づいており、最終的には同じサーバにマッピングされる.一方、「user:user 1:ids」はkey全体を使用してhashを計算し、異なるサーバにマッピングされる可能性があります.
distributionにはketama、modula、randomの3つのオプションの構成があります.その意味は以下の通りです.
timeout
単位はミリ秒で、serverに接続されたタイムアウト値です.デフォルトは永続的な待機です.
backlogはTCPのbacklog(接続待ちキュー)の長さをリスニングし、デフォルトは512です.
preconnectはboolean値で、twemproxyがpoolのserverにプリコネクションすべきかどうかを示します.デフォルトはfalseです.
redisはboolean値であり、サーバの通信プロトコルがredisであるかmemcachedであるかを識別するために使用されます.デフォルトはfalseです.
server_Connectionsサーバごとに開くことができる接続数.デフォルトでは、各サーバに接続があります.
auto_eject_hostsはboolean値で、twemproxyがserverの接続状態に基づいてクラスタを再構築すべきかどうかを制御します.この接続ステータスはserver_failure_limitバルブ値で制御します.デフォルトはfalseです.
server_retry_timeout単位はミリ秒で、auto_でサーバ接続の時間間隔を制御します.eject_hostがtrueに設定されたときに作用します.デフォルトは30000ミリ秒です.
server_failure_Limitは、auto_でサーバに接続する回数を制御します.eject_hostがtrueに設定されたときに作用します.デフォルトは2です.
servers poolのサーバのアドレス、ポート、および重みのリスト.オプションのサーバの名前が含まれます.サーバの名前が指定されると、サーバの順序が決定され、対応するコンシステンシhashのhash ringが提供されます.そうでない場合、serverで定義された順序が使用されます.
Twemproxyモニタ
Twemproxyモニタポートのデフォルトは22222で、30 sおきに情報が収集されます.
nutcracker --describe-statsレポートの情報は次のとおりです.
pool stats:
client_eof "# eof on client connections"
client_err "# errors on client connections"
client_connections "# active client connections"
server_ejects "# times backend server was ejected"
forward_error "# times we encountered a forwarding error"
fragments "# fragments created from a multi-vector request"
server stats:
server_eof "# eof on server connections"
server_err "# errors on server connections"
server_timedout "# timeouts on server connections"
server_connections "# active server connections"
requests "# requests"
request_bytes "total request bytes"
responses "# responses"
response_bytes "total response bytes"
in_queue "# requests in incoming queue"
in_queue_bytes "current request bytes in incoming queue"
out_queue "# requests in outgoing queue"
out_queue_bytes "current request bytes in outgoing queue"Pipelining
Twemproxyは、多くのclient側の要求を同時に受信し、1つまたは複数の接続のみを介してソースに戻すことができ、このような構造は、ストリームラインを用いて要求および応答を処理し、TCP往復時間を節約するのに適している.たとえば、Twemproxyは、「get keyr'、'set key 0 0 3rvalr'、'delete keyr'」の3つのクライアント側のリクエストを同時にエージェントしています.Twemproxyは、この3つのリクエストをバックエンドのredis:'get keyrset key 0 0 3rvalrdelete keyr'にパッケージ化することができます.
pipeliningもTwemproxyの高性能の原因の一つです.