对于B类宝物，在做新增预定时，需要注意先将原有的hash value取出，和新的预定取货时间做逻辑或操作，然后再把结果写回Redis中，而不能像A类宝物一样直接调用hSet去设置hash value；取消预定时，要注意先将原有的hash value取出，把要取消的时间段从hash value中扣除掉（异或+逻辑与操作），然后重新将剩余的已预订取货时间写回Redis中，而不能直接调用hDel去删除。
四、再次进阶&库存管理方案
自从推出了B类宝物之后，你的生意又比以往火爆了许多。于是新的需求又来了，现在有大量的游客、学生党等没什么丰厚积蓄的人表示对你的宝物非常感兴趣，来这个城市旅游的人都希望带一些纪念品回去。然而，B类宝物的价格虽然比A类便宜一些，对于这些人来讲还是有点贵。于是，你决定把自己余量最多的实惠宝物（C类宝物）拿出来售卖。
这部分宝物数量是最多的，于是你在这300个房间中，每个房间新增了100个宝箱，专门用于存放C类宝物。这100个宝箱分别被编号为1号，2号，……，100号。同样的，每天的每个小时，你都会向这300个房间中，每个房间的100个宝箱中分别放入一件C类宝物（也就意味着，整个大楼每小时C类宝物会更新30000件）。如果没有人预定，则下一个小时宝物更换。终于，这下可以满足所有人的需求了。
对于C类宝物，你的预定界面成了下面的样子：
我们又多了一个预定条件。此时，又面临着库存存储的问题。照例，这个库存其实就是一个大的五维数组，宝物类型、房间号、预定日期、取货时间、宝箱编号各自占有一个维度。不过前面我们的Redis各个维度基本上已经占满了，这次应该怎么存储呢？
这次的Redis库存存储必须要结合业务特点来了。首先，宝箱编号和取货时间这两个维度，能取的值范围并不太多，宝箱编号只有100个，只要把hash value变成一个长度为100的数组，数组的每个位置都存有INT类型表示的取货时间即可。然而hash value只能是string……于是乎，只好做一个数组的序列化操作，读取的时候再反序列化回来即可。好在长度只有100，序列化效率并不会成为系统的瓶颈。
例如，C类宝物，12月23日、24日，258房间，97和99号宝箱在11点至13点被预定，则存储为：
Redis Key —— C:258
Redis Value —— hash table ['2016-12-23' => '[97 => 6144, 99 => 6144]', '2016-12-24' => '[97 => 6144, 99 => 6144]' ]
其中6144用二进制表示为‘110000000000’，hash value为数组序列化以后的字符串，实际项目中可以使用json格式。好了，现在Redis对于三种宝物的存储都有了。
对于C类宝物，在用户取消预定、新增预定时，同样不能简单地调用hSet和hDel进行覆盖设置和删除，要取出已经预定的情况，与已经预定的取货时间做位运算。
五、存储优化
库存理论上就是一个多维数组，我们所做的主要工作就是怎样把各个维度合理的存储起来，并能够方便地进行增加、删除、查询操作。从节约使用内存的角度讲，在最开始还没有任何人预定的时候，Redis整个可以是空的，对于A类宝物来说，hash value等于false和根本不存在对应的redis key或hash key是等效的。
另外，宝物类型和房间号合起来做redis key，会导致我们在redis中和宝物库存相关的key的数量比较多，为了方便统一管理这些key，可以再增加一条redis缓存，专门用来存储和宝物库存相关的所有redis key值，如下图所示。需要注意的是，这次我们并不需要hash数据类型了，set类型就已经足够，增删改查复杂度都是O(1)。里面存储了所有redis中已经存在的库存key值。
这么做的一个好处是，万一哪天碰到一些特殊情况，需要把所有库存相关缓存全部清空的话，我们可以很容易地取出所有的库存key并做删除操作。另外一个好处是，给我们提供了继续扩展的思路……设想一下，现在最复杂的情况是C类宝物，一共5个维度。假设未来，你不再使用一幢楼的300个房间去售卖宝物，而是多幢楼，那么用户在下订单的时候又要多出一个维度——楼栋编号。碰到这种情况，我们完全可以将这个多出来的库存Key集合退化为楼栋编号来使用，保证了可能出现的更复杂情况下的扩展性。