更新秒杀架构

Author: xbox1994

MD/秒杀架构.md

@@ -21,10 +21,27 @@
 2. 提供用户查询实时抢购状态功能，将抢购对象保存在Redis中来提供
 
 ### 服务模块
-1. RabbitMQ的消费逻辑、业务逻辑，使用事务控制下订单，减库存操作
+1. RabbitMQ的消费逻辑、业务逻辑，使用事务控制下订单，减库存操作，且下订单操作要放到减库存操作之前，可以避免减库存update的行锁持有时间
 2. 避免同一用户同时下多个订单，在订单表中加上用户ID与商品ID的唯一索引；避免卖超问题，在更新数量的sql上需要加上>0条件
 
 ### 防刷模块
 1. 针对恶意用户写脚本去刷，在Redis中保存用户IP与商品ID进行限制
 2. 针对普通用户疯狂的点击，使用JS控制抢购按钮，每几秒才能点击一次
 3. 在后台生成数学计算型的验证码，使用Graphics、BufferedImage实现图片，ScriptEngineManager计算表达式
+
+### 问题
+以上的解决方案能通过利用Redis与RabbitMQ集群来承载非常高的并发量，但是有如下缺点：
+
+1. 运维成本与稳定性。Redis与RabbitMQ都可能用到集群，运维成本太高，稳定性也不能保证
+2. 开发成本高。必须准备好异常处理方案，比如访问Redis或者RabbitMQ失败之后，如何保证秒杀功能正常进行下去
+
+另一方面，MySQL的性能并不慢，慢的是执行事务时**Java的GC时间**和**网络通信时间**
+
+## 另一种方案
+
+将业务逻辑写成存储过程，事先放到数据库中，在Java客户端中调用存储过程即可立即拿到返回结果
+
+### 问题
+
+1. 耦合且无法控制代码版本，把业务逻辑写到数据库里去了，以后更改逻辑会难以维护
+2. 会增大对MySQL的压力，且MySQL最大连接数需要扩大