源碼->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
個人感覺本課程是自己目前在慕課網看到的最實用的項目,附上自己的代碼:https://github.com/QiXingjun/seckill
2017-02-22