缓存穿透的问题
通常使用的缓存都是应用先检查缓存中是否存在。如果存在，则直接返回缓存；如果不存在，则查询数据库，将结果缓存并返回。
但是查询的是一个不存在的数据，就会造成每一次请求都查询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。
