redisテスト

4641 ワード

保存

redis学習の概要
一、redis配置
二、購読発表
1.redis自身のサブスクリプションパブリケーション
Redis従2.Xバージョンから、非永続化メッセージに基づいて、パブリケーション/サブスクリプションモードを使用して実装されるイベント通知メカニズムがサポートされます.クライアントのオフライン再接続後、オフライン中のイベントは再通知されません.

10.15.107.145:7000> PUBLISH channeltestsub testmessage
(integer) 1
10.15.107.145:7000> 


10.15.107.145:7000> SUBSCRIBE channeltestsub
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channeltestsub"
3) (integer) 1
1) "message"
2) "channeltestsub"
3) "testmessage"

2.クラウドプラットフォームによるストレージにおけるkeyの購読
redisのサブスクリプション・パブリケーション・機能に加えて、エージェント、バスなどのインフラストラクチャをカプセル化して完成します.負荷等化とルーティングを総合的に考慮したのかもしれません.
三、redis性能に影響する要素

ネットワーク帯域幅および遅延は、通常、最大のショートボードである.

ローカルNIC帯域幅を表示

[root@localhost ~]# ifconfig
em1: flags=4163  mtu 1500
    inet 10.15.107.179  netmask 255.255.255.0  broadcast 10.15.107.255
    ...
[root@localhost ~]# sudo ethtool em1
    Settings for em1:
    ...
    Speed: 1000Mb/s
    ...

以上のコマンドは、ローカルNICがギガビットの「1000 Mb/s」であることを表示します.

pingを使用してネットワーク帯域幅を大まかに計算する

[root@localhost ~]# ping 10.15.107.115 
PATTERN: 0x190000
PING 10.15.107.115 (10.15.107.115) 56(84) bytes of data.
64 bytes from 10.15.107.115: icmp_seq=1 ttl=64 time=0.625 ms
^C
--- 10.15.107.115 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.625/0.625/0.625/0.000 ms

以上のコマンドによると、ネットワーク速度は64/0.625 bytes/ms=102 Mbps、同理用限界コマンド「ping-f-s 65507 10.15.107.115」で、ネットワーク速度は65506/9.919=6604 Mbps

と推定される.
応用:例えば4 KBの文字列をRedisに押し込んで、スループットは100000 q/sで、それでは実際に3.2 Gbits/sの帯域幅を必要として、だから10 Gbits/sのネットワークの接続を必要として、1 Gbits/sは足りないです

CPUは、シングルスレッドモデルであるため、マルチコアではなく大キャッシュ高速CPUが好きである.Intel CPUを推奨します.ネットワークデータによると、AMD CPUはIntel CPUの半分の性能しかない可能性がある

小さなオブジェクトアクセスではメモリ速度と帯域幅は重要ではないように見えますが、大きなオブジェクト(>10 KB)では重要になります.しかし、通常、Redisを最適化するためにより高性能なメモリモジュールを購入することはありません.

RedisはVM上で遅くなります.相当な仮想マシンを構成するredis-benchmarkのテスト結果は物理マシンより2倍遅く,多くのCPU時間がシステム呼び出しと割り込みに消費される.

ネットワーク接続を使用し、イーサネットネットワークパケットが1500 bytes以下である場合、複数のコマンドをpipeliningにパッケージすると、効率が大幅に向上します.実際、10 bytes 100 bytes,1000 bytesの要求を処理する場合、スループットはあまり差がない.ネットワーク遅延低減実験機器CPU:Intel(R)Xeon(R)CPU E 5-2609 [email protected] GHz実験機器redis_version:3.2.4実験機器mem_allocator:libc (with pipelining) [root@localhost ~]# redis-benchmark -h 10.15.107.115 -p 19000 -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q SET: 17140.46 requests per second GET: 20809.71 requests per second LPUSH: 17288.33 requests per second LPOP: 14601.31 requests per second (without pipelining) [root@localhost ~]# redis-benchmark -h 10.15.107.115 -p 19000 -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 2426.79 requests per second GET: 2121.18 requests per second LPUSH: 3136.17 requests per second LPOP: 3134.62 requests per second

ネットワークを介してredisを読み書きする場合、バッチ(Batch)操作は、Redis自体がtcpベースのRequest/Response protocolモードであるため、wiresharkパケットを使用してredis読み書きプロセスを分析することができるため、多くの性能向上に役立つ.

は、高構成の下で、クライアントの接続数も重要な要素です.epoll/kqueueのおかげで、Redisのイベントループはかなり拡張性があります.Redisは60000を超える接続の下でベンチマークテストを行い、50000 q/sを維持することができます.1つの経験則は、30000の接続数は100接続の半分のスループット

にすぎない.

異なるプラットフォームの下で、Redisは異なるメモリ割り当て方式(libc malloc,jemalloc,tcmalloc)にコンパイルすることができ、彼らは異なる速度、連続および非連続フラグメントの下で異なる表現をすることができる.自分でコンパイルしたRedisでない場合は、INFOコマンドを使用してメモリの割り当て方法を確認できます.ほとんどのベンチマークテストは、異なる割当てパターンの違いを感知するために長時間実行されず、本番環境の下のRedisインスタンスでのみ表示できます.異なるメモリ割り当て方式の比較http://blog.csdn.net/yongche_shi/article/details/54614144

リファレンス記事の接続
四、redisの持続化操作
infoコマンドでPersistenceを表示する

[root@localhost ~]# redis-cli -h 10.15.107.145 -p 7000
10.15.107.145:7000> info Persistence
# Persistence
loading:0 #              
rdb_changes_since_last_save:0 #         rdb  ，       ，              
rdb_bgsave_in_progress:0 #         rdb  
rdb_last_save_time:1510218400 #         rdb      。     -rdb_last_save_time=        rdb  
rdb_last_bgsave_status:ok  #    rdb       
rdb_last_bgsave_time_sec:1 #        rdb      
rdb_current_bgsave_time_sec:-1 #         rdb  ，                        
aof_enabled:0 #     aof
aof_rewrite_in_progress:0 #  aof rewrite        
aof_rewrite_scheduled:0 #rewrite    ，      bgrewriteaof  ，    rewrite       ，         bgrewriteaof      ， aof        rewrite 
aof_last_rewrite_time_sec:-1 #    aof rewrite     
aof_current_rewrite_time_sec:-1 #  rewrite      ，         ，   
aof_last_bgrewrite_status:ok #  bgrewriteaof     
aof_last_write_status:ok #  aof

自分で踏んだ穴:イントラネットテスト環境redisクラスタが構成されていないため、ある停電後に一部のデータが失われた.他の人が踏んだ穴:メモリが急上昇し、出力バッファの大量のデータが詰まっているため

インスタンス間SSH鍵による認証接続[AWS]

Redis Centinelアーキテクチャの原理の詳細(四)