redis优势
- 1、高速读写访问，Redis能读的速度是110000次/s,写的速度是81000次/s 。
- 2、海量数据存储，支持分布式，数据一致性保证。方便的集群节点增删
- 3、丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作
- 4、原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来
- 5、丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性
redis缺点
- 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
- Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
- 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
- Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
使用场景
- 1、高并发查询的地方。秒杀
- 2、不经常更新，但经常查询的地方。如：商品分类
- 3、频繁记录，统计。如用户登陆统计
- 4、分布式锁
- 5、数据永久性存储
常见的数据类型
- 1、set
- set是string类型的无序集合.集合是通过hashtable实现的,可以进行交集,并集,差集等等.复杂度为O(1)
- 2、zset
- zset set是string类型的无序集合,且不允许重复的成员
- 3、list
- list双向链表,按照插入有序,可以添加一个元素在列表的头部或者尾部
- 4、hash
- hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
- 5、string
- string是redis的基本类型，一个key对应一个value。是二进制安全的，最大存储512MB
| 类型 | 简介 | 特征 | 常用命令 | 场景 |
|---|---|---|---|---|
| string | key-value， 二进制安全 | 可以包含任何数据，jpg图片或者序列化对象等，最大512MB | set、get、setex、incr、decr | 接口访问频率限制、计数等等 |
| hash | key-value，相对于开发中的map | 特别适合存储对象，每个hash可以存2^32 - 1键值对 | hset、hmset、hget、hgetall、hexists、hlen | 存在、读取、修改订单信息 |
| list | 双向链表 | 插头顺序排列,可以添加一个元素到列表的头部或者尾部, 一个列表最多可以包含2^32-1个元素 | lpush、lrange、llen、lpop、rpush、rpop、lindex | 排队秒杀、消息队列 |
| set | 哈希列表，无序集合，元素不重复 | 交集，并集，差集功能，集合成员是唯一的，这就意味着集合中不能出现重复的数据。集合对象的编码可以是 intset 或者 hashtable。 集合最多成员数为2^32-1 | sadd、smembers、sdiff、sinter、sunion | 共同好友，推荐商品 |
| sorted set | 有序集合，且不允许重复的成员 | 不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序，集合中最大的成员数为2^32 - 1 | zadd、zrange、zcount、zcard | 带权重的消息队列、排行榜 |
redis持久化机制
1、RDB （redis database）
- RDB是redis默认的持久化方式。按照一定的时间将内存中的数据以数据快照的方式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期
- 优点：
- 只有一个dump.rdb，方便持久化
- 容灾性好，一个文件可以保存在安全的磁盘中
- 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
- 相对于大数据集时，比AOF的启动效率高
- 缺点：
- 数据安全性低。RDB是间隔时间进行持久化。如果在持久化期间redis发生故障，会丢失数据
2、AOF （append-only file）
- AOF持久化，则是将redis执行的每次写命令记录到单独的日志文件中，当重启redis会重新将持久化的日志中文件恢复数据
- 优点：
- 数据安全，aof持久化可以配置appendfsync属性，有always，每进行一次命令操作就记录到aof文件中一次
- 通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题
- aof机制的rewrite模式，aof文件没被rewrite之前，可以删除其中的某些命令
- 缺点：
- AOF文件比RDB文件大,且恢复速度慢
- 数据集大时,比RDB启动效率低
redis过期键删除策略
- redis过期策略有以下三种：
- 定时过期：每个设置过期时间的可以都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的cpu资源，从而影响缓存的响应时间和吞吐量
- 惰性过期：当有访问一个key时，才会判断这个key是否已过期，过期则清除。该策略可以最大化的节省cpu资源，但对内存非常不友好。极端情况可能出现大量的key没有再次被访问，从而不能被清除，占用大量内存
- 定期过期：每隔一段时间，会扫描一定数量的数据库的expires字典中的一定数量的key，并清除其中已经过期的key。改策略是前两者的一个折中方案。通过调整定时扫描时间间隔和每次扫描的限定耗时，可以在不同情况下使得cpu和内存资源达到最优的平衡效果
常见问题
1、缓存穿透
- 缓存穿透：
- 当查询Redis中没有的数据时，该查询会下沉到数据库层，同时数据库层也没有该数据，当这种情况大量出现或被恶意攻击时，接口的访问全部透过Redis访问数据库，而数据库中也没有这些数据，我们称这种现象为"缓存穿透"。缓存穿透会穿透Redis的保护，提升底层数据库的负载压力，同时这类穿透查询没有数据返回也造成了网络和计算资源的浪费。
- 解决方案：
- 在接口访问层对用户做校验，如接口传参、登陆状态、n秒内访问接口的次数；
- 利用布隆过滤器，将数据库层有的数据key存储在位数组中，以判断访问的key在底层数据库中是否存在；
2、缓存击穿
- 缓存穿透：
- 当查询Redis时，底层数据库有数据而缓存内没有数据。当热点数据key从缓存内失效时，大量访问同时请求这个数据，就会将查询下沉到数据库层，此时数据库层的负载压力会骤增，我们称这种现象为"缓存击穿"
- 解决方案：
- 延长热点key的过期时间或者设置永不过期，如排行榜，首页等一定会有高并发的接口；
- 利用互斥锁保证同一时刻只有一个客户端可以查询底层数据库的这个数据，一旦查到数据就缓存至Redis内，避免其他大量请求同时穿过Redis访问底层数据库；
3、缓存雪崩
- 缓存雪崩：
- 缓存雪崩是缓存击穿的"大面积"版，缓存击穿是数据库缓存到Redis内的热点数据失效导致大量并发查询穿过redis直接击打到底层数据库，而缓存雪崩是指Redis中大量的key几乎同时过期，然后大量并发查询穿过redis击打到底层数据库上，此时数据库层的负载压力会骤增，我们称这种现象为"缓存雪崩
- 解决方案：
- 在可接受的时间范围内随机设置key的过期时间，分散key的过期时间，以防止大量的key在同一时刻过期；
- 对于一定要在固定时间让key失效的场景(例如每日12点准时更新所有最新排名)，可以在固定的失效时间时在接口服务端设置随机延时，将请求的时间打散，让一部分查询先将数据缓存起来；
- 延长热点key的过期时间或者设置永不过期，这一点和缓存击穿中的方案一样；
