关于写操作，想了半天感觉和读操作差不多，那么这里就模拟一下秒杀的情景，看下500的数量，抢购时订单多久抢完，排队的情景。
测试场景：请求进来以后进行redis鉴权，查询商品是否存在（数据库百万级），获取用户详细信息，落单减库存（百万级），订单入库，增加销量（百万级）。
在之前配置下，redis记录商品信息，不参与读写操作：
还没有售罄的状态下：
售罄以后：
对于连续读写操作时，性能。。。
引入rocketmq+redis（应用等待mq返回后才返回）：
还有库存的时候
而且从数据库和redis显示，二者差了1000多个。
没有返回值的时候：
二者差别不大，至于秒杀令牌令牌桶之类的限流这里就不测了。
总的来说对于写操作来说，由于必须和数据库产生交互，性能损耗是不可避免的，我们只能尽量通过中间件用异步的形式把这些损失转化到后面，当然对于用户体验来说还是要看实际场景。
接下来会通过扩展数据库和redis主从结构进行优化
