作為流量充值的中間商，賺取差價。月流水最高8百萬元。
專案一分為二，乙個是接收客戶訂單，乙個是根據客戶訂單下單給**商。我主要負責的是接收客戶訂單部分。
校驗請求資料、token 以及簽名
生成 token
根據使用者 id 生成 token
使用 jwt，引數有 user_id, timestamp, secret_key, algorithm
使用者根據請求引數生成簽名
將請求引數字典按照 key 排序，並拼接:
key1=value1&key2=value2
校驗 token
使用 jwt.decode 解碼 token 資訊，不能解碼則拒絕
校驗 token 的 user_id 是否有效
校驗 token 是否過期
校驗簽名
將請求的引數按上述規則簽名，然後比較簽名與傳遞來的是否相同。
根據手機號等資訊獲取**，沒有**，返回失敗(讀庫1次)
根據使用者傳遞的引數以及**資訊建立訂單(寫庫1次)
將訂單 id 放入 worker 中處理
返回使用者下單成功
校驗使用者餘額是否足夠（餘額存放在 redis 中，定期同步到 mysql）
不夠足夠
獲取設定好的**商
根據流量包大小以及手機**商、省份獲取**商列表。
下單給另一部分。
下單到**商
下單給**商，如果失敗則重試。重試的順序是傳送過去的**商列表的順序。
有結果後，**給接收客戶請求的專案。
接收**
充值成功
更改資料庫狀態，**使用者
充值失敗
退款，更改資料庫狀態，**使用者
**的處理
使用了 grequests 以及 celery 的 -p gevent -c 100
問: 使用 grequests 的原因
grequests 使用 gevent 傳送非同步 http 請求。通過復用網路 io 來保持大量連線。
-p gevent -c 100
實現多次**
參考: celery best practices
python話費充值 手機話費充值
status 0,msg ok result mobile 15158825888 amount 0 list name areaid 30 company 移動 province 浙江 amount 1 adviceprice price 1.10 limitprice sms recharget...
流量系統專案總結
這兩周技術部安排我開發公司的流量系統，從拿到需求直到完成整個過程，才明白開發系統的定義是什麼，具體來說分為一下幾部分 第一 技術上 拿到需求後我的第一件事就是要確定整個系統開發的過程中難點在什麼地方，經過自己的思索以及技術主管陳從雲的指點，那就是演算法比較複雜，我想這個應該是 沒有什麼問題 基本上把...
專案 流量削峰技術
秒殺令牌的原理和使用方法 秒殺大閘的原理和使用方法 佇列洩洪的原理和使用方式 存在缺點 秒殺下單介面會被指令碼不停的刷 秒殺驗證邏輯和秒殺下單介面強關聯，冗餘度高 秒殺驗證邏輯複雜，對交易系統產生無關聯負載 秒殺介面需要依靠令牌才能進入 秒殺的令牌由秒殺活動模組負責生成 秒殺活動模組對秒殺令牌生成全...