双key绑定模式
该模式为新的redis应用自创模式，参考angularjs双key绑定实时更新数据模式、也可等同于db的映射模式，源于当前网络对于redis穿透、击穿没有很好的解决方案。
目前已知的方式有
1、布隆过滤器(代码繁琐、适合大量key进行节约缓存空间，非透明化、不适用于当前项目中量数据)
2、redis对key的频率控制，该做法无异于剥夺了redis的高并发属性，假如控制redis对key访问频率一万qps，访问数据库直接挂掉，假如控制不能直接挂掉数据库，访问频率必然不大，无参考意义
3、采用java二次缓存方式，该类做法适用于小型项目，假如redis缓存1G、到时候每次部署每台服务器占用内存就最少要1G，不适用于分布式集群项目
4、设置默认值，设置默认值方式在业务代码中处理，过于繁琐。或者更改序列化方式，假如是null，则保存空字符串。但此类方式弊端是与序列化方式相关，无法很好的重组
该做法的优点
1、缓存代价可接受，双key绑定适用于总缓存代价在可接受范围内，多出的缓存空间为key=空字符串产生的空间，假如一个key空间=10b，1M便可以存放10w个冗余key，1G可以存放1亿个冗余key
2、失效key的透明化，哪些key绝对不可能存在穿透，可直接查询出来
3、实现简单，直接在业务层多写一个key
4、替换简单，采用新的bind类，可随时去掉或替换其他方式
该做法不足的地方
1、目前api很多，写法假如没有采用事务方式，在并发情况下可能存在双key不一致(一般双key写入概率小## 标题)；但采用要去写lua脚本很繁琐
2、假如采用mq这种，与简单使用redis的初衷不一致，并且mq的性能远远没有redis好、并且很消耗性能
欢迎补充或升级…