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分析