經驗教訓總結

經驗

1不要相信任何輸入---要作好參數驗證

2函數意圖要簡單---只作一件事，徹底獨立的與其餘函數沒有關聯

3測試環境有錯誤，必定要解決---線上也確定會出現

4需求有不明確必定要追究到底5WHY法。腦補只會出現需求bug

5保障軟件質量惟有測試一條路，方法有：自動化測試、人工測試、持續集成的驗證。

6敏捷開發前期準備耗時長，但節省長期成本，構建質量更高的產品。

7遍歷過程不容許進行長IO操做（數據庫查詢）

8作活動次數限制不能用「==」來限制，應該使用">="或"<="

9發佈測試環境後應先自檢，不能把全部的工做都交給測試小姐姐來檢查。發佈測試環境和正式環境都須要先列檢查點。發佈正式環境依照測試環境的流程執行。

10代碼修改必定要把影響點都測試到，上線前通知相關業務方。

11代碼自己必定要能區分環境，不然開發很麻煩！

12需求改動都須要寫入到文檔中，口頭溝通會出現扯皮狀況。
13作事必定要想清楚後再行動，不然容易陷入細節。想清楚的標準是每一步都是肯定，均可以驗證！

14與人溝通必定要帶上下文（講背景），最好舉個栗子！

 

問題：

1cas適用於保證高併發狀況下對同一條記錄一致性，高併發寫重複適用redis鎖或mysql惟一索引來保證！！！設計表的時候要肯定是否存在高併發狀況，存在必須設置一個惟一索引！！！

2系統內存不足須要統計下是否真佔用不少內存，有多是slab佔用太多沒釋放致使的，相關命令有top,cat /proc/meminfo, cat /proc/slabinfo,systemtap

3系統硬盤空間不夠，要確認是否真佔用不少空間，有多是文件緩存。相關命令有lsof

查問題流程：

1確認現象-觀察流量、負載、日誌（關鍵）

2是否新業務上線

3是否生產代碼部署有缺漏

    a:代碼未更

    b:多臺代碼不一致

    c:配置錯誤

    d:數據庫表未上線

    e:redis連接是否正常

    f:依賴接口端口是否可訪問

4外部環境是否發生變化

    a:fb、微信限流

 

修復bug流程：

1（最快）最短路徑復現問題

2修復bug

3提交pr

4經過ci檢查

5合併分支

6發佈上線

7觀察數據