优惠劵系统库存设计浅谈

优惠劵系统活动库存通常分为：总库存和日库存。在一个用户来领取优惠劵时，须要判断当前剩余总库存和日库存是否充足，若是充足则进行库存扣减，不然提示用户领取失败。总库存和日库存的扣减是一个原子操做，要么都成功，要么都失败。咱们知道数据库事务知足"ACID"特性，所以能够将这两个操做放到一个事务中进行。

原始阶段库存设计

在最初阶段，系统用户数量较少，优惠劵领取请求流量不大。咱们能够将一个活动的总库存和日库存放到同一个MySQL数据库中。一个活动的总库存对应一条记录，一个活动的日库存在活动期间天天都有一条日库存记录。在用户来领取优惠劵时，咱们开启一个事务，首先扣减总库存，其次扣减日库存，若是任一步骤失败，则回滚事务，前端提示用户领取优惠劵失败。

考虑到系统数据库模块的可扩展性，咱们采用“分库分表”的方式进行数据的“sharding”，按照具体的业务ID来分库，例如咱们能够按照活动号来分片咱们的数据，这样同一个活动的总库存和日库存都落在一个数据库中，能够作成一个事务。出于性能考虑咱们不采用分布式事务。

这种系统设计的优势是：实现简单，库存具备强一致性（由事务保证）；可是其缺点也很明显：事务开启时，MySQL会给总库存和日库存加行锁（InnoDB存储引擎），行锁具备排他性，在一个事务提交以前其余事务都必须等待。所以，虽然在领劵时咱们系统是开启多线程方式并发处理请求，可是在更新数据库时全部的请求仍是“串行化”操做。假设，咱们更新总库存和日库存这两个操做一次耗时10ms，那么系统针对每一个活动的领劵请求“TPS”最高也只有100，这对于一些“热点”活动高并发领取来讲是没法忍受的。

Redis内存数据库库存扣减

Redis是一个高性能的分布式缓存系统，它既能够用做缓存，也能够用做内存数据库。它的特色是性能极高，由于操做都是纯内存操做。单机最高可以达到10W的QPS，对于通常的系统，这个已经可以知足要求。"Every coin has two sides"，虽然Redis的性能极高，可是它也有缺点，例如redis的事务不能像MySQL同样可以保证事务的"ACID"特性，Redis 的事务保证了 ACID 中的一致性（C）和隔离性（I），但并不保证原子性（A）和持久性（D）。这样就可能产生问题，例如在扣减库存时，首先扣减总库存，再扣减日库存。假设总库存扣减成功，日库存扣减失败。Redis没有回滚机制，这样即便事务失败了，也无法回滚总库存，从而产生问题。

Redis高可用

Redis支持集群部署，Redis 集群有16384个槽，经过计算key的CRC16校验和再对16384取模获得key落在哪一个slot上（CRC16(key) % 16384）。 当单个Redis节点撑不住时能够考虑用Redis集群的方式来实现库存扣减。主从复制，master节点和slave节点之间用Sentinel作故障转移。

Redis同步扣减库存，异步同步到数据库方案

虽然Redis提供了持久化方案（RDB，AOF），可是对于一些重要的业务数据，Redis自己的持久化方案可能还不够，咱们须要将Redis中记录的库存数据异步同步到数据库中。在极端状况下Redis挂了，还有数据库做为"凭证"。 所以，根据业务须要，能够考虑开启一个后台任务，定时地将Redis中记录的库存数据同步到数据库中。