项目-设计高并发交易系统

1、引述

与秒杀活动相似，此外还具备两个自身的特点：

1）并发要求更高；2）更严格的安全级别；

体现在技术方案上，相比于秒杀商品，共同点是并发请求抢锁，此外还有两个突出特点：

1）事务级操作量大--并发高导致；2）事务要求严格--安全级别导致；

2、解决高并发常用方案

    方案一，使用内存代替实时的DB事务操作，然后异步DB持久化。优点是提高了并发性能，缺点是DB持久化失败或者内存故障都会导致丢数据，安全级别不适合；

    方案二，使用乐观锁。悲观锁，一个事务执行操作的数据，只有当该事务把锁释放，其他事务才可操作冲突的数据。乐观锁，维护DB库存记录的版本号，提交事务时检查版本号是否被修改，没有修改更新版本号，被修改则回滚事务抛异常。优点是提高了并发能力，缺点是抢到同一个商品的请求，只有一个会成功，用户体验不好；其次，手快的用户因为并发高会失败，手慢的用户因为并发小反而会成功，产生负面影响；最后，带来大量的无效请求、事务回滚，给DB造成不必要的压力，浪费资源；

3、采用的方案

1）系统垂直拆分--分而治之

所有的交易行为都和商品的ID关联，将商品ID按一定规则分组划分，同一个商品的所有操作只发生在一条垂直链上的服务器（也是集群的）和DB上，互不影响，海量化为小量，分而治之；

2）业务逻辑层，创建请求队列--减小并发

如果到达DB的事务操作不是并发的，而是串行的，就不会存在并发抢锁问题 。若要抢商品的事务操作串行进入DB，只需将业务层的请求以FIFO的方式排队，就可以达到效果。

分布式的FIFO队列方案：

• 同一个商品的ID所有请求绑定到同一个系统集合（垂直链系统），需要一个商品ID hash值的分流；
• 单机请求队列方案，同一台Server上所有请求，按照商品ID进行排队，串行执行业务逻辑（worker线程池），达到排队的效果；
• redis控制并发，为防止请求队列过载，利用redis的原子累增操作，控制同时进入DB执行抢商品事务的请求数，超过阈值拒绝服务；

3）设计双维度库表

按照商品ID和自然日两个维度分表，原因是随着商品数量增大，单表数据增加，DB性能下降；若将历史数据与当前数据分开存储（即冷热分离），可以解决这个问题，同时数据迁移也变得简单化。

综上所述，主要采用了集合化分治、请求排队、双维度分表等方案，可以使DB的并发性能提升8倍以上。