Redis的基础概念以及性能测试

Redis基础概念

Redis是一个开源的NoSql数据库，key-value类型。近些年在互联网界应用较为广泛，其主要特点有

• Redis支持数据持久化，可以将内存中的数据保存到磁盘，当服务宕机重启后，可以将磁盘中保存的数据再次加载并提供服务
• 除了常规的key-value（字符串）类型的数据，Redis还支持list（列表）、set（集合）、zset（有序集合）、hash（散列）等数据结构，并在这些数据结构上提供了一系列方法和元算方法
• Redis支持数据备份，master-salve模式

总体上来说，Redis的主要优点有

• 存取性能高，测试的性能测试读性能160000+次/秒，写性能80000+次/秒
• 支持的数据结构丰富，五种基础数据类型String、list、set、zset、hash等，可以满足业务的各种复杂数据存取
• 原子操作，Redis的所有指令都是原子操作（单一操作指令），当出现多个指令时，可能出现不一致现象
• 事务支持，MULTI、EXEC配合可以实现事务支持，针对多个指令操作时，为了保证数据一致性，可以采用事务
• 丰富的特性，订阅发布机制、通知、Expire等等

性能测试

Redis的一个重要特点是存取性能高，且较为稳定。安装完成后，将借助提供的性能测试工具redis-benchmark进行性能测试，做到心里有数，在实际项目中可以做出粗略的评估，是采用哨兵的单节点，还是分不式部署以便完成更高并发读取官方文档。

# redis-benchmark工具的指令格式，这里只描述了几个常用的参数，更多的查看官方文档
redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]

# -h hostname用于描述要测试连接的主机IP，如果测试本机，可以忽略
# -p 端口，默认为6379，当忽略该参数时，表示连接默认端口为6379
# -c 并发连接的客户端数量，即并发数，默认为50，在实际测试中可以动态调整该参数
# -n 一次并发测试过程中，发起的总请求数，默认为10000
# -k 1:keep alive，0-reconnect，默认为1
# -t 只测试test中描述的指令，缺省该参数时，默认全部命令测试一遍，如 -t set,lpush只测试set、lpush指令
# -q 只测试，静默，不显示输出，只展示测试结果

以下测试的本机硬件基础信息：CPU（8核 Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz）、内存16G。

整体测试

# 100并发，发起100000次请求
redis-benchmark -p 6300 -c 100 -n 100000

====== PING_INLINE ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
147929.00 requests per second

====== PING_BULK ======
  100000 requests completed in 0.69 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
145985.41 requests per second

====== SET ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
147275.41 requests per second

====== GET ======
  100000 requests completed in 0.69 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
145137.88 requests per second

====== INCR ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
146412.88 requests per second

====== LPUSH ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
146198.83 requests per second

====== RPUSH ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
146842.88 requests per second

====== LPOP ======
  100000 requests completed in 0.69 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
145560.41 requests per second

====== RPOP ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
147058.83 requests per second

====== SADD ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
146412.88 requests per second

====== HSET ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
147058.83 requests per second

====== SPOP ======
  100000 requests completed in 0.69 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
145985.41 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

99.95% <= 1 milliseconds
100.00% <= 1 milliseconds
146627.56 requests per second

====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

99.95% <= 1 milliseconds
100.00% <= 1 milliseconds
147058.83 requests per second

====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
148148.14 requests per second

====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
146842.88 requests per second

====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

99.90% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 2 milliseconds
148148.14 requests per second

====== MSET (10 keys) ======
  100000 requests completed in 0.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
147929.00 requests per second

综上，100并发10W次请求，所有指令的处理请求数基本上在14W+的水平。

redis-benchmark -p 6300 -c 1000 -n 100000 -q

PING_INLINE: 122850.12 requests per second
PING_BULK: 126742.72 requests per second
SET: 125156.45 requests per second
GET: 123304.56 requests per second
INCR: 124069.48 requests per second
LPUSH: 121951.22 requests per second
RPUSH: 126582.27 requests per second
LPOP: 125628.14 requests per second
RPOP: 126422.25 requests per second
SADD: 124688.28 requests per second
HSET: 124223.60 requests per second
SPOP: 124223.60 requests per second
LPUSH (needed to benchmark LRANGE): 125313.29 requests per second
LRANGE_100 (first 100 elements): 126103.41 requests per second
LRANGE_300 (first 300 elements): 125156.45 requests per second
LRANGE_500 (first 450 elements): 125313.29 requests per second
LRANGE_600 (first 600 elements): 124069.48 requests per second
MSET (10 keys): 125786.16 requests per second

当并发增长到1000时，其整体处理性能有所下降，在12w+/秒的处理请求水平。

测试部分指令

# 1000并发，100万的请求,只测试set、get指令
redis-benchmark -p 6300 -c 1000 -n 1000000 -t set,get -q

SET: 122654.24 requests per second
GET: 124331.71 requests per second

# 整体性能也在12W+/秒的读写速度