redis基本知识介绍

基本数据类型:

redis相对memcache来说,支持了更多的数据类型,在使用场景上面无疑是更加的便捷

1. String: 可以存储任何形式的字符串,内部实现结构有int,sds(simple dynamisc string),当值为整型时,使用int结构存放,非整型时使用sds存储
2. List: 当list的节点小于配置: hash-max-ziplist-entries 或者elem_value字符串的长度小于 hash-max-ziplist-value,采用ziplist存储,以便节约内存, 当大于时采用双向链表存储 ,list两端的查询复杂度为O(1),中间为O(N)
3. Map:新建的Hash类型也使用ziplist存储value，保存数据过多时，转而使用hast table。
4. SortSet：如果新建的Sortset包含value数大于配置或者value长度大于配置值，则直接使用hash table和skip list存储value，skip list实现对value的排序；否则直接使用skip list存储value。
5. Set :value 值为int时采用intset存储,当值的个数大于配置时,采用hash table

高级特性:

1. 简易事务的支持
   redis提供的事务更像是一组命令的批处理,和关系型数据库最大的区别在于不会回滚.

   • watch:监测某一个key是否发生变动
   • mulit:开始事务,标记事务的开始,在此之后的命令会顺序存放到队列
   • exec:向服务器提交所有开始事务后的命令,然后恢复到正常连接
   • discard:清除队列里的命令,当在使用mulit后使用discard,会清除队列里的所有命令,当有watch命令时,会清除当前连接的监控
   • unwhatch:取消监控,如果调用了EXEC或DISCARD命令，就不需要手动调用UNWATCH命令。

   使用方法:

    reids.mulit; 开始事务
    redis.set(key,value);
    redis.set(key1,value1);
    redis.exec;
   

2. pipeline:批量提交多组命令,减少网络请求压力
   我们知道,redis是基于单线程的, 对于批量操作多个key这种场景来说,每次请求无疑会增加网络请求耗时,所以redis提供了这种命令用来提供个批量写入这种场景使用,不保证一个管道里的命令全部成功.

3. lua:脚本.详见后续文档

持久化方式:

两种方式

1. RDB：支持多长时间内多少次写入触发.fork子进程,建议最大使用内存,最多丢失上一次快照保存之后的数据,在执行快照时间,服务器会一直阻塞,阻塞时间和日志大小有关
2. AOF: 三种策略 ,性能依次从低到高
   1. always 总是写入
   2. everysec 每秒保存
   3. no 禁用同步策略,只追加命令,何时落盘,由操作系统保证(大多数Liunx系统,每30s进行一次fsync,将缓存区的数据落入磁盘)

两种方式的区别

RDB实际上是fork出一个子进程,通过子进程来写入临时文件,当临时文件完成后通过写复制模式的原子性替换旧的文件
AOF实际上是追加命令,通过类似于日志的方式记录每一条写的命令(包含新增,修改,删除),存储的文件格式相对简单,便于查看,解析。

两种方式的优缺点

RDB的优点：

1. 使用RDB做持久化的时候,整个redis只会有一份数据文件,对于文件备份来说,可以很轻易的备份任意时间点的数据。
2. 性能高,是已知redis持久化方式中性能最高的一种。
3. 灾备恢复最快,当数据集过大时,RDB的恢复效率更高，这是相对于AOF来说，RDB的文件相对较小。

RDB的缺点：

1. 持久化的力度过粗,如果在这一次fork还为完成的时候机器宕机,那么上一次持久化之后的数据都会丢失。
2. RDB的机制在fork子进程执行持久化的时候,会阻塞主线程,在数据集过大的情况下会导致服务终端几百毫秒甚至几秒。

AOF的优点：

1.更完整的持久化机制,这种方式给我们提供了三种策略,其中 always是同步持久化,也就是说数据变更会立即落入磁盘。
2. AOF是通过追加的方式来实现持久化,因此当服务器宕机的时候,也不会损坏已经追加完成的数据,最多丢失当前写入的那条数据.如果在写入中途宕机,导致文件损坏,在下一次启动前可以通过redis-check-aof来解决文件问题。
3. AOF的保存文本格式更清晰，更易于理解,当意外flush db 的时候，在服务还没有rewrite之前,我们可以通过该文件手动修改命令,让该命令失效。

AOF的缺点：

1.持久化文件相对于RDB来说更大,恢复数据起来慢于RDB。
2.性能上低于RDB,只有在禁用同步策略的时候和RDB性能持平。

两种场景的选择：看业务场景的需要，是需要牺牲一些性能换取更高的数据一致性,还是需要更高的性能降低点数据一致性.