Redis从入门到精通：初级篇

原文连接：http://www.cnblogs.com/xrq730/p/8890896.html，转载请注明出处，谢谢

 

Redis从入门到精通：初级篇

平时陆陆续续看了很多Redis的文章了，工做中也一直在用Redis，感受是时候对过往Redis的所学进行一次系统性的总结。《Redis从入门到精通》系列会分为初级、中级、高级三篇，从浅入深讲解Redis相关知识点。

在本文中，咱们将看到如下内容：

• Redis简介
• Redis安装、启动
• Redis登陆受权
• Redis配置文件redis.conf中参数详细的一个解读
• Redis性能测试

这些内容无关具体用法，做为一些初级的知识，系统地先认识一下Redis。

 

Redis简介

Redis是一款开源的使用ANSI C语言编写、遵照BSD协议、支持网络、可基于内存也可持久化的日志型、Key-Value高性能数据库。Redis与其余Key-Value缓存产品相比有如下三个特色：

• 支持数据持久化，能够将内存中的数据保存在磁盘中，重启可再次加载使用
• 支持简单的Key-Value类型的数据，同时还提供List、Set、Zset、Hash等数据结构的存储
• 支持数据的备份，即Master-Slave模式的数据备份

同时，咱们再看下Redis有什么优点：

• 读速度为110000次/s，写速度为81000次/s，性能极高
• 具备丰富的数据类型，这个上面已经提过了
• Redis全部操做都是原子的，意思是要么成功执行要么失败彻底不执行，多个操做也支持事务
• 丰富的特性，好比Redis支持publish/subscribe、notify、key过时等

 

Redis安装、启动

此次写Redis系列的文章，LZ特地去阿里云上买了一个月的服务器，操做系统是Linux，由于Redis项目自己不正式支持Windows系统。不过微软开放技术小组开发和维护了Windows版本的Redis，下载地址为https://github.com/MicrosoftArchive/redis/releases，感兴趣的能够本身去试下，LZ在本身笔记本上安装启动过，没有问题，但就不细说了。

下面说一下在Linux系统上安装并启动Redis的步骤（个人Redis安装在/data/component/redis目录下，每一步使用的命令标红加粗）：

• 进入目录，cd /data/component/redis
• 下载Redis，wget http://download.redis.io/releases/redis-3.2.11.tar.gz，能够看到LZ使用的Redis版本是3.2.11，在LZ写这篇文章的时候，Redis最新版本为4.0.9，地址为http://download.redis.io/releases/redis-4.0.9.tar.gz，感兴趣的朋友也能够用这个版本
• 解压下载下来的tar包，tar -zxvf redis-3.2.11.tar.gz，解压完毕的文件夹名称为redis-3.2.11
• 进入redis-3.2.11，cd redis-3.2.11
• 因为咱们下载下来的是源文件，所以使用make命令对源文件进行一个构建，构建完毕咱们会发现src目录下多出了redis-benchmark、redis-check-aof、redis-check-rdb、redis-cli、redis-sentinel、redis-server几个可执行文件，这几个可执行文件后面会说到
• 因为上述几个命令在/data/component/redis/redis-3.2.11/src目录下，为了更方便地使用这几个命令而不须要指定全路径，配置一下环境变量。这里我是以非root用户进行登陆的，所以配置用户变量，先执行cd命令回到初始目录，再vi ./.bash_profile，在path这一行加入PATH=$PATH:$HOME/.local/bin:$HOME/bin:/data/component/redis/redis-3.2.11/src，使用:wq保存并退出
• 使环境变量生效，执行source ./.bash_profile
• 使用redis-server便可启动redis，redis-server /data/component/redis/redis-3.2.11/redis.conf

不过这个时候咱们的启动稍微有点问题，不是后台启动的，即ctrl+c以后Redis就停了：

为了解决这个问题，咱们须要修改一下redis.conf，将Redis设置为以守护进程的方式进行启动，打开redis.conf，找到daemonize，将其设置为yes便可：

这个时候先关闭一下再启动，Redis就在后台自动运行了，关闭Redis有两种方式：

• redis-cli shutdown，这是种安全关闭redis的方式，但这种写法只适用于没有配置密码的场景，比较不安全，配置密码下一部分会讲
• kill -9 pid，这种方式就是强制关闭，可能会形成数据未保存

重启后，咱们可使用ps -ef | grep redis，netstat -ant | grep 6379命令来验证Redis已经启动。

 

Redis登陆受权

上面咱们安装了Redis，但这种方式是很是不安全的，由于没有密码，这样任何链接上Redis服务器的用户均可以对Redis执行操做，因此这一部分咱们来说一下给Redis设置密码。

打开redis.conf，找到"requirepass"部分，打开本来关闭的注释，替换一下本身想要的密码便可：

重启Redis，受权登陆有两种作法：

• 链接的时候直接指定密码，redis-cli -h 127.0.0.1 -p 6379 -a 123456
  
• 链接后受权，redis-cli -h 127.0.0.1 -p 6379，auth 123456

在配置了密码的状况下，没有进行受权，那么对Redis发送的命令，将返回"(error) NOAUTH Authentication required."。

 

Redis配置文件redis.conf

上面两小节，设置使用守护线程启动、设置密码，都须要修改redis.conf，说明redis.conf是Redis核心的配置文件，本小节咱们来看一下redis.conf中一些经常使用配置：

配置	做用	默认
bind	当配置了bind以后： 只有bind指定的ip能够直接访问Redis,这样能够避免将Redis服务暴露于危险的网络环境中，防止一些不安全的人随随便便经过远程访问Redis 若是bind选项为空或0.0.0.0的话，那会接受全部来自于可用网络接口的链接	127.0.0.1
protected-mode	protected-mode是Redis3.2以后的新特性，用于增强Redis的安全管理，当知足如下两种状况时，protected-mode起做用： bind未设置，即接收全部来自网络的链接 密码未设置 当知足以上两种状况且protected-mode=yes的时候，访问Redis将报错，即密码未设置的状况下，无密码访问Redis只能经过安装Redis的本机进行访问	yes
port	Redis访问端口，因为Redis是单线程模型，所以单机开多个Redis进程的时候会修改端口，否则通常使用你们比较熟悉的6379端口就能够了	6379
tcp-backlog	半链接队列的大小，对半链接队列不熟的能够看我之前的文章TCP：三次握手、四次握手、backlog及其余	511
timeout	指定在一个client空闲多少秒以后就关闭它，0表示无论	0
tcp-keepalive	设置tcp协议的keepalive，从Redis的注释来看，这个参数有两个做用： 发现死的链接 从中间网络设备的角度看链接是否存活	300
daemonize	这个前面说过了，指定Redis是否以守护进程的方式启动	no
supervised	这个参数表示能够经过upstart和systemd管理Redis守护进程，这个具体和操做系统相关，资料也不是不少，就暂时无论了	no
pidfile	当Redis以守护进程的方式运行的时候,Redis默认会把pid写到pidfile指定的文件中	/var/run/redis_6379.pid
loglevel	指定Redis的日志级别，Redis自己的日志级别有notice、verbose、notice、warning四种，按照文档的说法，这四种日志级别的区别是： debug，很是多信息，适合开发/测试 verbose，不少不多有用的信息（直译，读着拗口，从上下文理解应该是有用信息很少的意思），但并不像debug级别这么混乱 notice，适度的verbose级别的输出，极可能是生产环境中想要的 warning，只记录很是重要/致命的信息	notice
logfile	配置log文件地址,默认打印在命令行终端的窗口上	""
databases	设置Redis数据库的数量，默认使用0号DB	16
save	把Redis数据保存到磁盘上，这个是在RDB的时候用的，介绍RDB的时候专门说这个	save 900 1 save 300 10 save 60 10000
stop-writes-on-bgsave-error	当启用了RDB且最后一次后台保存数据失败，Redis是否中止接收数据。 这会让用户意识到数据没有正确持久化到磁盘上，不然没有人会注意到灾难（disaster）发生了。 若是Redis重启了，那么又能够从新开始接收数据了	yes
rdbcompression	是否在RBD的时候使用LZF压缩字符串，若是但愿省点CPU，那就设为no，不过no的话数据集可能就比较大	yes
rdbchecksum	是否校验RDB文件，在RDB文件中有一个checksum专门用于校验	yes
dbfilename	dump的文件位置	dump.rdb
dir	Redis工做目录	./
slaveof	主从复制，使用slaveof让一个节点称为某个节点的副本，这个只须要在副本上配置	关闭
masterauth	若是主机使用了requirepass配置进行密码保护，使用这个配置告诉副本链接的时候须要鉴权	关闭
slave-serve-stale-data	当一个Slave与Master失去联系或者复制正在进行中，Slave可能会有两种表现： 若是为yes，Slave仍然会应答客户端请求，但返回的数据多是过期的或者数据多是空的 若是为no，在执行除了INFO、SLAVEOF两个命令以外，都会应答"SYNC with master in progres"错误	yes
slave-read-only	配置Redis的Slave实例是否接受写操做，即Slave是否为只读Redis	yes
slave-priority	从站优先级是能够从redis的INFO命令输出中查到的一个整数。当主站不能正常工做时，redis sentinel使用它来选择一个从站并将它提高为主站。  低优先级的从站被认为更适合于提高，所以若是有三个从站优先级分别是10， 100， 25，sentinel会选择优先级为10的从站，由于它的优先级最低。  然而优先级值为0的从站不能执行主站的角色，所以优先级为0的从站永远不会被redis sentinel提高。	100
requirepass	设置客户端认证密码	关闭
rename-command	命令重命名，对于一些危险命令例如： flushdb（清空数据库） flushall（清空全部记录） config（客户端链接后可配置服务器） keys（客户端链接后可查看全部存在的键）                    做为服务端redis-server，经常须要禁用以上命令来使得服务器更加安全，禁用的具体作法是是： rename-command FLUSHALL "" 也能够保留命令可是不能轻易使用，重命名这个命令便可： rename-command FLUSHALL abcdefg 这样，重启服务器后则须要使用新命令来执行操做，不然服务器会报错unknown command	关闭
maxclients	设置同时链接的最大客户端数量，一旦达到了限制，Redis会关闭全部的新链接并发送一个"max number of clients reached"的错误	关闭，默认10000
maxmemory	不要使用超过指定数量的内存，一旦达到了，Redis会尝试使用驱逐策略来移除键	关闭
maxmemory-policy	当达到了maxmemory以后Redis如何移除数据，有如下的一些策略： volatile-lru，使用LRU算法，移除范围为设置了失效时间的 allkeys-lru，根据LRU算法，移除范围为全部的 volatile-random，使用随机算法，移除范围为设置了失效时间的 allkeys-random，使用随机算法，移除范围为全部的 volatile-ttl，移除最近过时的数据 noeviction，不过时，当写操做的时候返回错误 注意，当写操做且Redis发现没有合适的数据能够移除的时候，将会报错	关闭，noeviction
appendonly	是否开启AOF，关于AOF后面再说	no
appendfilename	AOF文件名称	appendonly.aof
appendfsync	操做系统实际写数据到磁盘的频率，有如下几个选项： always，每次有写操做都进行同步，慢，可是最安全 everysec，对写操做进行累积，每秒同步一次，是一种折衷方案 no，当操做系统flush缓存的时候同步，性能更好可是会有数据丢失的风险 当不肯定是使用哪一种的时候，官方推荐使用everysec，它是速度与数据安全之间的一种折衷方案	everysec
no-appendfsync-on-rewrite	aof持久化机制有一个致命的问题，随着时间推移，aof文件会膨胀，当server重启时严重影响数据库还原时间，所以系统须要按期重写aof文件。 重写aof的机制为bgrewriteaof（另一种被废弃了，就不说了），即在一个子进程中重写从而不阻塞主进程对其余命令的处理，可是这依然有个问题。 bgrewriteaof和主进程写aof，都会操做磁盘，而bgrewriteaof每每涉及大量磁盘操做，这样就会让主进程写aof文件阻塞。 针对上述问题，可使用此时可使用no-appendfsync-on-rewrite参数作一个选择： no，最安全，不丢失数据，可是须要忍受阻塞 yes，数据写入缓冲区，不形成阻塞，可是若是此时redis挂掉就会丢失数据，在Linux操做系统默认设置下，最坏场景下会丢失30秒数据	no
auto-aof-rewrite-percentage	本次aof文件超过上次aof文件该值的百分比时，才会触发rewrite	100
auto-aof-rewrite-min-size	aof文件最小值，只有到达这个值才会触发rewrite，即rewrite由auto-aof-rewrite-percentage+auto-aof-rewrite-min-size共同保证	64mb
aof-load-truncated	redis在以aof方式恢复数据时，对最后一条可能出问题的指令的处理方式：  yes，log并继续 no，直接恢复失败	yes
slowlog-log-slower-than	Redis慢查询的最低条件，单位微妙，即查询时间>这个值的会被记录	10000
slowlog-max-len	Redis存储的慢查询最大条数，超过该值以后会将最先的slowlog剔除	128
lua-time-limit	一个lua脚本执行的最大时间，单位为ms	5000
cluster-enabled	正常来讲Redis实例是没法称为集群的一部分的，只有以集群方式启动的节点才能够。为了让Redis以集群方式启动，就须要此参数。	关闭
cluster-config-file	每一个集群节点应该有本身的配置文件，这个文件是不该该手动修改的，它只能被Redis节点建立且更新，每一个Redis集群节点须要不一样的集群配置文件	关闭，nodes-6379.conf
cluster-node-timeout	集群中一个节点向其余节点发送ping命令时，必须收到回执的毫秒数	关闭，15000
cluster-slave-validity-factor	若是该项设置为0，无论Slave节点和Master节点间失联多久都会一直尝试failover。 好比timeout为5，该值为10，那么Master与Slave之间失联50秒，Slave不会去failover它的Master	关闭，10
cluster-migration-barrier	当一个Master拥有多少个好的Slave时就要割让一个Slave出来。 例如设置为2，表示当一个Master拥有2个可用的Slave时，它的一个Slave会尝试迁移	关闭，1
cluster-require-full-coverage	有节点宕机致使16384个Slot所有被覆盖，整个集群是否中止服务，这个值必定要改成no	关闭，yes

以上把redis.conf里面几乎全部的配置都写了一遍（除了ADVANCED CONFIG部分），感受其余博客不多有看到比我这个还全的了^_^，给你们做为参考吧。

 

Redis性能测试

以前说过Redis在make以后有一个redis-benchmark，这个就是Redis提供用于作性能测试的，它能够用来模拟N个客户端同时发出M个请求。首先看一下redis-benchmark自带的一些参数：

参数	做用	默认值
-h	服务器名称	127.0.0.1
-p	服务器端口	6379
-s	服务器Socket	无
-c	并行链接数	50
-n	请求书	10000
-d	SET/GET值的字节大小	2
-k	1表示keep alive，0表示重连	1
-r	SET/GET/INC使用随机Key而不是常量，在形式上key样子为mykey_ran:000000012456 -r的值决定了value的最大值	无
-p	使用管道请求	1，即不使用管道
-q	安静模式，只显示query/sec值	无
--csv	使用csv格式输出	无
-l	循环，无限运行测试	无
-t	只运行使用逗号分割的命令的测试	无
-I	空闲模式，只打开N个空闲线程而且等待	无

抛开配置只谈性能的都是耍流氓，说一下我买的阿里云服务器的配置：

• 单核CPU，CPU类型为Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
• 内存4G
• 带宽1M
• 操做系统为Centos7

首先咱们运行最简单的redis-benchmark -q，运行结果为：

打印了每一个命令的QPS，看到基本都在读写速度基本都在100000次/s以上。

接着换一个命令进行测试，由于实际场景中咱们的Key和Value必定是很是丰富的，不多是单一的Key和单一的Value，所以接着去的测试使用-r模拟value到100000且将运行次数提升到1000000次，具体命令为redis-benchmark -q -r 100000 -n 1000000，运行结果为：

看到整个读写效率基本都在110000次/s以上，证实了读写的高效率。

简单对于Redis的性能测试就到这儿，这个测试结果看起来很美，可是实际应用却彻底不是，主要体如今如下几点：

• 网络与带宽，这是现实中最主要的影响因素，上面的测试仍是太过于低级，现实使用中Redis里面存一个用户信息、订单信息，几KB的大小，100000qps根本不可能你们能够算算须要多大的带宽，粗粗算一下超过1个G吧，不少线上服务的带宽根本达不到1G/s，因此Redis的吞吐量最早会被网络带宽限制住
• Redis因为是单线程模型，所以CPU性能很是重要，尤为是大缓存的快速CPU，我这里的CPU上面写过了，Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz整体仍是能够的
• 客户端链接数，上面使用了默认的链接数50，实际上10W、20W甚至100W+呢？不过得益于epoll模型，整个降低的能够接受，下面有一张链接数和qps的关系，我也是网上找来的
• RDB和AOF可能会对Redis形成的阻塞并未考虑进去
• 尽量使用大内存，避免SWAP

不管如何，总而言之，Redis整个性能是很是不错的，我的认为若是要选一款存储系统，那么Redis应当是首选。