源码->https://github.com/fattypiggy/Seckill 请大家fork和star 多多交流
2017-03-03
没有实现过秒杀功能,但感觉上通过可靠队列序列化请求,根据秒杀数量(如1000),直接入队满足需求的数量的请求(如1500),后续到来的请求直接返回秒杀结束,这样就缩减了秒杀对底层的压力。
2017-02-26
老师在课程中挺多观点都是很有借鉴意义的,如service方法全部进行单元测试,缓存使用,秒杀瓶颈分析等,但就秒杀方案本身来说是很不完整的,不知道是讲师录课程时关注点还是忽略了,就我目前想到可能存在的问题有:1.请求未过滤,很可能出现通过程序秒杀的情况;2.性能本身极限受控于数据库性能,当有较大用户量参与的秒杀时只能重新设计方案;3.如果出现分库分表的情况,秒杀级别应该就不止6000qps能够满足的了,而且随着参与人数增加,锁竞争会更加激烈,性能应该会有较大降低4.感觉该方案只适合低用户量时快速实现秒杀的需求;5.阿里的代码规范里也提出了禁止使用存储过程,从个人经验看,存储过程维护起来的确麻烦;
2017-02-26
存储过程中,row_count()函数用来返回上一条sql(delete,insert,update)影响的行数。
根据row_count()返回值,可以进行接下来的流程判断:
0:未修改数据;
>0: 表示修改的行数;
<0: 表示SQL错误或未执行修改SQL
根据row_count()返回值,可以进行接下来的流程判断:
0:未修改数据;
>0: 表示修改的行数;
<0: 表示SQL错误或未执行修改SQL
2017-02-22