优惠劵系统活动库存一般分为：总库存和日库存。在一个用户来领取优惠劵时，需要判断当前剩余总库存和日库存是否充足，如果充足则进行库存扣减，否则提示用户领取失败。总库存和日库存的扣减是一个原子操作，要么都成功，要么都失败。我们知道数据库事务满足"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中记录的库存数据同步到数据库中。