本质是把库存放到redis里做扣减，解决数据库更新库存的行锁瓶颈。
库存流水需要异步插入到数据库中，作为最终的业务凭证。
- 前端：采用PHP-FPM实现，但是建议生产环境使用GO/JAVA等支持redis长连接的开发语言/框架。
- 后端：利用Redis维护优惠券库存，利用Redis Lua保障库存扣减幂等性，同时投递库存流水日志到Redis队列。
- 任务：消费Redis中的库存流水日志，批量插入到数据库中，落地为业务凭证。（我没实现）
- 优惠券：用户看到的优惠券实体，内部包含多个批次。
- 批次：一个优惠券由多个批次组成，一个批次内有多个券码coupon。
1）创建优惠券
2）创建批次，上传对应的若干券码（或者随机生成）
3）将批次生效到线上，用户可以秒杀
业务规则 - 先验与回滚
兑换优惠券可能需要消耗用户积分，前端必须实时做一次积分查询，积分充足则立即执行Redis扣减。
在任务处理时，对用户积分做真实扣减，若此时积分不足则可以将券码归还到redis中，并站内信通知用户。
因为最终业务凭证是以数据库为准的，而任务本身是一个准实时异步过程，所以业务前端应该给予用户合理的提示，例如"稍后到卡包中查看优惠券"。
业务规则 - 前置与有损
如果业务有类似限制IP领取几次等比较复杂的规则，优先考虑在redis lua之前做前置判定。
因为lua脚本中逻辑越多，redis的TPS越低，所以尽量保证lua只做库存核心扣减。
前置规则校验的缺点，就是可能因为前置规则更新了某些计数，而后续的redis lua扣减异常，导致用户再也无法抢该券码。
但是出于折衷，暂时没有更好的办法，可以根据业务需要做让步和取舍。
云主机Redis：云存在超卖问题，性能也不是很稳定，库存扣减性能在2w-4w/s。
物理机Redis: 库存扣减<=9w/s，随lua逻辑的复杂度而稍微降低，但整体远优于云Redis。
压测均采用redis长连接，采用PHP-FPM无法达到预期，需要换一个语言来实现库存前端服务。
任务入库仅做流水的select/insert操作，可以基于批量插入优化实现高吞吐。
如果业务量需要单个商品/优惠券>=9w/s的秒杀量，可以考虑限流，否则绰绰有余。
因为单个优惠券的库存是单台redis执行lua来承载的，而redis是单线程程序，所以lua的TPS有限。
在单个优惠券后端处理能力已知有限的情况下，有2个解决方案：
1）限流：也就是通过前端挡住大多数流量，只透传可控的流量到redis，给予用户友好的文案即可。
2）扩展：把优惠券的库存拆成N份，存储到多个redis实例，用户按uid打散到不同的redis实例进行扣减。
但是从公司量级来说，除非做到小米和京东的秒杀量级，否则上述方案大概一辈子也用不到。
demo里直接把优惠券coupon放在redis里，为了节约存储空间可以考虑只放coupon的数据库id。
对于商品类秒杀，库存可能只是一个剩余数量，异步任务需要走商品库存服务完成真实扣减。
1，不能使用带有随机性质的函数（redis会直接报错），比如time()，spop()等，否则主从同步时在从库上重放脚本，会导致主从不一致。
2，在cluster/codis下，可以使用redis的hash tags机制，实现多个key路由到同一个slot的能力，确保lua可以访问到相关数据。
3，不要使用eval，每次上传脚本到redis性能很差；应该使用evalsha，提前计算好lua脚本的sha1值，当evalsha报错时再触发一次script load上传脚本，也就是懒惰上传。
因为最终是数据库作为业务凭证，所以当redis主从切换等数据丢失场景出现时，至多出现少发的情况，绝对不会出现超发，因为在数据库层面可以基于coupon做去重。