“秒杀”问题的数据库和SQL设计
1. 问题的来源
最近发现很多人被类似秒杀这样的设计困扰，其实这类问题可以很方便地解决，先来说说这类问题的关键点是什么：
一定要高性能，不然还能叫秒杀吗？
要强一致性，库存只有100个，不能卖出去101个吧？但是库存10000实际只卖了流量交易9999是否允许呢？
既然这里说了是秒杀，那往往还会针对每个用户有购买数量的限制。
总结一下，还是那几个词：高性能强一致性！
下文的所有解决方案是在 Mysql InnoDB 下做的。因为用到了很多数据库特性。其他的数据库或其他的数据库引擎会有不同的表现，请注意。
2.完全不考虑一致性的方案
2.2 方案
表结构很简单，其实就是一个 user 和 deal 的关联表。谁买了多少就插入数据呗。首先，还要检查一下传过来的 buy_count 是否超过单人购买限制。接下来，每次插入前执行以下以下操作检查一下是否超卖即可：select sum(buy_count) from UserDeal where deal_id = ?最后还要检查一下这个用户是否购买过：select count(*) from UserDeal where user_id = ? and deal_id = ?全都没问题了就插入数据：insert into UserDeal (user_id, deal_id, buy_count) values (?, ?, ?)
2.3存在的问题
大家别笑，这样的设计你一定做过，刚毕业的时候谁没设计过这样的系统啊？而且大部分系统对性能和一致性的要求并没有那么高，所以以上的设计方案还真是普遍存在的。那就说说在什么情况下会出问题吧：
如果库存只剩一个，两个用户同时点购买，两个人检查全部成功，最后，就超卖了。
如果一个用户同时发起两次请求，检测部分同样可能会同时通过，最后，数据就异常了。
那就让我们一步步来解决里面存在的问题吧。
3.保证单用户不会重复购买
先来解决最简单的问题，保证单用户不会重复购买。
其实只要利用数据库特性即可，让我们来加一个索引：alter table UserDeal add unique user_id_deal_id(user_id, deal_id)加上唯一索引后，不仅查询性能提高了，插入的时候如果重复还会自动报错。当然别忘了在业务代码中 catch 一下这个异常，并在页面上给用户友好的提醒。
4. 解决超卖问题
4.1 方案
为了解决这个问题，第一个想到的就是把这几次操作在事务中操作。否则无论怎么改，也都不是原子性的了。但是加完事务后就完了？上面的 select 语句没有使用 for update 关键字，所以就算加入了事务也不会影响其他人读写。所以我们只要改一下 select 语句即可：select sum(buy_count) from UserDeal where deal_id = ? for update
4.2 优化
刚改完后发现，问题解决了！so easy！步步高点读机，哪里不会点哪里，so easy！但是不对啊！为什么两个用户操作不同的 deal 也会相互影响呢？原来我们的 select 语句中的查询条件是 where deal_id = ? ，你以为只会锁所有满足条件的数据对吧？但实际上，如果你查询的条件不在索引中，那么 InnoDB 会启用表锁！那就加一个索引呗：alter table UserDeal add index ix_deal_id(deal_id)
05. 提高性能了
好了，到目前为止，无论用户怎没点，无论多少个人买同一单，都不会出现一致性的问题的。
而且事务都是行锁，如果你的业务场景不是秒杀，操作是分散在各个单子上的。而且你的压力不大，那么优化到这就够了。但是，如果你真的会有几万人、几十万人同时秒杀一个单子怎么办？很多交易类网站都会有这样的活动。我们现在思考一下，上面的优化好像已经是极致了，不仅满足了一致性，而且性能方面也做了足够的考量，无从下手啊！这时候，只能牺牲一些东西了。
06. 鱼与熊掌不可兼得
6.1 优化的思路
性能和一致性常常同时出现，却又相互排斥。刚才我们为了解决一致性问题带入了性能问题。现在我们又要为了性能而牺牲一致性了。这里想提高性能的话，就要去掉事务了。那么一旦去掉事务，一致性就没办法保证了，但有些一致性的问题并不是那么地严重。所以，这里最关键的就是要想清楚，你的业务场景对什么不能容忍，对什么可以容忍。不同业务场景最后的方案一定是不同的。
6.2 秒杀可以容忍什么
本文标题说的是秒杀，因为这个业务场景很常见，那么我们就来说说秒杀。秒杀最怕的是超卖，但却可以接受少卖。什么是少卖？我有一万份，卖了9999份，但数据库里却说已经买完了。这个严重吗？只要我们能把这个错误的量控制在一定比例以内并且可以后续修复，那这在秒杀中就不是一个问题了。
7. 为了性能牺牲一致性的设计方案
7.1 去掉了事务会发生什么
在上述的方案中，如果去掉了事务，单用户重复购买是不会有问题的，因为这个是通过唯一索引来实现的。所以这边我们主要是去解决超卖问题。既然去掉了事务，那么 for update 锁行就无效了，我们可以另辟蹊径，来解决这个问题。
7.2 修改表结构
刚才一直没有提 Deal 表，其实它就是存了一下基本信息，包括最大售卖量。
之前我们是通过对关联表进行 sum(buy_count) 操作来得到已经卖掉的数量的，然后进行判断后再进行插入数据。现在没了事务，这样的操作就不是原子性的了。所以让我们来修改一下 Deal 表，把已经售卖的量也存放在 Deal 表中，然后巧妙地把操作转换成一行 update 语句。
在 G2 4.0 的重构的开发过程中，我们主要关注在架构、交互和图表的体验上；这次我们对 G2 的性能做一个整体的评估，分析其中的性能问题点，最终完成性能的优化；使得 G2 在大数据量情况下也拥有良好的性能。
文中描述的模块性能优化的方法，也可以借鉴到其他的地方。
性能评估
先评估下 G2 目前的性能数据：可以想象到的影响 G2 渲染性能的自变量包括：数据量、Geometry 类型、辅助组件(Label/Annotatio)使用情况，对这些自变量进行测量和验证。
数据量对初始渲染时间的影响
实验中数据量范围: [100, 20000]，使用的 geometry 类型为 line，实验中的因变量为渲染时间即图表的初始渲染时间
Geometry 类型对初始渲染时间的影响
这次实验针对大数据量情况下常用的 line/area/point 三种图形来进行测量 Geometry 类型说明：point、line、area、line+point、area+point
型对初始渲染时间有影响，Geometry 数量对初始渲染时间强相关，在数据量大后渲染时间甚至和Geometry数量成线型关系了；同时 Geometry 数量对初始性能渲染时间影响大于 Geometry 类型对初始渲染时间影响。
Label 数据标签使用对初始渲染时间影响
这次实验以折线图、折线图开启数据标签label、折线图开启数据标签并配置 label layout 三组来进行对比
的开启和 label layout 使用会明显的影响图形的初始渲染性能。
性能分析
在上面对几个自变量对性能影响的实验测量后，这里来针对一个具体的数据量来进行性能分析，定位造成性问题的瓶颈点。我们用 Chrome 的 performance 工具来对 10000 数据量的图形渲染进行 profile 分析：
首先我们对初始的渲染分成四个阶段，分别对应 G2 内部渲染的四个阶段