redis,缓存雪崩，粗粒度锁，缓存一致性

1，

redis单线程为什么快 io多路复用技术 单线程避免多线程的频繁切换问题

memcache缺点 kv形式数据 没有持久化
mongodb 海量数据的访问效率 mr的计算模型
文档就是类似json的键值对形式的数据
写操作MongoDB比传统数据库快的根本原因是Mongo使用的内存映射技术 － 写入数据时候只要在内存里完成就可以返回给应用程序，这样并发量自然就很高。而保存到硬体的操作则在后台异步完成
读操作MongoDB快的原因是： 1）MongoDB的设计要求你常用的数据（working set)可以在内存里装下。这样大部分操作只需要读内存，自然很快。 2）文档性模式设计一般会是的你所需要的数据都相对集中在一起

2，

缓存不仅快 其次减少数据库压力 数据库连接资源有限

缓存雪崩：一系列的key，过期时间一样，缓存到时了，请求都到数据库了
缓存穿透：访问key 缓存中没有值，数据库崩了，可以将null写入缓存，时效快
缓存击穿：一个key时效，同时访问这个key的请求很多，不过期

3、粗粒度锁：

这时候，普遍的做法是加锁，但是如果对整个访问redis的动作加锁，那么等于多个线程串行访问了！

4、细粒度加锁：

我们这里的做法是对key（redis）进行细粒度加锁，每个key拥有一把锁，只对key进行并发控制，key与key之间允许并发。

5、缓存一致性

5.1.实时同步更新

特点：更新数据库的同时，更新缓存，使用缓存工具类或者AOP实现

优点：数据一致性强，不会出现缓存雪崩

缺点：代码耦合，运行期耦合，影响正常业务，增加一次网络开销

适用场景：写操作频繁、数据一致性要求比较高，比如银行业务、证券业务

5.2.准实时同步更新

特点：更新数据库后，异步更新缓存，使用使用mq实现或者binglog同步

优点：数据一致性较强、有较短的延迟，与业务代码解耦，不会影响正常业务，不会出现缓存雪崩

缺点：有较短延迟，无法保证最终一致性，需要补偿机制

试用场景：不适合写操作频繁且数据一致性要求严格的场景

5.3.缓存失效机制

特点：基于缓存自身的失效机制，弱一致性

优点：实现简单，与业务完全解耦，不影响正常业务

缺点：有一定延迟，存在缓存雪崩问题

试用场景：适合读多写少的互联网场景，允许一定数据延迟

5.4.任务调度更新

特点：采用任务调度框架，按照一定频率更新

优点：不影响正常业务，与业务解耦

缺点：不保证一致性，代码复杂度增大（要维护两套代码），容易堆积垃圾数据

试用场景：复杂统计类数据缓存，对数据一致性要求低的场景，比如统计类数据、BI分析