電商系統常見存儲問題

如何避免重複下單

解決辦法是，讓你的訂單服務具有冪等性。什麼是冪等呢？一個冪等操做的特色是，其任意屢次執行所產生的影響均與一次執行的影響相同。也就是說，一個冪等的方法，使用一樣的參數，對它進行調用屢次和調用一次，對系統產生的影響是同樣的。

咱們給訂單系統增長一個「生成訂單號」的服務，這個服務沒有參數，返回值就是一個新的、全局惟一的訂單號。在用戶進入建立訂單的頁面時，前端頁面先調用這個生成訂單號服務獲得一個訂單號，在用戶提交訂單的時候，在建立訂單的請求中帶着這個訂單號。

這個訂單號也是咱們訂單表的主鍵，這樣，不管是用戶手抖，仍是各類狀況致使的重試，這些重複請求中帶的都是同一個訂單號。訂單服務在訂單表中插入數據的時候，執行的這些重複 INSERT 語句中的主鍵，也都是同一個訂單號。數據庫的惟一約束就能夠保證，只有一次 INSERT 語句是執行成功的，這樣就實現了建立訂單服務冪等性。

如何解決 ABA 問題？

ABA 問題怎麼解決？這裏給你提供一個比較通用的解決方法。給你的訂單主表增長一列，列名能夠叫 version，也便是「版本號」的意思。每次查詢訂單的時候，版本號須要隨着訂單數據返回給頁面。頁面在更新數據的請求中，須要把這個版本號做爲更新請求的參數，再帶回給訂單更新服務。

訂單服務在更新數據的時候，須要比較訂單當前數據的版本號，是否和消息中的版本號一致，若是不一致就拒絕更新數據。若是版本號一致，還須要再更新數據的同時，把版本號 +1。「比較版本號、更新數據和版本號 +1」，這個過程必須在同一個事務裏面執行。

UPDATE orders set tracking_number = 666, version = version + 1WHERE version = 8;
複製代碼

如何解決修改價格後用戶頁面的價格未變化

首先，商品系統須要保存包含價格的商品基本信息的歷史數據，對每一次變動記錄一個自增的版本號。在下單的請求中，不只要帶上SKUID，還要帶上版本號。訂單服務以請求中的商品版本對應的價格來建立訂單，就能夠避免「下單時忽然變價」的問題了。

可是，這樣改正以後會產生一個很嚴重的系統漏洞：黑客有可能會利用這個機制，以最便宜的歷史價格來下單。因此，咱們在下單以前須要增長一個檢測邏輯：請求中的版本號只能是當前版本或者上一個版本，而且使用上一個版本要有一個時間限制，好比說調價5秒以後，就再也不接受上一個版本的請求。這樣就能夠避免這個調價漏洞了。

數據庫事務

如何用ES快速地實現搜索提示功能

由於用戶每輸入一個字均可能會發請求查詢搜索框中的搜索推薦。因此搜索推薦的請求量遠高於搜索框中的搜索。es針對這種狀況提供了suggestion api，並提供的專門的數據結構應對搜索推薦，性能高於match，但它應用起來也有侷限性，就是隻能作前綴匹配。再結合pinyin分詞器能夠作到輸入拼音字母就提示中文。若是想作非前綴匹配，能夠考慮Ngram。不過Ngram有些複雜，須要開發者自定義分析器。好比有個網址www.geekbang.com，用戶可能記不清具體網址了，只記得網址中有2個e，此時用戶輸入ee兩個字母也是能夠在搜索框提示出這個網址的。以上是我在工做中針對前綴搜索推薦和非前綴搜索推薦的實現方案。

mysql怎麼能避免寫出慢SQL

• 使用索引避免全表掃描
• 分析 SQL 執行計劃

mysql如何應對高併發

• 使用緩存
• 讀寫分離