redis的发布和订阅

客户端可以订阅多个频道，当订阅的频道有消息发布，就会通知所有订阅该频道的客户端

SUBSCRIBE channel1  //订阅频道

publish channel1 hello  //发布消息

bitsmap 位图

setbit   key   offest  1    //将偏移的位置，置1 

getbit   key   offest        //获取偏移位置对应的值

bitcount  key    //统计置1的数量

bitop    and/or

省内存，适用于存储大量活跃用户

hyperloglog  做基数处理的数据类型

pfadd  key  val1  val2  val3 ...   

pfcount  key   //统计出基数的个数

pfmerge  k3  k1  k2  //合并到k3

Geospatial  经纬度

getadd   key  经度  维度   字段

geopos  key  字段   //查看某字段的经纬度

geodist   key  字段1  字段2   km   //查看两地之间的距离

Redis事务

Redis事务是一个单独的隔离操作∶事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

Redis事务的主要作用就是串联多个命令防止别的命令插队

事务命令

multi  //开始    exec  //执行    discard  //放弃组队

组队的时候，有任意一个命令出现了报告错误，执行时整个队列都会被取消

如果执行阶段某个命令报告了错误，则只有报错的命令不会被执行，而其他正确命令可以执行

事务冲突解决：

悲观锁：任意时刻只有一个人可以操作数据库

乐观锁：读共享，更新数据后，会更改数据库版本号，其他人再次更新时，需要查看数据库版本号是否一致。

watch  key           //监视key

unwatch  key       //取消监视key，exec命令或者discard命令被执行后，就不须要执行unwatch

乐观锁

Redis事务的三大特性

单独的隔离操作
事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

没有隔离级别的概念
队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

不保证原子性
事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis持久化RDB

rdb：在指定的时间间隔内将内存中的数据集快照写入磁盘

Redis 会单独fork 一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换为持久化的文件(dump.rdb)。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效

RDB的缺点是最后一次持久化后的数据可能丢失

优点：

1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高更适合使用
3.节省磁盘空间

4.恢复速度快

缺点： 

1.Fork 的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
2.虽然 Redis，在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
3.在备份周期在一定间隔时间做一次备份，所以如果 Redis意外down 掉的话，就会丢失最后一次快照后的所有修改

redis.conf

当redis无法写入磁盘，直接关闭redis的写操作   stop-writes-on-bgsave-error yes

 存储到磁盘的快照是否压缩  stop-writes-on-bgsave-error yes

检查数据完整性  rdbcompression yes 

save秒  写操作次数

20s   >=  3    20秒后，子进程进行持久化

rdb数据备份

 复制dump.rdb 

Redis持久化AOF

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

开启AOF

AOF和RDB同时开启，系统默认读取AOF（数据不会丢失）的数据

AOF文件异常

通过/usr/local/bin/redis-check-aof--fix 进行修复

AOF同步频率设置

appendfsync always
始终同步，每次 Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失

appendfsync no
redis不主动进行同步，把同步时机交给操作系统

重写压缩

AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

触发机制：设置重写的基准值(>=64M)，文件达到基准值的%100时，开始重写

持久化流程

1.客户端的请求写命令会被append追加到AOF 缓冲区内
2.AOF缓冲区根据AOF持久化策略，将写操作同步到磁盘的AOF文件中;
3.AOF文件大小超过重写策略或手动重写时，会对 AOF文件 rewrite重写，压缩AOF文件容量

4.Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的

优势：

1.备份机制更稳健，丢失数据概率更低
2.可读的日志文本，通过操作AOF稳健，可以处理误操作

劣势：

1.比起RDB占用更多的磁盘空间
2.恢复备份速度要慢
3.每次读写都同步的话，有一定的性能压力
4.存在个别 Bug，造成恢复不能