Redis开发与运维. 3.2 Redis Shell

    xiaoxiao2024-04-19  3

    3.2 Redis Shell

    Redis提供了redis-cli、redis-server、redis-benchmark等Shell工具。它们虽然比较简单,但是麻雀虽小五脏俱全,有时可以很巧妙地解决一些问题。

    3.2.1 redis-cli详解

    第1章曾介绍过redis-cli,包括-h、-p参数,但是除了这些参数,还有很多有用的参数,要了解redis-cli的全部参数,可以执行redis-cli -help命令来进行查看,下面将对一些重要参数的含义以及使用场景进行说明。

    1.?-r

    -r(repeat)选项代表将命令执行多次,例如下面操作将会执行三次ping命令:

    redis-cli -r 3 ping

    PONG

    PONG

    PONG

    2.?-i

    -i(interval)选项代表每隔几秒执行一次命令,但是-i选项必须和-r选项一起使用,下面的操作会每隔1秒执行一次ping命令,一共执行5次:

    $ redis-cli -r 5 -i 1 ping

    PONG

    PONG

    PONG

    PONG

    PONG

    注意-i的单位是秒,不支持毫秒为单位,但是如果想以每隔10毫秒执行一次,可以用-i 0.01,例如:

    $ redis-cli -r 5 -i 0.01 ping

    PONG

    PONG

    PONG

    PONG

    PONG

    例如下面的操作利用-r和-i选项,每隔1秒输出内存的使用量,一共输出100次:

    redis-cli -r 100 -i 1 info | grep used_memory_human

    used_memory_human:2.95G

    used_memory_human:2.95G

    ......................

    used_memory_human:2.94G

    3.?-x

    -x选项代表从标准输入(stdin)读取数据作为redis-cli的最后一个参数,例如下面的操作会将字符串world作为set hello的值:

    $ echo "world" | redis-cli -x set hello

    OK

    4.?-c

    -c(cluster)选项是连接Redis Cluster节点时需要使用的,-c选项可以防止moved和ask异常,有关Redis Cluster将在第10章介绍。

    5.?-a

    如果Redis配置了密码,可以用-a(auth)选项,有了这个选项就不需要手动输入auth命令。

    6.?--scan和--pattern

    --scan选项和--pattern选项用于扫描指定模式的键,相当于使用scan命令。

    7.?--slave

    --slave选项是把当前客户端模拟成当前Redis节点的从节点,可以用来获取当前Redis节点的更新操作,有关于Redis复制将在第6章进行详细介绍。合理的利用这个选项可以记录当前连接Redis节点的一些更新操作,这些更新操作很可能是实际开发业务时需要的

    数据。

    下面开启第一个客户端,使用--slave选项,看到同步已完成:

    $ redis-cli --slave

    SYNC with master, discarding 72 bytes of bulk transfer...

    SYNC done. Logging commands from master.

    再开启另一个客户端做一些更新操作:

    redis-cli

    127.0.0.1:6379> set hello world

    OK

    127.0.0.1:6379> set a b

    OK

    127.0.0.1:6379> incr count

    1

    127.0.0.1:6379> get hello

    "world"

    第一个客户端会收到Redis节点的更新操作:

    redis-cli --slave

    SYNC with master, discarding 72 bytes of bulk transfer...

    SYNC done. Logging commands from master.

    "PING"

    "PING"

    "PING"

    "PING"

    "PING"

    "SELECT","0"

    "set","hello","world"

    "set","a","b"

    "PING"

    "incr","count"

    PING命令是由于主从复制产生的,第6章会对主从复制进行介绍。

    8.?--rdb

    --rdb选项会请求Redis实例生成并发送RDB持久化文件,保存在本地。可使用它做持久化文件的定期备份。有关Redis持久化将在第5章进行详细介绍。

    9.?--pipe

    --pipe选项用于将命令封装成Redis通信协议定义的数据格式,批量发送给Redis执行,有关Redis通信协议将在第4章进行详细介绍,例如下面操作同时执行了set hello world和incr counter两条命令:

    echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\

        n$7\r\ncounter\r\n' | redis-cli --pipe

    10.?--bigkeys

    --bigkeys选项使用scan命令对Redis的键进行采样,从中找到内存占用比较大的键值,这些键可能是系统的瓶颈。

    11.?--eval

    --eval选项用于执行指定Lua脚本,有关Lua脚本的使用将在3.4节介绍。

    12.?--latency

    latency有三个选项,分别是--latency、--latency-history、--latency-dist。它们都可以检测网络延迟,对于Redis的开发和运维非常有帮助。

    (1)--latency

    该选项可以测试客户端到目标Redis的网络延迟,例如当前拓扑结构如图3-4所示。客户端B和Redis在机房B,客户端A在机房A,机房A和机房B是跨地区的。

    客户端B:

    redis-cli -h {machineB} --latency

    min: 0, max: 1, avg: 0.07 (4211 samples)

    客户端A:

    redis-cli -h {machineB} --latency

    min: 0, max: 2, avg: 1.04 (2096 samples)

    可以看到客户端A由于距离Redis比较远,平均网络延迟会稍微高一些。

    (2)--latency-history

    --latency的执行结果只有一条,如果想以分时段的形式了解延迟信息,可以使用--latency-history选项:

    redis-cli -h 10.10.xx.xx --latency-history

    min: 0, max: 1, avg: 0.28 (1330 samples) -- 15.01 seconds range

    min: 0, max: 1, avg: 0.05 (1364 samples) -- 15.01 seconds range

    可以看到延时信息每15秒输出一次,可以通过-i参数控制间隔时间。

    (3)--latency-dist

    该选项会使用统计图表的形式从控制台输出延迟统计信息。

    13.?--stat

    --stat选项可以实时获取Redis的重要统计信息,虽然info命令中的统计信息更全,但是能实时看到一些增量的数据(例如requests)对于Redis的运维还是有一定帮助的,如下所示:

    redis-cli --stat

    ------- data ------ --------------------- load -------------------- - child -

    keys       mem      clients blocked requests            connections         

    2451959    3.43G    1162    0       7426132839 (+0)     1337356    

    2451958    3.42G    1162    0       7426133645 (+806)   1337356    

    2452182    3.43G    1161    0       7426150275 (+1303)  1337356

    14.?--raw和--no-raw

    --no-raw选项是要求命令的返回结果必须是原始的格式,--raw恰恰相反,返回格式化后的结果。

    在Redis中设置一个中文的value:

    $redis-cli set hello "你好"

    OK

    如果正常执行get或者使用--no-raw选项,那么返回的结果是二进制格式:

    $redis-cli get hello

    "\xe4\xbd\xa0\xe5\xa5\xbd"

    ?

    $redis-cli --no-raw get hello

    "\xe4\xbd\xa0\xe5\xa5\xbd"

    如果使用了--raw选项,将会返回中文:

    $redis-cli --raw get hello

    你好

    3.2.2 redis-server详解

    redis-server除了启动Redis外,还有一个--test-memory选项。redis-server --test-memory可以用来检测当前操作系统能否稳定地分配指定容量的内存给Redis,通过这种检测可以有效避免因为内存问题造成Redis崩溃,例如下面操作检测当前操作系统能否提供1G的内存给Redis:

    redis-server --test-memory 1024

    整个内存检测的时间比较长。当输出passed this test时说明内存检测完毕,最后会提示--test-memory只是简单检测,如果有质疑可以使用更加专业的内存检测工具:

    Please keep the test running several minutes per GB of memory.

    Also check http:// www.memtest86.com/ and http:// pyropus.ca/software/memtester/

    ................忽略检测细节................

    Your memory passed this test.

    Please if you are still in doubt use the following two tools:

    1) memtest86: http:// www.memtest86.com/

    2) memtester: http:// pyropus.ca/software/memtester/

    通常无需每次开启Redis实例时都执行--test-memory选项,该功能更偏向于调试和测试,例如,想快速占满机器内存做一些极端条件的测试,这个功能是一个不错的选择。

    3.2.3 redis-benchmark详解

    redis-benchmark可以为Redis做基准性能测试,它提供了很多选项帮助开发和运维人员测试Redis的相关性能,下面分别介绍这些选项。

    1.?-c

    -c(clients)选项代表客户端的并发数量(默认是50)。

    2.?-n <requests>

    -n(num)选项代表客户端请求总量(默认是100?000)。

    例如redis-benchmark -c 100 -n 20000代表100各个客户端同时请求Redis,一共执行20?000次。redis-benchmark会对各类数据结构的命令进行测试,并给出性能指标:

    ====== GET ======

        20000 requests completed in 0.27 seconds

        100 parallel clients

        3 bytes payload

        keep alive: 1

    99.11% <= 1 milliseconds

    100.00% <= 1 milliseconds      

    73529.41 requests per second

    例如上面一共执行了20?000次get操作,在0.27秒完成,每个请求数据量是3个字节,99.11%的命令执行时间小于1毫秒,Redis每秒可以处理73529.41次get请求。

    3.?-q

    -q选项仅仅显示redis-benchmark的requests per second信息,例如:

    $redis-benchmark -c 100 -n 20000 -q

    PING_INLINE: 74349.45 requests per second

    PING_BULK: 68728.52 requests per second

    SET: 71174.38 requests per second

    LRANGE_500 (first 450 elements): 11299.44 requests per second

    LRANGE_600 (first 600 elements): 9319.67 requests per second

    MSET (10 keys): 70671.38 requests per second

    4.?-r

    在一个空的Redis上执行了redis-benchmark会发现只有3个键:

    127.0.0.1:6379> dbsize

    (integer) 3

    127.0.0.1:6379> keys *

    1) "counter:__rand_int__"

    2) "mylist"

    3) "key:__rand_int__"

    如果想向Redis插入更多的键,可以执行使用-r(random)选项,可以向Redis插入更多随机的键。

    $redis-benchmark -c 100 -n 20000 -r 10000

    -r选项会在key、counter键上加一个12位的后缀,-r 10000代表只对后四位做随机处理(-r不是随机数的个数)。例如上面操作后,key的数量和结果结构如下:

    127.0.0.1:6379> dbsize

    (integer) 18641

    127.0.0.1:6379> scan 0

    1) "14336"

    2)  1) "key:000000004580"

        2) "key:000000004519"

        …

       10) "key:000000002113"

    5.?-P

    -P选项代表每个请求pipeline的数据量(默认为1)。

    6.-k <boolean>

    -k选项代表客户端是否使用keepalive,1为使用,0为不使用,默认值为1。

    7.?-t

    -t选项可以对指定命令进行基准测试。

    redis-benchmark -t get,set -q

    SET: 98619.32 requests per second

    GET: 97560.98 requests per second

    8.?--csv

    --csv选项会将结果按照csv格式输出,便于后续处理,如导出到Excel等。

    redis-benchmark -t get,set --csv

    "SET","81300.81"

    "GET","79051.38"

    3.3 Pipeline

    3.3.1 Pipeline概念

    Redis客户端执行一条命令分为如下四个过程:

    1)发送命令

    2)命令排队

    3)命令执行

    4)返回结果

    其中1)+4)称为Round Trip Time(RTT,往返时间)。

    Redis提供了批量操作命令(例如mget、mset等),有效地节约RTT。但大部分命令是不支持批量操作的,例如要执行n次hgetall命令,并没有mhgetall命令存在,需要消耗n次RTT。Redis的客户端和服务端可能部署在不同的机器上。例如客户端在北京,Redis服务端在上海,两地直线距离约为1300公里,那么1次RTT时间=1300 ×2/(300000×2/3)=

    13毫秒(光在真空中传输速度为每秒30万公里,这里假设光纤为光速的2/3),那么客户端在1秒内大约只能执行80次左右的命令,这个和Redis的高并发高吞吐特性背道而驰。

    Pipeline(流水线)机制能改善上面这类问题,它能将一组Redis命令进行组装,通过一次RTT传输给Redis,再将这组Redis命令的执行结果按顺序返回给客户端,图3-5为没有使用Pipeline执行了n条命令,整个过程需要n次RTT。

    图3-6为使用Pipeline执行了n次命令,整个过程需要1次RTT。

    Pipeline并不是什么新的技术或机制,很多技术上都使用过。而且RTT在不同网络环境下会有不同,例如同机房和同机器会比较快,跨机房跨地区会比较慢。Redis命令真正执行的时间通常在微秒级别,所以才会有Redis性能瓶颈是网络这样的说法。

    redis-cli的--pipe选项实际上就是使用Pipeline机制,例如下面操作将set hello world和incr counter两条命令组装:

    echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\

        n$7\r\ncounter\r\n' | redis-cli --pipe

    但大部分开发人员更倾向于使用高级语言客户端中的Pipeline,目前大部分Redis客户端都支持Pipeline,第4章我们将介绍如何通过Java的Redis客户端Jedis使用Pipeline功能。

    3.3.2 性能测试

    表3-1给出了在不同网络环境下非Pipeline和Pipeline执行10000次set操作的效果,可以得到如下两个结论:

    Pipeline执行速度一般比逐条执行要快。

    客户端和服务端的网络延时越大,Pipeline的效果越明显。

     

    图3-6 使用Pipeline执行n条命令模型

    因测试环境不同可能得到的具体数字不尽相同,本测试Pipeline每次携带100条

    命令。

    表3-1 在不同网络下,10000条set非Pipeline和Pipeline的执行时间对比

    网  络         延  迟         非Pipeline        Pipeline

    本机         0.17ms     573ms      134ms

    内网服务器     0.41ms     1?610ms 240ms

    异地机房         7ms 78?499ms        1?104ms

     

    3.3.3 原生批量命令与Pipeline对比

    可以使用Pipeline模拟出批量操作的效果,但是在使用时要注意它与原生批量命令的区别,具体包含以下几点:

    原生批量命令是原子的,Pipeline是非原子的。

    原生批量命令是一个命令对应多个key,Pipeline支持多个命令。

    原生批量命令是Redis服务端支持实现的,而Pipeline需要服务端和客户端的共同实现。

    3.3.4 最佳实践

    Pipeline虽然好用,但是每次Pipeline组装的命令个数不能没有节制,否则一次组装Pipeline数据量过大,一方面会增加客户端的等待时间,另一方面会造成一定的网络阻塞,可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成。

    Pipeline只能操作一个Redis实例,但是即使在分布式Redis场景中,也可以作为批量操作的重要优化手段,具体细节见第11章。

    最新回复(0)