1、如何解决缓存穿透和缓存雪崩问题？
问题分析：这两个问题一般在中小型传统软件企业很难碰到这个问题。如果有大并发的项目，流量有几百万左右。这两个问题一定要深刻考虑。
缓存穿透，即当黑客故意去请求缓存中不存在的数据，导致所有的请求都到数据库上了，从而数据库连接异常
解决方案：
1、利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试。
2、采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热（项目启动前，先加载缓存）操作。
3、提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的、key是否合法有效。如果不合法，则直接返回。
缓存雪崩，即缓存同一时间大面积的失效，这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。
解决方案：
- 给缓存的失效时间加上一个随机值，避免集体失效
- 使用互斥锁，但是该方案吞吐量明显下降了
- 双缓存，我们有两个缓存，缓存A和缓存B。缓存A的失效时间是20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点：
1、从缓存A读数据库，有则直接返回
2、A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。
3、更新线程同时更新缓存A和缓存B
如何解决Redis的并发竞争key问题：
问题分析
这个问题大致就是，同时又多个子系统去set一个key。如果去百度一下的话，答案基本都是推荐使用Redis事务机制。其实不太推荐使用Redis的事务机制。因为我们的生产环境基本都是Redis集群环境，做了数据分片操作。你一个事务中涉及到多个key操作的时候，这多个key不一定都存储在同一个reids-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方法变成串行访问也可以。总之，灵活变通。