前一段時間，部門接入了新業務，由於業務量小，架構非常簡單，採用了最簡單的lnmp架構，整個專案是交給乙個剛畢業的rd負責的，這是背景。
上線前半天，服務平穩執行。下午的時候，開始收到大量報警：no host could be connected in the cluster。第一反應：mysql伺服器不會掛了吧。開啟監控，一切正常，登入也一切正常，但報警一直沒有間斷，這奇怪了。
實際上一點都不奇怪。「no host could be connected in the cluster」本身不是mysql的錯誤，所以並不是mysql伺服器本身出了問題，問題的原因一定是出在封裝的底層的類庫，為了描述的更明白一些，我先總結一下這個mysql連線管理類庫的功能。
為了保證mysql服務的穩定性，我們的mysql連線類庫實現了乙個故障自動切換的功能：維護乙個當前的mysql伺服器的列表，每次連線時隨機選擇一台伺服器連線（這裡不考慮跨機房的問題，也不考慮選擇的演算法。選擇機器的演算法可以是隨機的，也可以是輪詢的，這不是關鍵），同時維護乙個失敗的伺服器列表。如果某一次mysql執行失敗，那麼便把這台伺服器從可用的伺服器中摘除，同時放置到失敗的伺服器列表中， 在一定時間內（interval,比如2s）這台mysql便不在被訪問。 需要注意的是，這台mysql並不是一直在失敗的伺服器列表中的，經過一段時間後，便會重新釋放，重新進入可用的伺服器列表中。這麼做的主要目的，是在某一台mysql伺服器發生故障時，由於這台mysql被訪問到的概率變小，不至於出現線上服務的大面積癱瘓，也給線上故障轉移提供更多的時間buffer。
問題就出在這裡！這個自動切換的功能只適用於mysql cluster，也就是存在多個mysql伺服器的情況，如果伺服器只有一台，那麼問題就很嚴重了：如果某一次mysql查詢執行失敗了，那麼這台mysql會被打入冷宮，在接下來的時間間隔內，便沒有任何可用的mysql伺服器了！這樣一來，流量一大，所有的interval間隔內的請求便都失敗了！這也是為什麼線上會出現大量的「no host could be connected in the cluster」的報警。
這個問題很典型，很多人不清楚類庫的作用，便信手拈來直接使用，所以出現問題的時候常常也是一頭霧水，不知從何下手。尤其在大公司中，類庫、工具、成熟的解決方案都比較齊全，在使用方便的同時，也隱藏了內部的實現邏輯，往往會造成「使用很熟練，原理一竅不通」的問題。
記錄自己一次艱難得DEBUG過程
debug問題 64位沒有錯誤，32位有錯誤 32位debug模式沒有錯誤，release模式有錯誤 release模式下第一次執行沒有錯誤，第二次執行有錯誤 整了三天徹底給我整蒙了 第乙個錯誤是因為32位記憶體不足無法分配的問題，我首先加了try塊捕捉記憶體不足的情況，並且反饋給dll的呼叫者 根...
一次糟糕面試的思考
1.溝通原則之一，在溝通過程中發現對方問的問題有問題時，應在融洽的氣氛中當面指出，事後想找機會指出是無力的，並且可能沒有這樣的機會。但切記不要將這一切變成一場爭論。2.溝通原則之二，當對方與你針鋒相對時應怎麼辦呢？最明智的做法首先應指明這種狀態，希望雙方冷靜下來之後尋求新的溝通方式。若這種方法無法湊...
Flash，一次Bug的思考
我絕對不算是f黑，大部分時候，我還是很挺flash平台的，flash提供了很好的跨平台特性以及flash player11後的gpu加速 stage3d等等，對於開發者來說，絕對讓人欣喜若狂 對我是這樣 flash出bug也算是常有的事，不過大都還好，我能理解adobe開發者們的辛苦，要考慮跨平台 ...