同事在初始化redis配置的時候，給dial函式賦值時用了閉包，導致程式上線後，資料怎麼都載入不到redis中去，排查了半個多小時，總算找到了罪魁禍首。雖然自己之前對閉包也算了解，但是看到他的那段**的時候，乍一看竟也沒發現出問題來，所以決定寫篇文章加深印象，避免自己以後也犯類似的問題。
先上**：
func initredis() error
if gconfig.conf
.password != ""
}return c, err},}
c.prefix = gconfig.conf
.prefix
gredis[gconfig.name] = c
}return nil
}
乍一看是不是很難發現問題到底出在哪，我們當時碰到的問題是，資料沒有從db載入到redis伺服器1中，經過排查，發現db的資料全載入到了redis伺服器3中了。恰巧redis伺服器3是配置檔案中的最後乙個，也就是for迴圈中遍歷的最後乙個。進而我們發現dial函式對應的閉包函式裡引用了gconfig這個自由變數。
這會導致什麼問題呢？我們先來溫習一下閉包的特性：有自由變數的匿名函式是閉包，閉包的特性，就是內層函式引用了外層函式中的變數，注意是引用哦。
所以，這會導致redis連線池中每個連線去做dial的時候，拿到的都是for迴圈中最後乙個gconfig，即連線的都是redis伺服器3，去redis伺服器1裡面拿資料當然就什麼都拿不到了。
c thread 使用不當導致的崩潰問題
看個例子 1 class ctimer7 開始8void start 914 15void run 1622 23 結束24 void stop 2532 33 private 34 std thread t 35 std thread t1 36int i 37 bool b exit 38 39...
Select 使用不當引發的core，你應該知道的
排查乙個宕機問題，搞了好幾天時間，最終確定原因 最終確定問題原因，在此分享一下 如下rip不正確，指令位址錯亂，棧資訊已破壞 在此基礎上準確定位非常困難，但是仍可發現一些線索 根據當前棧資訊，大概尋找到懷疑的函式 檢視整個棧上下資訊，看有無懷疑的函式 所以很有可能就是fetchnsaddrev函式導...
快取如果使用不當會造成什麼後果？
了解什麼是 redis 的雪崩和穿透？redis 崩潰之後會怎麼樣？系統該如何應對這種情況？如何處理 redis 的穿透？對於系統 a，假設每天高峰期每秒 5000 個請求，本來快取在高峰期可以扛住每秒 4000 個請求，但是快取機器意外發生了全盤宕機。快取掛了，此時 1 秒 5000 個請求全部落...