7.1 Redis简介
- <Key-Value>内存缓存
- 可持久化到磁盘
- 支持多种数据类型:string, hash, list, set, sorted set, bitmap, hyperloglog
- Redis的所有操作都是原子操作;Redis支持几个操作合并后的原子性操作,即事务
App端本身有一层缓存(网络不可用时威力大);后台用Redis做一层缓存;
7.2 数据类型
7.2.1 string: value可存储JSON格式的页面数据,图片数据,等;
7.2.2 hash: value存储的是hashmap; 例子:key是用户id, value是<用户属性,属性值>构成的map; 用string来存JSON也可以代替,但修改某字段麻烦,需要先解析再序列化,整个value被修改;用id_hashkey来做key也行,但耗费空间太大;
7.2.3 list: value是个双端队列;可用作消息队列;
7.2.4 set: 无序且不重复的元素集合;支持交集,查集,并集等操作;例子:用户a和用户b的“共同好友”,可以用二者各自好友集合的交集实现;
7.2.5 sorted-set: 有序且不重复的集合;每个元素有一个score,集合里按照score排序的;元素的score可以重复,元素的value不能重复;
7.3 内存优化
7.3.1 监控内存:Info memory命令可以查看redis当前内存使用情况
7.3.2 优化存储结构:hashmap, list, sorted-set,在数据量少的情况下,速度优势体现不出来,所以采用序列化数组来存储(ziplist),省空间。
hashmap的ziplist: <HEAD, key1, value1, key2, value2, ...END>
list的ziplist: <HEAD, data1, data2, ...END>
sorted-set的ziplist:<HEAD, data1, score1, data2, score2, ...END>
7.3.3 限制使用的最大内存:
配置maxmemory: 达到这个值,将触发数据清除策略;
maxmemory-policy: 数据清除策略:过期时间,LRU,最小存活时间,随机选取,等策略;
7.3.4 过期时间:设置了超时时间的Key, 在过期后会被自动删除;一般用定期查询的方式来执行批量删除
7.4 集群
7.4.1 客户端分片:在客户端按Key进行分发到不同的Redis单机;
缺点:静态分片,Redis实例增多或减少,要重新改变分片规则; 可运维性差; 每加一个客户端实现,就要把同样的分片逻辑重写一遍,SB
7.4.2 Twitter开源的Twemproxy: 在客户端和Redis之间增加一个代理层,负责路由;
缺点:多了一层,性能损失;无法平滑的增加Redis实例;
7.4.3 Codis: 按key哈希到1024个slot, 每个Server存储一部分slots; slot分配表,记录在zookeeper里,由无状态的Codis Proxy集群来查询;
7.4.4 Redis3.0: 完全去中心化,P2P模式;每个机器负责“数据存储”和“路由重定向”;key哈希成16K个slot,每个机器负责一部分slot,客户端任意访问一个机器,如果不在该机器上,该机器返回正确机器的IP,客户端读新IP
7.4.5 创业公司的王道:Redis云服务
7.5 持久化
7.5.1 RDB: 父进程fork子进程,“二者共享内存空间”, 父进程继续服务客户端,子进程负责把内存里的数据写到磁盘文件里。
缺点:每次都是全量写入,两次之间如果挂了会丢失最后那点儿数据;
7.5.2 AOF: “一条一条”那种数据日志;适合两次全量写入之间的增量更新;