基本操作：
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
即可。主机无需配置。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数量上来后，延迟更加明显。