开发者学堂课程【Redis 入门到精通（基础篇）： hash 实现抢购】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/764/detail/13379
Hash 实现抢购
内容介绍：
一、Hash 类型应用场景
二、业务场景
三、解决方案
一、Hash 类型应用场景
业务场景
双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000张
这是一个反过来的东西，购物车是买家的东西，而抢购则是卖家的东西，在促销活动，价格低，数量有限，这也是商家的策略，商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000张，假设先销售移动的，所有人都在抢这1000张，这里的key就是商家id，电话卡则是商品种类id，也就是field，而1000张则是商品的数量 value，按这个结构设计，我们就可以设计出这个hash 的大概模型。
解决方案
●以商家id作为key
●将参与抢购的商品id作为field
●将参与抢购的商品数量作为对应的value
●抢购时使用降值的方式控制产品数量
●实际业务中还有超卖等实际问题，这里不做讨论
抢购的时候，降值怎么解决，hash不提供descrip，那么就使用hincrby，使用负值，进行串联就可以了，如果说数量变成0怎么办，就需要一个判断，还有其他方法，这里提到的这个简单一些，实际业务中的超卖问题我们不做讨论。
Hmset p01 c30 1000 c50 1000 c100 1000，回车，假设这个时候有人买到了一张，那么就需要hincrby p01 c50 -1，回车得到999，然后hincrby p01 c100 -20，那么此时就变成了980，
hgetall得到最后的数量，然后在操作前还需要进行一个判断，判断就是编程的事情，我们现在要处理的只是库里面的数据，有一个问题要讨论一下，就是我们的redis起到的作用是数据存储还是带有业务逻辑判断的，原则上来说，只做数据的提供和保存，尽量不要把业务压到redis上面，所以说有些指令慎用。
比方说一些判断语句，他就已经带了业务的存在了，因此在做这类操作时要小心，不要把业务压到技术端，应该归业务逻辑层控制，而不应该是完全依赖，可以去做，但是不必要去做，导致编程中，业务过于分散，不合理。
对于使用hash模型可以应用于抢购，限购，限量发放优惠卷，激活码等业务数据的存储作用等等，模型相对简单。
业务场景
String存储对象（json）与hash存储对象
最后一个，关于String存储对象（json）与hash存储对象，用string的json格式去存储对象，是一种方式，用hash存也是一种方式，这两种方式的缺点是string存讲究整体性，一次性数据以整体操作，要么一次性更新，要么一次性获取，讲究读为主，而hash则可以分开，使用field进行隔离，所以hash在更新操作方面会更比较灵活一点，所以面对hash这种模型。
在之前提到过，这个是群组概念，把一系列的数据包装成一个群组，然后对外产生一个唯一的一个口，就是一个key，如果说更新操作或者修改数量的操作比较多的话，推荐使用hash，如果说仅仅是把这个数据对外呈现，那么使用string会更方便一点，如果说在hash里面存储string也是可以的，在之前的购物车说的也是这个设计，所以说企业开发各种东西还是灵活设置，并不是绝对的。
