使用thrift搭建的系統已經穩定執行了一段時間了，該系統是公司的核心流式系統，高峰時qps在40萬。作為目前最流行的rpc框架，thrift不僅提供了通訊協議，同時提供了網路框架，解脫了程式設計師的生產力。thrift也是阿帕奇hadoop系列的rpc實現工具。本文主要聚焦在搭建c++實現的thrift系統中，遇到的各種問題。
但是thrift在隱藏一些底層細節的同時，也給應用層帶來了一些不確定性，這些不確定和誤解，導致一些異常事件的發生。總結如下：
thrift compile在生成檔案的時候，生成php檔案時，同一命名空間下，不同的thrift檔案生成types.php，會導致檔案覆蓋（cpp和python沒有此問題）
服務端在採用tbufferedtransport時，該物件實際會自己快取read/write buffer，當catch到異常時，僅僅close對應的socket，buffer並不會清空。此時如果再次open socket傳送資料，會導致buffer資料混亂，transport出現異常。解決的方法是把指向該tbufferedtransport的shared_ptr.reset()。
服務端和客戶端採用的協議必須一樣。服務端用tbufferedtransport，客戶端不能用tframeworktransport，否則會異常。客戶端報can't write *** bytes的異常
有時候會設定服務端和客戶端的超時，這時候如果另外一方在接/發資料的時候，未能在timeout時間內完成資料傳輸，則會由於另外一方的強制斷開而報異常。異常的內容是：broken pipe
如果thrift服務經常catch到異常，且異常的內容每次都不同，如broken pipe, no more data to read等，很有可能是在客戶端，多個執行緒共用乙個socket，卻沒有加鎖導致的heisenbug
服務端hander中，使用者實現的服務介面，不能有block的**，如sleep()，lock.wait()，否則會導致工作執行緒被阻塞。這樣引起的後果是：1，客戶端請求執行緒被卡死在socket::read()；2，服務端fd洩露
thrfit的client不能在多個執行緒間不加同步的復用，因為client不是執行緒安全的。
YII踩坑紀錄
username trim username required message 使用者名稱不能為空 username unique targetclass common models user message 使用者名稱已存在 username string min 6,max 60,toolong...
Vue踩坑紀錄
前端 vue,vuetify 後端 flask,flask cors 資料庫 mongodb 前後通訊 axios dashboard methods get defkey index key index db.sns.find sort datetime 1 return dumps key in...
web開發前端踩坑
1.inline block總會有間隙 前端布局對齊也可以使用float，但是這樣做會導致被作用塊不佔高度 相當於不存在，脫離了文件流，但是會顯示 前面的塊不佔高度後面跟著的不需要對齊的塊就可能會和前面的塊擠在一起 各種異常 float很好用，但是怎麼才能避免塊坍塌呢？1.在結束float的塊後面加...