《App后台开发运维和架构实践》读书笔记 - Redis

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: “一条一条”那种数据日志；适合两次全量写入之间的增量更新；