前天ksearch效能壓測過程中發現乙個很奇怪的問題，跟了3天，case做了無數個，終於發現問題所在，還是kfc（kuafu communication）的問題。然後想起來，去年實時搜尋上線前夕，也遇到乙個很奇怪的問題，最後定位出來也是kfc的問題，異常鬱悶，所以這裡記錄一下。
ksearch的服務框架：search和merge兩種角色，search負責真正的儲存和檢索，通過行結構做災備，列結構獲得大資料量和高qps；merge對外提供服務，對內**請求給相應列的search機器；search和merge之間的網路和角色，是通過kfc管理的。search的每一列負責同乙個key的請求，merge通過key_send**請求到相應search機器。kfc對我們來說是一套黑盒系統，只是聽老大說很nb，很多部門都在用；使用過程中碰到了很多蛋疼的問題。以後有這種涉及到效能的大型系統，千萬不要信黑盒系統，不管別人說它多麼nb。
case 1： 2行6列search，merge復用第一行的前兩台機器
現象：通過merge壓測時，如果把query落在單獨一列，不管是高併發還是低併發，由於search服務能力很強，可以很輕鬆把merge網路壓滿，達到10k的qps；用abench -r壓也可以輕鬆達到8k以上沒有異常。但是如果query落到所有列上，低併發情況下，可以達到10k；如果用高併發壓，發現qps只能達到5k左右；用abench -r壓2k的qps都會有很多超時，和預期相差很大。看merge機器，不管是程序還是系統，都遠遠沒有達到瓶頸；而且search機器也很空閒。由於下週就要上線，相當操蛋。
針對這個問題，我們做了以下實驗：
1. 只壓到兩列的query，結果跟壓全列query一樣，說明不是機器規模問題。
2. 調整query返回結果大小，發現高併發下qps跟返回結果大小成反比，即返回結果越小，qps越高；而實際上返回結構大小，search處理時間幾乎不會變化。 說明還是網路的問題。
3. 分析log發現，不管高併發還是低併發，search機器處理query的平均時間沒有變化，但merge機器觀察到search的latency卻有很大變化。網路通訊我們用的是kfc，說明問題出在kfc身上。
還有其他一些，不一一列了，最後確認是同一臺機器復用search和merge，觸發了kfc的效能問題；通過調整系統部署解決。
case 2: 2行22列，3臺merge
現象：merge總是觀察到批量超時，每次一有query超時就超一批，對超時query分析發現，每一批中一般只有乙個大賣家，其他都是小賣家。大賣家超時是可以預期的，小賣家超時卻沒辦法解釋。
case做了一大堆，糾結到最後發現是因為，kfc分發訊息時使用round-robin方式，假設有10個server提供服務，來了1000個query，他會為rr的為每個server分100個query，而不是哪個server閒著就分配給哪個。這樣就有問題了，如果有乙個大賣家堵住了乙個server，其他的query就在他後面排隊，等到第乙個大賣家超時，後面堵著的所有賣家都超時了。
服務端開發筆記三 pemelo開發過程中遇到的問題
問題 首先需要弄明白的是，乙個客戶端只有乙個pomelo例項。當使用者登入之後，不退出，重啟客戶端。伺服器檢測到玩家已經登入，會將之前的登入踢下線，客戶端會觸發disconnect事件，在disconnect中斷開pomelo鏈結。這樣導致當前的鏈結也被斷掉了。解決方案 目前處理方式是在discon...
開發過程中錯誤總結
1 18年5月28日 說明是.xml檔案的問題。去上.xml排查，看是不是註解。或者檔案本身書寫有誤。2 linux下 webstorm,ppt,wps不能書寫漢字。在啟動檔案中修改 啟動 sudo sh webstorm.sh export xmodifiers im fcitx export q...
某店鋪收銀系統開發過程中出現的幾點問題
1 我們在開發該收銀系統過程中出現了一點 虎頭蛇尾 的苗頭，尤其是我們組，完成時間脫延，沒被挑中，大家都有點士氣低落。做到後來針對自己負責的模組不能最大程度上保持高度負責的態度，甚至有些技術問題出現的時候，更是 不假思索 將這類問題推出去。可喜可悲，可喜的是，如此機遇好好利用便能長人一步 可悲的是，...