电商平台常用缓存策略总结

一、走索引通道

1、方案

给所有商品创建索引,商品列表走搜索通道

2、索引如何维护

方案一是通过定时器,给最近变更的商品重新创建索引,存在一定的延时;

方案二是当后台上架或者修改商品的时候重新创建索引,小型电商平台可能直接就这样干了;

方案三是通过mq,beanstalsk等消息队列,当存在商品信息变更到时候,发送一条通知,告知变更的商品id,消费者可以实时收到商品的变更从而重新创建商品的索引,存在的问题是索引可能更新比较频繁。

二、aop将返回结果加入缓存

1、方案

通过spring aop可以知道调用api的所有参数,这些参数组成缓存的key,然后把正确的返回结果放入到缓存中,这种缓存放松一般不能放太久,因为商品信息可能会变更,5-30分钟左右。

2、存在的问题

这种方案决定了缓存的时间不可能太久,产生的后果是后台上架的商品可能要三十分钟以后才能真正在平台看到商品,商品价格变更,三十分钟后才能看到效果。更关键的是拦截器拦截后同步设置缓存,所有查询方法夹杂了大量的插入操作。

三、从数据库搜索查询商品基本信息,其余信息从缓存加载

1、方案

从数据库加载商品的基本信息,基本上只要商品的id,从数据库拉取到商品list后,再遍历设置商品的其余信息。这些遍历的商品其余信息均从缓存获取,key是是商品的id。

商品信息从缓存获取,如果没有发送一条mq,同时从数据库加载该商品信息,等mq消费完毕后一下次开始就可以从数据库加载该商品信息了。

 

2、这样做的原因

1)我们有些商品列表业务比较复杂,商品信息无法从索引中加载。

2)商品信息也无法一次性从缓存中加载,比如说存在优惠的商品商品价格需要重新计算,优惠计算通常存在一定复杂度,如果整个商品列表从数据库查询出来,然后又遍历每个商品重新设置优惠后的价格,商品加载的速度也就可想而知 。

 

3、创建优惠活动如何通知相关消费者商品信息变更

1)优惠活动一般都会有开始时间和结束时间,通过mq的延迟队列在优惠开始的时候消费者修改相关商品的价格,在优惠结束后通知相关消费者商品的价格

2)同理,如果商品取消了相关商品的优惠活动同样需要处理redis里面商品信息的价格

 

4、缺点

商品信息从缓存获取,第一次没有需要发送mq,mq发送同样是update操作,虽然相当于异步了,可以理解为查询方法有副作用

 

四、直接将商品列表信息推送到缓存中

1、方案

对于一些促销活动商品列表为了加载方便可以通过脚本直接讲商品信息推送到缓存中

2、缺点

比较适合一些秒杀场景的业务,对于一般的业务并不适合

五、查询先从缓存获取,再从数据库中获取

1、方案

优先从缓存获取商品信息,如果没有从数据库中获取,然后将从数据库中获取的信息防止到缓存里卖弄

2、缺点

1)缓存不能放置太久,不然会招来业务部门的投诉

2)查询方法有update操作,方法有副作用

六、多种策略混合使用(方案三的加强版)

1、方案

1)第一次商品列表信息还是从数据库加载

2)aop将返回结果设置到缓存中,可以设置长久一些

3)aop取出来的商品信息,遍历每个商品,再重新从缓存中获取商品信息,重新设置每个商品信息,解决列表中的商品信息不是最新的问题

4)发送mq操作在aop完成,解决了查询方法有副作用的问题。

2、缺点

1)aop需要仅仅针对商品列表相关的,需要做好相关配置

2)副作用只是放在aop进行,实际仍然存在,只是代码维护会方便很多

 

七、缓存工具

1、memcached

1)所有数据放在内存中,重启数据将丢失

2)多线程,非阻塞

3)不支持失误

4)不支持集群,需要依赖于客户端执行实现

 

2、redis

1)数据加载到内存中,支持虚拟内存设置,如果设置vm=true,部分数据将直接放在了磁盘里面

2)单线程io复用模型  

3)支持master,slave模式,偏向于在服务器端实现集群

4)支持list,map等复杂数据结构

5)支持事务,通过multi和whatch命令

6)redis数据可以持久化,内存中的数据隔段时间(可配置)可同步到磁盘中

 

3、activemq

1)支持一对一消息模式,即生产者消费者模式

2)支持一对多消息模式,即发布订阅模式

3)支持消息延时发送,延时队列

4)支持定时发送,定时器模式

5)消息队列中间件一般支持推和拉两种方式,上面的使用场景都是通过监听的方法有一条发一条的推的模式

 

八、代码编写注意事项

1、一个查询加载注意将变的信息放在一个方法,经常变更的信息放在一个接口

2、比如是否收藏,购物车数量等,这些是常变更的信息

3、原则上使用策略三,缓存时间可以设置为持久化,但为了防止mq丢失,脏数据等问题,最好给缓存加一个时间戳

九、更极端的方案

1、方案

将所有商品都推送到redis中,redis中没有直接放回空集合。

后台时刻维护redis中的商品信息。

 

2、缺点

redis内信息的维护感觉还是没有在关系型数据库中维护来得方便。

 

转载于:https://my.oschina.net/fengshuzi/blog/791442

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值