1、设置set k1 v1

2、选择库 select no.

3、删除对应的k-v:  delete k1

4、删除当前库flushdb

5、删除所有库flushall

6、设置key的过期时间：expire keyname seconds

常用数据类型：五大

1、string：简单的k-v对

对value是整型的进行加减，一定要是数字才可以：

INCR k1          递增1

INCRBY k1  3   递增3

DECR k1       

DECRBY k1 3

修改从0位开始的值，v的值会覆盖：setrange k1  0 1111

按区间[n,m]查看value的值：getrange k1   n m

设置k-v，并同时设置过期时间(若k-v已存在，会覆盖)：setex k1 100 v1111

同上，但若k-v已存在，那么操作失败：setnx k1 100 v11111111

批量设置k-v，不管其是否存在：    mset k1 v1 k2 v2

批量设置k-v，如果有一个存在就整个操作失败：    msetnx k1 v1 k2 v2

2、hash：hash表，无序

3、list：双向链表

插入一个或多个元素：lpush listName  1 2 3 4 5

set：hash表，只有key没有value，无序

zset(sorted set)：有序集合，底层实现是跳表

持久化persistence

RDB：将数据库的内存快照以二进制的形式写入磁盘的rdb文件中。

对数据完整性要求不是那么高，对快速备份和恢复比较在意，优先考虑rdb，但有可能会丢失最后一个时间片的数据。

save seconds

AOF：以协议文本的方式记录数据库的每一个写操作，写到AOF文件中去，以此达到记录数据库状态的目的。

配置

开启appendonly yes

策略有三种appendfsync always/appendfsync everysec/appendfsync no

append文件名：ppendfilename "appendonly.aof"

aof文件过大重写：随着aof文件越来越大，超过阈值（默认64   配置auto-aof-rewrite-min-size 64mb auto-aof-rewrite-percentage 100）的时候，redis开始启动文件压缩，生产保证数据恢复的最小命令集，可以使用命令bgrewriteaof。之后每次重写的触发条件是文件到达上次的1倍，且大于64M。

对数据完整性要起比较高，带来的代价就是持续的IO，二是rewrite最后过程中将rewrite过程中的新增写操作写入新的文件时带来的阻塞是不可避免的。

redis支持事务

开启->入队->执行

基本操作

multi:表示一个事务的开启，标志这后面的redis操作会被入队queue。

exec:执行事务中的指令集，排他的执行。

discard：撤销事务的执行，销毁queue。

指令集中有一个出错的话，整个事务都无法执行

redis对事务是部分支持的，比如命令中有一些是不存在的命令，那就会导致所有其他命令也无法执行(比如把set k1 v1错误的协程setget k1 v1)；如果只是有一些命令错误，但是命令本身是存在的（比如将set k1 v1写成set k1 v1 v2 v3），那么除了错误的命令之外的其他命令都能得到执行。我的理解是执行正确的命令，如果某些命令无法执行，事务内的其他已执行的命令不会被回滚。也就是说redis的事务不保证原子性。

watch监控：属于乐观锁的一种（CAS）。WATCH监控一个或多个key是否被修改（从监控开始到事务提交这段时间内），如果修改，整个事务都无法执行，并返回nil（注意：WATCH只对事务），返回nil。一旦执行了EXEC，所有的监控锁都会被取消。

UNwatch监控：取消所有keys的监控。

发布和订阅

进程中一种消息通信的模式：发送者发送消息（PUBLISH channel1 "hello world"），订阅者 （subscribe）接收消息 。

命令：

订阅、接收消息：subscribe  c1 c2 c3      表示订阅c1 c2 c3三个频道；也可以用通配符订阅：psubscribe c*

发布、发送消息：publicsh c1  "hello redis"

注意：实际生产中一般不用redis来处理发布和订阅，而是用其他消息中间件来完成发布和订阅。

主从复制和读写分离

master-slave

redis server起来后默认都是master，除非修改配置文件。

命令行和config配置文件配置的方法相同，都是：

slaveof <masterip> <masterport>

即可。主机无需配置。slave只能读，不能进行写操作。master能读能写。当然一般是读写分离的。

生产时一般是一个master，多个slave。通常会遇到如下几种故障：

1、master挂掉：此时slaves依旧是slave，slave并不会在master挂掉后自动变成slave。当master恢复后又变成了master，又恢复到挂掉之前的主仆关系。若master挂掉期间，slave手动改成了master，那么原来的master恢复后则变成了光杆司令。

2、slave挂掉：这种情况下，slave再恢复后不会和原来的master自动连接并形成主仆关系，需要手动配置slaveof ip port，或者修改配置文件。

处理故障，做主从分离一般有如下几种策略：

1、一主一从：从机原地待命，不会变成slave，需要手动干预，master恢复后又回恢复到之前的主机地位，主从备份依旧有效。

2、一主多从

3、薪火相传

4、哨兵模式sentinel。主机挂掉后，组织slaves投票选出master；若原来的master恢复后回来了，那么他会被哨兵监控到，使他变成slave。

其中前三种基本上被哨兵模式取代了。因为哨兵模式更加自动化，不需要人工干预。前面三种都需要人工干预，在某一台从机上执行命令SLAVEOF NO ONE，指定其为新的master

master-slave的缺点

由于所有的写操作都在master上，然后复制到slaves上，所以复制过程会有个延迟，而且当访问繁忙或者当slave数量上来后，延迟更加明显。