如何测试你的redis服务的性能
这里要用到redis的一个命令程序redis-benchmark
首先开启redis-server服务。配置文件是什么鬼?不知道看我上一篇博客文章。
[root@localhost bin]# redis-server /myconfigs/redis.conf
[root@localhost bin]#
[root@localhost bin]# ps -ef | grep redis
root 3892 1 0 07:39 ? 00:00:00 redis-server 127.0.0.1:6379
root 3905 3650 0 07:39 pts/0 00:00:00 grep --color=auto redis
[root@localhost bin]#
[root@localhost bin]# redis-benchmark
然后就开始漫长的性能测试:
那么性能测试都测试写什么呢?
redis的五大数据结构,我在后面的博客里再介绍。每个数据结构的都对应了许多命令操作,这些命令操作的性能如何,就是redis-benchmark在redis所在服务器机器上的性能测试结果。
例如,这里,我们看两个命令,就是最近处的键值操作的get和set。我们可以看到在我的VM上,每2.28秒内可以跑100,000次set请求,而跑100,000次get请求只需要1.65秒。
可以看到,redis的性能是非常惊人的,也难过它在高负载、高并发的应用场景中一直扮演着举足轻重的角色。如果你开发一个网站,所有的数据请求全部由mysql直接响应,那你的mysql多半要被高负载场景的大量请求活活压死。有了redis,这些大量的数据请求就会被redis挡在缓存这一级,分担相当的工作。
你不要说1.65秒才十万次,你别忘了,我测试的环境是我的笔记本电脑上开的VM,虚拟内存也只有1G,在真实的服务器上,redis的响应请求的能力更加惊人。
Redis零散知识点罗列
redis是单进程
redis使用单进程模型来处理客户端请求。
对读写等事件的响应是通过linux系统的epoll函数的包装来做到的。简单说,就是为了快速读写,redis实现对读写事件的响应借助了linux系统底层的epoll函数来实现。Epoll是linux内核为处理大批量而做了改进的epoll,是linux下多路复用IO接口select/poll的增强版。它显著提高程序在大量并发连接中只有少量活跃情况下的系统CPU利用率。
Redis默认有16个数据库
redis默认存在了16个数据库,它们可以用dbid进行标识,从0至15。这个数据库的数量可以在配置文件中修改设置。我们打开配置文件:
[admin@localhost bin]$ vi /myconfigs/redis.conf
好,我们默认进入redis-cli时进入的是0号库。如果要切换库,可以用select 【dbid】命令来进行。
比如,我们现在在0号库,发现有k1这个键值对存在,切换到1号库时,k1件就没有值了:
[admin@localhost bin]$ redis-cli -p 6379
127.0.0.1:6379>
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get k1
"happyBKs"
127.0.0.1:6379>
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> get k1
(nil)
127.0.0.1:6379[1]>
127.0.0.1:6379[1]>
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> get k1
"happyBKs"
127.0.0.1:6379>
注意:切到哪个库,命令行上会有[dbid]来标记,如[1]。0号库缺省。
如何查看redis某个数据库中键的个数呢?如何查看包含哪些键呢?
127.0.0.1:6379> DBSIZE
(integer) 4
127.0.0.1:6379> keys *
1) "k1"
2) "mylist"
3) "counter:__rand_int__"
4) "key:__rand_int__"
127.0.0.1:6379>
127.0.0.1:6379>
可以看到,除了我们在上一篇博客中自行设置了一个k1键,还有三个redis默认自带的键。
我们在设置几个键:
127.0.0.1:6379> set k2 22222
OK
127.0.0.1:6379> set k3 33333
OK
127.0.0.1:6379>
127.0.0.1:6379> keys *
1) "key:__rand_int__"
2) "counter:__rand_int__"
3) "k2"
4) "mylist"
5) "k3"
6) "k1"
127.0.0.1:6379> keys k*
1) "key:__rand_int__"
2) "k2"
3) "k3"
4) "k1"
127.0.0.1:6379>
127.0.0.1:6379> set k10 101010101
OK
127.0.0.1:6379> keys k?
1) "k2"
2) "k3"
3) "k1"
127.0.0.1:6379> keys k*
1) "key:__rand_int__"
2) "k2"
3) "k10"
4) "k3"
5) "k1"
127.0.0.1:6379>
如何清空键值对呢?
分为两种,flushdb清空当前所在数据库的所有key;flushall清空所有数据库的所有key。
下面的例子可以看到,我们尝试在1号库建了一个键,然后回到0号库flushdb清空key,再回到1号库发现db1_key1键还在。
27.0.0.1:6379>
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set db1_key1 sdfsadfasd
OK
127.0.0.1:6379[1]> keys *
1) "db1_key1"
127.0.0.1:6379[1]>
127.0.0.1:6379[1]>
127.0.0.1:6379[1]>
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> keys *
1) "key:__rand_int__"
2) "counter:__rand_int__"
3) "k2"
4) "k10"
5) "mylist"
6) "k3"
7) "k1"
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379>
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
1) "db1_key1"
127.0.0.1:6379[1]>
127.0.0.1:6379[1]>
flushall会将所有库都gameover。所以一定要慎用。
127.0.0.1:6379[1]>
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
(empty list or set)
127.0.0.1:6379[1]>
127.0.0.1:6379[1]>
统一密码管理:
在使用redis的时候,并没有让我们输入用户名密码,16个库都同样的密码,要么都可以,要么都连不上。
安全加固应该在系统层面进行加固,redis将能访问redis的用户都默认作为授信用户。当然,redis也可以设置用户密码登录的方式,但是这与偏重于高并发和缓存应用场景十分不相符。
其他
redis索引都是从0开始。
redis默认端口6379。