Redis笔记

1、解决CPU和内存压力

2、解决IO压力

Mamcache、Redis、MongoDB（文档型数据库）

String（最大长度为512M）、List（值在键在，值光键亡，快速链表结构）、Set（无序）、ZSet（有序集合，哈希表+跳跃表，可以用作排行榜）、Hash（压缩列表+哈希表）、Bitmaps（只存0和1，若初始偏移量很大存在效率低阻塞，可以用作计算访问网站的用户数量）、HyperLogLog（解决基数问题）、Geospatial（地理位置信息二维坐标）

默认16个数据库，初始默认用0号库

dbsize：查看当前数据库的key数量

flushdb：清空当前库

flushall：通杀全部库

http://www.redis.cn/commands.html

单独隔离、串联多个命令防止别的命令插队

multi（组队出现错误，执行整个队列会被取消）、exec（执行出现错误，只有报错的不会被执行，非原子性）、discard

watch key 进行监视（没太明白作用）

单独的隔离级别（所有命令按顺序执行）、没有隔离级别（事务提交前任何指令都不会被执行）、不保证原子性（事务中有一条命令执行失败，其他命令仍会被执行，没有回滚）

1、解决超卖问题：加事务-乐观锁，但出现遗留库存问题

2、解决连接超时问题：使用连接池连接

3、解决库存依赖问题：Lua脚本，解决原子性问题

RDB： 父进程fork出子进程，由子进程进行持久化，先将数据写入到一个临时文件中，待持久化过程结束后再替换上一次持久化好的文件，最后一次持久化后的数据可能丢失

AOF：以日志的形式来记录每个写操作，只许追加文件不可以改写文件。（比RDB占用更多磁盘空间）

AOF持久化流程： 请求命令被append追加到AOF缓冲区；AOF缓冲区根据AOF持久化策略将操作sync同步到磁盘AOF文件中，当AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；当Redis重启时，会重新加载AOF文件中的写操作来达到数据恢复的目的

若AOF和RDB同时开启，默认取AOF的数据

AOF什么时候发生重写？ 默认配置是当AOF文件大小大于等于上次rewrite后文件大小的一倍且文件大于64M时触发

1、Master以写为主，Slave以读为主（读写分离、容灾恢复快）

2、一主二仆、薪火相传（slaveof slave可以是下一个slave的master）、反客为主（ slaveof no one 手动设置）

3、哨兵模式： sentinel monitor mymaster 127.0.0.1 6379 1（其中，mymaster为监控对象起的服务器名称， 1为至少有多少个哨兵同意迁移的数量）

4、如何复制？ slave成功连接master主动发送sync同步命令（复制延时）

5、故障恢复

1、无中心化集群： 启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N

2、slots： 一个redis集群包含16384个插槽（hash slot），数据库中的每个键都属于这16384个插槽的其中一个，根据CRC16(key)%16384计算键key属于哪个槽

节点 A 负责处理 0 号至 5460 号插槽。
节点 B 负责处理 5461 号至 10922 号插槽。
节点 C 负责处理 10923 号至 16383 号插槽。

1、缓存穿透： key不存在，恶意访问压垮数据源（对空值缓存并设置很短过期时间，设置白名单，采用布隆过滤器，进行实时监控）

2、缓存击穿： 一个key对应的数据存在但过期，存在大量并发请求（预先设置热门数据，实时调整，使用锁）

3、缓存雪崩： 多个key的缓存击穿（构建多级缓存架构，使用锁或队列，设置过期标志更新缓存，将缓存失效时间分散开）

4、分布式锁： 设置锁的过期时间（业务出现异常防止锁无法释放）+设置服务器UUID（防止释放其他服务器的锁）+添加LUA脚本（保证删除锁的原子性）。互斥性、不会发生死锁、解锁和解锁必须是同一个客户端、加锁和解锁必须具有原子性