1.整体业务流程
1.1 redis判断流程 （单线程）
1.首先获取订单id和用户id，调用lua脚本进行redis操作，lua内包括 对购买资格/库存充足的判断 、 扣库存下单、发送订单消息到Stream。
2.Stream组成消息队列，有异常自动放到pending-list
1.2线程流程 （多个线程轮流）
1.线程读取消息队列（read消息队列），如果能不能读到消息，就继续读；如果读到了订单消息，就解析消息内容，调用下单函数3写入数据库，然后回复确认ack；如果出现了异常，就去处理penging-list 步骤2。
2.处理penging-list，解析消息，下单，处理；如有异常，重复循环继续处理；直到处理完跳出。
3. 加Redisson分布式锁，调用创建订单数据库操作。
2.解决了哪些问题？
2.1.超卖问题-->乐观锁
通过乐观锁，用库存当做版本号，只要库存大于0，就可以允许下单（一人一单后面有措施解决）
在lua脚本内代码
2.2一人一单->维护set，存储用户id+优惠券id，判重
sismember去判断用户id和优惠券id的记录是否同时存在在集合内
集合结构保证即便用户数量很多，也能最大程度减少重复数量，同时存在判断效率也高
2.3避免lua脚本频繁读取
定义成静态资源，随时取用，不用反复读lua脚本
2.3为什么分布式锁Redisson
分布式锁能够保证在集群模式下，不同的服务器jvm上保持锁的唯一性
后续Redisson使用了hash结构，因为能够保证可重入性
Redisson内部自动解决了2.4和2.5的问题。
2.4（自实现的才有这问题）分布式锁的宕机死锁-->设置过期时间+保证原子性lua脚本
过期时间保证服务宕机之后锁会过期释放
lua脚本保证不会锁还没加过期时间就宕机
Redisson内部自动实现了过期时间和加锁的原子性操作（lua），所以不会分开执行，不会死锁。
2.5（自实现的才有这问题）分布式锁的多线程误删问题-->判断线程标识+保证原子性lua脚本
判断锁的唯一线程标识，不是自己的不删
lua保证原子性，避免id判断和删锁之间的间隙
Redisson有看门狗机制，自动给锁续期，所以不存在锁过期导致别的线程获取锁然后误删的问题。只有服务宕机之后，看门狗机制也停止，才会锁过期，但这不是误删问题（服务阻塞但没有宕机）。
2.6 Redisson可重入、可重试、自动续期
可重入：锁底层是hash结构，hash的名字是，hash的key（field）是线程名字，value是重入次数。
多获取一次锁次数加一，结束一次次数减一，只有次数为0线程才会释放锁。
可重试：发布订阅。订阅锁的消息，一旦其他线程释放了锁，就会发布一个消息通知别人来抢。有一个剩余重试时间waitTime，所有抢锁时间加起来如果超过这个阈值，就会放弃重试，如果还有剩余重试时间，就继续等发布然后抢，等发布的时间就是当前剩余重试时间。如果等不到，就不等了。
自动续期：看门狗，一个函数重置重试时间（默认30s），每次都从30s开始。然后递归，实现无线续期。
3.一些数据结构
3.1 redis里
3.1.1 用于一人一单的set
使用redis的set结构，包含订单id和用户id
redis.call('sismember', orderKey, userId) == 1)
3.1.2 消息队列 Stream
--3.5 发送消息到redis stream队列，xadd stream.orders * k1 v1 k2 v2......
redis.call('xadd', 'stream.orders', '*', 'userId', userId, 'voucherId', voucherId, 'id', orderId)
3.1.3库存Stock 用String计数
redis.call('get', stockKey)) <= 0)
3.2 mysql里
3.2.1 完整订单
持久化进来的订单
3.2.2优惠券和秒杀优惠券
优惠券数据
