redis基础知识

特点

内存+磁盘的持久化保存
具有非常丰富的数据类型，尤其擅长数组类数据的高速度处理
数据快照
自带的主从复制
丰富的数据类型
字符串
链表
集合
有序集合
散列表

适用场景
时间线应用

得益于链表的高速实现
对数组形式数据频繁添加和删除

不限于常规数组，包括链表，有向集合

安装

centos 上 : yum install redis

windows 下载安装，网上教程很多。

启动及配置

我是用windows 时配置文件中有一项

# On Windows, daemonize and pidfile are not supported.

# However, you can run redis as a Windows service, and specify a logfile.

# The logfile will contain the pid.

说明在windows中不支撑守护进程程（后台启动）的方式启动，但可以注册为woindows的后服务程序，因为我没有这个需求，所以没有去进一步的折腾。

常用配置

基本配置说明

n 参考http://blog.csdn.net/willability/article/details/7676384

windows启动

启动服务端：打开一个cmd窗口使用cd命令切换目录到redis安装目录，运行redis-server.exe启动redis.

启动客户端：打开另一个cmd窗口使用cd命令切换目录到redis安装目录运行redis-cli.exe -h 127.0.0.1 -p 6379，其中的-h和-p是可以省略的，保持默认。

退出 quit

常用命令及操作

set a 1 a 为键，1 为值

set b [1,2,3,4,5] value为列表。

setex c 5 3 表示5秒过期时间

get a 取数

lpush data foo 向链表data 左向push一个值foo

zadd sets 1 abc 向有向集体中增加值第一个参数是位置，第二个参数是值。

zadd set 2 bcd

zrange sets 0 -1 第一个参数表示取数开头的位置，0就从开始取。，第一个参数是取数结尾的位置，-1表示取到最后

redis记录点击数

INCR visits:635:totals 自增长visits:635:totals

INCR visits:635:totals

get visits:635:totals 得到结果是2.

查看当前系统所有的数据

可以使用正则表达式的表达式

keys *

keys h*llo

keys h?llo

key h[ae]llo

Redis的主从复制

一、设置配置文件

把conf文件复制两份，一份改名为redis.windows-master.conf，里面以默认配置就行，另一份改名为redis.windows-service.conf，里面改两个地方，1 ，port 改为6389（因为默认是6379，已经被master占用，）另一个方是：# slaveof <masterip> <masterport> 在这一行的下边加一行 slaveof 127.0.0.1 6379 (也就是master服务器的地址和端口 )

二、启动

启动master redis-server.exe redis.windows-master.conf

启动slave redis-server.exe redis.windows-slave.conf

也就是带上配置文件启动，这样启动的两个服务器用的是两个不同的配置文件

三、验证

连接master redis-cli.exe -h 127.0.0.1 -p 6379

插入数据rpush data value1

连接slave redis-cli.exe -h 127.0.0.1 -p 6389

取数 lrange data 0 -1 也能得到数据，说明自动实现了主从复制。

Redis的持久化

快照（snapshot）

设置一个触发条件，当这个触发条件满足时，redis 就往硬盘中写入数据。触发时间可以是时间，也可时是修改的数量，甚至是手工触发条件。所保存的文件一般是以rdo作为后缀（文件类型名）。如果你当前进程关闭或宕机了，当你下一次打开redis时，他们把这个数据重新装回内存。装载回存是一次完成的。

快照原理

Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性 rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。

同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。

我们可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到 Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。

优点：

对相同变量只保存最后一次的最终结果

缺点：

快照备份不是实时的，所以可能丢失数据

运行redis时是一次全部写入到内存，对IO操作的性能影响很大，

设置配置文件
# save ""
save 900 1 # 900秒内有一次修改就save
save 300 10 #300秒内有10次修改就save
save 60 10000 # 60 秒内有10000次修改就save
rdbcompression yes 表示是否压缩，默认为yes
dbfilename dump.rdb 表示备份文件名字
# Note that you must specify a directory here, not a file name.

dir ./ 表示日志文件存放的目录，注意的是所选的目录一定要有写权限
# requirepass foobared 表示在连接等操作时是否需要口令，默认是关闭的。
appendonly no 表示是否只使用appendonly，默认是no
slowlog-log-slower-than 10000 记录执行时间长于10000毫秒的命令

动态修改配置参数
config get * 列出所有配置项
config set time out 280 动态的把timeout的值设为280 这样就不用重新启动

AOF（Append Only File）仅追加日志

记录全部对数据改写的命令，如果你当前进程关闭或宕机了，当你下一次打开redis时，redis就会重写执行这写日志文件的命令。

优点：

记录所有数据，所以不会丢失数据。写入时不是一次性全部写入，对IO影响较小

缺点：

如果同一变量修改多次，那么会记住所有的修改，这样就可能执行很多次才能得到最终结果，装载速度变慢。解决办法是让redis在一定条件下合并日志，这样就可以把前面无用的日志过滤掉，但是合并日志也会消耗大量的性能。

设置配置文件

appendonly yes

特点
启动装载 AOF优先于RDB

源码如下：
RDB性能优于AOF，因为里面没有重复
Redis一次性将数据加载到内存中，一次性预热

AOF rewrite

重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的 rename命令用新的 AOF文件取代老的AOF文件。

VM （虚拟内存 2.4版之后就已经去掉了）

在未打开VM的情况下，Redis的数据全部装入内存，将受限于内存的大小打开VM后，Redis把全部Key放入内存，热Value也装进内存，冷Value放在磁盘的交换文件

配置

常见性能问题：

写快照产生阻塞

写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务

、采用主从复制，Master不写快照，slave去写

、使用bgsave

AOF引发的问题

AOF持续写入，产生阻塞的可能较小

AOF重写对性能影响很大，会引发服务暂停响应。但不重写，AOF太大，影响启动装载数据速度

将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题，设置为yes表示 rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入。最好是不开启Master的AOF备份功能

内存瓶颈

maxmemory <bytes> 设置最大使用内存，当内存达到这个最大值时，redis就会抛弃旧的变量。可以用算法设置抛弃那种变量。

主从复制阻塞

Redis主从复制的性能问题，第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb 文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master 将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于磁盘io的限制，如果Master快照文件比较大，那么dump会耗费比较长的时间，这个过程中Master可能无法响应请求，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。

巴特西

redis基础知识

最新文章

热门文章