高并发之性能、可用性和可扩展性

在提升系统性能方面我们一直关注的是系统的查询性能，通过数据库的分布式改造，各类缓存的原理和使用技巧。究其原因在于我们遇到的大部分场景都是读多写少，尤其是在一个系统的初级阶段。

高并发写请求的场景，其中秒杀抢购就是最典型的场景。
假设你的商城策划了一期秒杀活动，活动在第五天的 00:00 开始，仅限前 200 名，那么秒杀即将开始时，后台会显示用户正在疯狂地刷新 APP 或者浏览器来保证自己能够尽量早的看到商品。
这时，你面对的依旧是读请求过高，那么应对的措施有哪些呢？
因为用户查询的是少量的商品数据，属于查询的热点数据，你可以采用缓存策略将请求尽量挡在上层的缓存中，能被静态化的数据（比如商城里的图片和视频数据）尽量做到静态化，这样就可以命中 CDN 节点缓存减少 Web 服务器的查询量和带宽负担。Web 服务器比如 Nginx 可以直接访问分布式缓存节点，从而避免请求到达 Tomcat 等业务服务器。

解决方法无非有几种：

1. 使用锁的方式，比如分布式锁，也可以利用redis本身操作原子性的特点
2. 写入消息队列，在消息队列中做减库存的操作，做异步校验

在用户下单的时候，用了redis的原子性减库存，如果不支付，一般可以设置一个定时器，定时器时间一到，就把库存加上，同时定义订单失败

比如1000件商品 系统生成1000个令牌 拿到令牌的用户可以进入消息队列，其他未拿到令牌的直接返回已抢完。