最近在自己的工作中，把其中一个PHP项目的缓存从以前的APC缓存逐渐切换到Redis中，并且根据Redis所支持的数据结构做了库存维护功能。缓存是在业务层做的，准确讲应该是在MVC模型中Model的ORM里面。主要逻辑就是先查缓存，查不到的话再查数据库。不过这些不是本文的主要内容，下面我把库存管理功能的缓存设计思路分享一下，希望能带给大家一些收获，有不足之处或者有更好方案的，也希望各位多多指教。
一、业务背景
为了略去我们公司项目背景，我决定把这次的问题类比成一个考卷上的问题。至于业务细节，大家也无需关注~看题目就可以了：
假设你是某国最牛的收藏家，手里有各种价值连成的宝物。知道有一天，你觉得做收藏太没意思了，打算把这些宝物卖掉换点现金。
不过把这些值钱的宝贝放在菜市场上卖实在太low了。在“互联网+”时代，我们当然要玩一些不一样的卖法：在你名下有一栋300个房间的大楼（编号为001至300），每个房间放着一个密码锁保险箱，在下个月（12月1日至12月31日）的每一天，你都会挑选300件最好的“极品宝物”（也称作A类宝物），分别放入这300个房间的保险箱里，每天每个房间放什么宝物已经定好了，所有想买宝物的人必须至少提前一天在网上预定，到时候凭借预定码自己打开保险箱取货。没有被预定的宝物将会被你收回，不再售卖。
要做这样一个网络预定系统，它的前端界面大概是这样的：
上图中三个要填的控件，单击后可以出现选择框。现在的问题是，一个房间只有一个宝物，不能被重复预定。所以当买家选择了宝物类型和房间号之后，在选择预定日期时，要在日期选择框给用户一个提示。比如12月3日051号房间已被预定，现在又有另一位用户选择了051号房间，那么在弹出日期选择框时，12月3日要置为不可选。如下图（12月3日显示为“缺”）：
那么，这样一个简单的库存系统，如何在redis中存储呢？
二、库存管理方案（Redis）
最粗暴的想法是，我们的库存其实就是一个很大的三维数组，第一维宝物类型，第二维房间号，第三维即预定日期。Redis支持5种存储类型：String，Hash，List，Set，Sorted Set。目前的场景中Hash和Set类型都可以满足要求，在此我们选择使用Hash类型做存储。
Redis的key设置为 宝物类型+房间号（例如 A:205，A代表极品宝物，205为房间号），Redis的value为hash类型，hash key为日期（例如 2016-12-05），hash value为true或false，表示已经被预定或没有被预定。用图表示为：
如果A类宝物158房间在12月8日已经被预定，则存储为
Redis Key —— A:158
Redis Value —— hash table ['2016-12-08' => 1]
三、进阶场景&库存管理方案
你所推出的A类极品宝物很受欢迎，刚推出去不久即被预定出去很多。然而，动辄数十万元的价格也让很多有收藏兴趣、却没那么富裕的中产阶级望而却步。于是，你又从自己的收藏中挑选出了比A类宝物稍次一些的B类宝物（也称作“优质宝物”），价格更加亲民。
由于B类宝物比A类宝物多一些，你打算换一种玩法，在这300个房间中，每个房间又放入了一个保险箱，这次，你每隔一个小时都会向300个房间的箱中各放入一件B类宝物，没有被预定的宝物在这一个小时过后会被收回，换成下一个小时的宝物。买家预订后，按照所预定的小时来取走宝物。对于B类宝物，你的预定系统会多了一个选项，即取货时间。如下图：
现在由于多了一个预定条件（取货时间），那在做库存存储的时候，粗暴的方式想一下，库存其实就是一个大的四维数组。第一维宝物类型，第二维房间号，第三维预定日期，第四维取货时间。在Redis中怎样存储这类宝物呢？
其实仔细想一下，在存储A类极品宝物的时候，我们在Redis中的存储是有浪费维度的情况的，
当时hashValue只存了一个true表示有预定，这个维度其实是被浪费掉了。考虑到取货时间全是整点，一整天也就是0至1点，1至2点，……，23至24点共计24种情况，所以我们完全可以使用二进制整数表示被预定的时间。例如1表示0至1点，2表示1至2点，4表示2至3点，……，
8388608 （= 2^23）表示23至24点。多个时间段被预定，只需要将数值取逻辑或操作即可。
这样，我们的Redis结构变成了这样子：
例如，B类宝物103房间，12月5日和6日的上午8点至12点被预定，在redis中存储为
Redis Key —— B:103
Redis Value —— hash table ['2016-12-05' => 3840, '2016-12-06' => 3840]