秒殺搶券系統往往有一些需要注意的具體的地方，有介面安全方面的，也有資料庫安全方面的，高併發方面的，這裡主要從前後端兩方面進行闡述。
前端的一條原則：盡可能地保證發往後端的資料和請求是有效的。
具體措施如下：
比如，對需要輸入手機號的秒殺搶券活動來說，為了避免掉惡意請求，盡量在前端新增手機號合法性的驗證。當然，隨著手機號的不斷增多，現在已經出現19+開頭的號碼，雖然前幾年的驗證方法很可能已經不適用於現在的實際情況，但是可以不用校驗那麼嚴格和具體。這樣可以一定程度上保證資料的有效性。
再比如，為了後端在一定程度上避免處理無效請求，在前端傳送 http 請求時，可以在請求頭 authorization 新增介面簽名，簽名值可以**於時間等動態引數的簡單加密。這樣可以一定程度上保證請求的有效性。
後端的一條原則：盡可能地保證有效的請求才能發往資料庫。
具體措施如下：
歸根到底，秒殺搶券活動很多情況下都是搶乙個券碼，那我們肯定在資料庫中提前準備了乙個券碼表，這個表至少必須有主鍵 id 和券碼串 code 吧。所以其實秒殺的就是個id，買房搖號也是一樣分配了乙個自增的 id，若 id 在庫存量之內就代表搖上了，稍微大一點代表還有機會，可以等前面的人放棄資格，若號碼太靠後的話，就只存在理論上搖到的可能了。
那麼，這麼重要的 id 選用redis維護的原因是什麼呢？
redis作為分布式nosql，便於後端秒殺服務節點的橫向擴充套件，不用考慮跨jvm對id的分布式鎖；
redis採用記憶體儲存，性能夠好，訪問夠快；
redis處理請求單執行緒，原子自增操作是執行緒安全的。
另外，redis 除了維護自增 id 之外，也儲存了參與資格名單、參與歷史記錄等，這一點主要考慮到redis 可以幫助底層資料庫做一層快取，減少資料庫 io 壓力。
經過這樣的設計，最終真正訪問資料庫的有效請求只有最大庫存數量一樣多，每乙個訪問資料庫的請求都應當返回乙個券碼，做到了彈無虛發。
Square Cube 系統注意事項
cube是乙個採集基於時間的事件資料並時行度量分析的系統 基於node.js 純js框架系統，是乙個殭屍專案，已經3年沒更新了 作者沒有關閉專案的原因是給感興趣的開發者了解，僅能限於內部使用 先將自己安裝部署過程中的注意事項記錄如下 b 1.需要先安裝 node.js npm mongodb b 1...
android Hid 實現注意事項
使用cypress平台上時，除錯a g sensor時，通過hid協議在android上列舉出hid的裝置檔案，因為a g是一體的，所以cypress將a g的資料通過乙個hid通道資料傳送，android層主動傳送取資料的命令，cpress 這面將資料傳送到hid裝置檔案中，但是遇到有時候a g的...
實現Autolayout的注意事項
要想實現autolayout，有以下幾個注意 1 在裡面的 build.gradle 裡面的dependencies 加compile com.zhy autolayout 1.3.4 2 在清單檔案裡加以下句子，和 acitivity 同級別。720和 1280 是設計稿的寬高，以 px為單位 所...