Redis 笔记系列（四）——redis零散知识杂记

如何测试你的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。