为什么使用redis
性能
- 我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。
并发
- 在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库。
redis优点
（1）支持多种数据类型
（2）纯内存操作
（3）单线程，避免频繁上下文切换
（4）采用异步非阻塞工作机制
redis缺点
- 缓存和数据库双写一致性问题
- 缓存雪崩问题
- (三)缓存击穿问题
- (四)缓存的并发竞争问题
redis数据类型以及应用场景
1、string
最简单的k/v对，使用set/get操作。v可以是字符串也可以是数字。使用incr、decr，incr by、decr by实现复杂计数功能的缓存。
2、hash
结构化的对象，比较方便的就是操作其中的某个字段。用的最多的就是单点登录，存储用户信息，以cookieId作为key，设置缓存过期时间，能模拟session的效果。
3、list
可以做简单的消息队列。使用lpop和rpush的方式，做先入先出FIFO
可以利用lrange命令，做基于redis的分页功能
4、set
set堆放的是一堆不重复值的集合。所以可以做全局去重的功能
利用交集sinter、并集sunion、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。
5、sorted set
sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。
redis的过期策略以及内存淘汰机制
redis采用的是定期删除+惰性删除策略。
定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.
redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
惰性删除。redis在获取key的时候会检查key是否设置了过期时间并且判断是否到期，如果到期，就会删除key
定期删除+惰性删除的问题
如果定期删除没有删除key，也没有去请求过这个key，那么redis内存会越来越高。需要使用内存淘汰策略。
通过maxmemory-policy volatile-lru设置淘汰策略
redis和数据库双写一致性问题
分析:一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。
首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。
如何解决redis的并发竞争key问题
分析:这个问题大致就是，同时有多个子系统去set一个key。因为生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都
存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。回答:如下所示
(1)如果对这个key操作，不要求顺序
这种情况下，准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可，比较简单。
(2)如果对这个key操作，要求顺序
假设有一个key1,系统A需要将key1设置为valueA,系统B需要将key1设置为valueB,系统C需要将key1设置为valueC.
期望按照key1的value值按照 valueA–>valueB–>valueC的顺序变化。这种时候我们在数据写入数据库的时候，需要保存一个时间戳。假设时间戳如下
系统A key 1 {valueA 3:00}
系统B key 1 {valueB 3:05}
系统C key 1 {valueC 3:10}那么，假设这会系统B先抢到锁，将key1设置为{valueB 3:05}。接下来系统A抢到锁，发现自己的valueA的时间戳早于缓存中的时间戳，那就不做set操作了。以此类推。
其他方法，比如利用队列，将set方法变成串行访问也可以。总之，灵活变通。
