Redisエージェントとしてtwemproxyを使用する

6723 ワード

シーンの説明を適用する
最近第3のゲームがオンラインになって、ゲームのホットスポットのデータはすべてRedisデータベースが存在します
二twemproxy紹介
Twemproxyはnutcrackerとも呼ばれ、memcachedとredisプロトコルに提供される高速で軽量なエージェントです.バックエンドキャッシュサーバの接続数を減らすために設計されたのが最初です.protocol pipeling and shardingにより、バックエンドのキャッシュアーキテクチャを横方向に拡張できます.
Twemproxyには以下の特性があります.

Fast.

Lightweight.

Maintains persistent server connections.

Keeps connection count on the backend caching servers low.

Enables pipelining of requests and responses.

Supports proxying to multiple servers.

Supports multiple server pools simultaneously.

Shard data automatically across multiple servers.

Implements the complete memcached ascii and redis protocol.

Easy configuration of server pools through a YAML file.

Supports multiple hashing modes including consistent hashing and distribution.

Can be configured to disable nodes on failures.

Observability via stats exposed on the stats monitoring port.

Works with Linux, *BSD, OS X and SmartOS (Solaris)

twemproxyでは、入力されたリクエストと出力された応答はmbufによってメモリが割り当てられます.mbufはゼロコピーzero-copyを実現できる.クライアントから受信したリクエストとバックエンドサーバへのリクエストの転送は同じバッファを使用しているためです.バックエンド・サーバから返された応答を格納し、クライアントに応答を送信するのと同じバッファです.
またmbufのメモリは再利用プールreuse poolによって管理される.すなわちmubfのメモリが割り当てられると、解放されずreuse poolに戻すだけです.mbufのサイズとtwemproxyがサポートできる同時接続の間には、何らかのトレードオフ関係があります.大きなmbufを設定すると、twemproxyがリクエストの読み取りまたは応答時にread syscallを呼び出す数を減らすことができます.しかし、mbufを大きく設定すると、アクティブな接続ごとに16 Kまでのバッファサイズが使用され、twemproxyがクライアントからの同時接続を大量に処理する場合、これは問題になります.twemproxyを使用して大量の同時接続を処理する場合は、-mパラメータを使用して512バイトなどの小さなmbufを設定します.
クライアント接続ごとに少なくとも1つのmbufが消費されます.サービスの1つのリクエストは、クライアントからエージェントへ、もう1つはエージェントからバックエンドserverへの2つの接続を確立する必要があるため、mbufが2つ必要です.
「get foo barr」のようなセグメント化可能な要求に対して、「get foor」と「get barr」にセグメント化することができ、要求に使用されるmbufと応答に使用されるmbufの2つが消費される.したがって、N個のセグメントに分けることができる要求には、N*2個のmbufが必要である.mbuf設計の利点は、割り当てられたメモリがすべて1つのreuse poolから来ていることです.悪い点は、mbufがメモリを割り当てると、空きmbufが常にreuse poolに戻されるため、メモリが解放されないことです.
したがってnutcrackerが1000クライアント要求と100サーバ要求を処理する必要がある場合、nutcrackerは(max(1000100)*2*mbuf-size)サイズのメモリを消費します.クライアントがnon-pipelinedリクエストを送信し、デフォルトmbufサイズ16 Kを設定すると、nutcrackerは32 Mメモリを消費します.
さらに、1つの要求が10個のセグメントに分けることができると、メモリは320 Mに消費され、10 K要求を処理すると、メモリ消費は3.2 Gに達する.デフォルトのmbufサイズ16 Kが適用されず、サイズが512 Kに設定されている場合、nutcrakcerは1000個のリクエストで消費されたメモリを処理します.
1000*2*512*10=10M
これはnutcrackerが大量のクライアントリクエストを処理する必要がある場合やmulti-getリクエストが必要な場合、mbufを512バイトなどの小さな値に設定する必要があるためです.
3 twemproxyインストール使用
からhttps://drive.google.com/folderview?id=0B6pVMMV5F5dfMUdJV25abllhUWM&usp=drive_web
パッケージのダウンロード
tar zxvf nutcracker-0.4.0.tar.gz cd nutcracker-0.4.0
mkdir -p/data/app_platform/twemproxy/conf
mkdir -p/data/app_data/twemproxy/logs/
./configure --prefix=/data/app_platform/twemproxy/ --enable-debug=log
make&make install
cp conf/nutcracker.yml/data/app_platform/twemproxy/conf/
cp scripts/nutcracker.init/etc/init.d/nutcracker
chmod a+x/etc/init.d/nutcracker
useradd nutcracker -s/sbin/nologin
chkconfig --level 35 nutcracker on
chown -R nutcracker/data/app_data/twemproxy/logs/
本番環境ではnutcrakcerのログ機能をオンにすることが望ましい.コンパイル時に--enable-debug=logを付けるとともにnutcrackerを起動する時にログレベルをLOG_に設定する必要がある.INFOすなわち-v 6.
ここでは起動スクリプトで設定します
-d -c/data/app_platform/twemproxy/conf/nutcracker.yml -v 6 -o/data/app_data/twemproxy/logs/nutcrakcer.log
/etc/init.d/nutcrackerの内容は以下の通りです.

#! /bin/sh
#
# chkconfig: - 55 45
# description:  Twitter's twemproxy nutcracker
# processname: nutcracker
# config: /etc/sysconfig/nutcracker

# Source function library.
. /etc/rc.d/init.d/functions

USER="nutcracker"
OPTIONS="-d -c /data/app_platform/twemproxy/conf/nutcracker.yml  -v 6 -o /data/app_data/twemproxy/logs/nutcrakcer.log"

#if [ -f /etc/sysconfig/nutcracker ];then
#    . /etc/sysconfig/nutcracker
#fi

# Check that networking is up.
if [ "$NETWORKING" = "no" ]
then
    exit 0
fi

RETVAL=0
prog="nutcracker"

start () {
    echo -n $"Starting $prog: "
    daemon --user ${USER} /data/app_platform/twemproxy/sbin/${prog} $OPTIONS
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/${prog}
}
stop () {
    echo -n $"Stopping $prog: "
    killproc ${prog}
    RETVAL=$?
    echo
    if [ $RETVAL -eq 0 ] ; then
        rm -f /var/lock/subsys/${prog}
    fi
}

restart () {
    stop
    start
}


# See how we were called.
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  status)
    status ${prog}
    ;;
  restart|reload)
    restart
    ;;
  condrestart)
    [ -f /var/lock/subsys/nutcracker ] && restart || :
    ;;
  *)
    echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
    exit 1
esac

exit $?

twemproxyの構成
/data/app_platform/twemproxy/conf/nutcracker.yml
ソースパッケージのconfディレクトリの下にプロファイルのケースがあります
プロファイルに複数のserver poolを構成できます.各server poolは複数のredisインスタンスを構成できます.

gintama:
  listen: 192.168.100.68:22124
  hash: fnv1a_64
  distribution: ketama
  timeout: 100
  redis: true
  auto_eject_hosts: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
    - 192.168.100.68:6379:1
       - 192.168.100.68:6380:1
       - 192.168.100.68:6381:1
       - 192.168.100.69:6379:1
       - 192.168.100.69:6380:1
       - 192.168.100.69:6381:1

gintamaはserver poolの名前です
Listenが傍受するサーバIPとポートは、/var/run/nutcrackerのようなsocketの絶対パスであってもよい.sock
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値の計算に使用します.
distributionはkey値分布モードを指定し、次の値を指定します.

ketama

modula

random

timeoutバックエンドキャッシュサーバとの接続の確立を待つか、バックエンドキャッシュサーバが応答を返すのを待つタイムアウト時間を設定し、デフォルトでは無線で待機します.
redis redisプロトコルの使用
redis_auth redis検証の使用
auto_eject_hostsはserver_を試したかどうかを設定します.failure_limitが設定された回数後も接続できないサーバはserver poolから一時的に削除されます.
server_retry_timeout一時的に削除されたサーバに再接続しようとするタイムアウト時間を設定します.デフォルトは30000ミリ秒です.
server_failure_Limit連続接続回数が設定された数値に達した場合、このserverをpoolから一時的に削除します.
serversバックエンドキャッシュサーバのIP、ポート、およびウェイトを指定
プロファイル構文のテスト:
/data/app_platform/twemproxy/sbin/nutcracker -t -c/data/app_platform/twemproxy/conf/nutcracker.yml
参照先:
https://github.com/twitter/twemproxy

ページの静的化と擬似静的URLのリダイレクト

[TIL] TypeScript Basic Type