缓存穿透的问题
通常使用的缓存都是应用先检查缓存中是否存在。如果存在,则直接返回缓存;如果不存在,则查询数据库,将结果缓存并返回。
但是查询的是一个不存在的数据,就会造成每一次请求都查询DB,这样缓存就失去了意义。
为了解决这个问题,通常使用特殊字符串标记无用的缓存,比如"EmptyCache",然后在应用层做相应处理,解决此问题。但是这种方式显得比较粗暴:
- 需要在反序列化过程中,将特殊字符串排除掉,同时需要将不存在的数据标记出来,避免再查询DB。
- 如果需要处理不同类型的数据的缓存穿透问题,是不是多加几种特殊字符传。
因此,我们可以引入NullObject模式来解决此问题。它的作用在于提供一个对象给指定的类型,用以代替这个对象为空的情况。
更具体的信息,可以参考此链接:https://en.wikipedia.org/wiki/Null_object
新的方案:以券(Ticket)为例
步骤一、引入抽象类AbstractNullObject
public abstract class AbstractNullObject{
private Integer id;
public void markNullObject(){
this.id = -1;
}
public void isNullObject(){
return id!=null && id<0;
}
}
一般在设计数据库表时,都有id字段,而且id字段是自增的整数。我们可以复用此id字段,并约定一个规则:id小0的对象,都是NullObject。
步骤二、让Ticket继承能够AbstractNullObject,并添加createNullObject函数
public class Ticket extends AbstractNullObject{
public static Ticket createNullObject(String ticketCode){
Ticket ticket =new Ticket();
ticket.setTicketCode(ticketCode):
ticket.markNullObject();
}
}
步骤三、更新缓存的查询流程
旧流程 | 新流程 |
---|---|
1. 根据TicketCodes,查询缓存,并将结果加入结果集。 2. 根据TicketCodes和结果集,找出不存在的TicketCode,然后到db查询,将结果加入结果集,并写入缓存。 3. 返回结果集合。 |
1. 根据TicketCodes,查询缓存,并将结果加入结果集。 2. 根据TicketCodes和结果集,找出不存在的TicketCode,然后到db查询,将结果加入结果集,并写入缓存。 3. 根据TicketCodes和结果集,再次不存在的TicketCode,为这些code创建NullObject,并写入缓存。 4. 过滤结果集,剔除NullObject。 5. 返回结果集。 |
对比新老流程,新流程增加了步骤3、4。
步骤3的作用:为不存在的TicketCode,创建NullObject,写入缓存。下次再次查询时,缓存就有数据,DB也不会查询。
步骤4的作用:NullObject是可以正常被反序列化,但对调用方来说是无效的数据,需要剔除。
总结
带来的好处:
- 如果想让Sku,Product避免缓存穿透的问题,只要继承NullObject接口,就能复用已有的成果。
- 在redis反序列化过程,没有特殊处理。
- 在原有的查询流程追加行为,没有破坏性的改造,成本低。
与老方案的差异:
序列化NullObject产生的字符串,携带的信息量远大于特殊字符传,而且反序列化后,可以判断是否为NullObject。
网友评论