方永、南天紫云

道亦有道

Rust与oracle、redis集群的纠结
2018年01月26日

最近用 rustRocket web框架做了一套api接口,记录一下遇到的问题。

一個年底活動的項目,前後端分離,後端以json api的形式與前端交互。

後端也就幾張表,幾個前端接口,但是接入了 5 類接口,且有3類在內網,2類使用java生態的協議,dubbo和hessian,項目時間很緊張, 沒時間去分析實現這倆協議,用java做了轉接。

數據庫是oracle db,rust的oracle驅動crate倒是有幾個,最後用了mimir,這個基於odpi的庫除了調試信息不多,沒guide文檔外, 其它還算好,也封裝了odpi的連接池,但文檔裏沒說明這個不是線程安全的,將pool作爲rocket的guard,編譯沒有問題,運行時經常 get_connection失敗,用wrk加點壓力,然後隨機coredump,好吧,換用單鏈接吧。由於只是驅動,所以操作都是拼sql語句,做了 個trait,復用從一個查詢裏取結果並查詢每列的結果等等這些瑣碎的操作吧。

然後上準生產,操作系統是redhat6,本機編譯的二進制glibc太老,跑不起來,編譯新版本的glibc並加載,運行時coredump,在這臺服務器編譯, 報一堆錯誤,看到由一個名爲ring的crate引起,這個庫被cookie依賴,cookie被rocket依賴,在Cargo.toml裏patch cookie,ring的 依賴並沒有去除,分支rocket並patch rocket,生效。吐槽一下ring,一是鎖定rustc版本,一是鎖定gcc版本,大家寫代碼是要上生產的,不是 玩兒的,ring的作者你太任性了!去除了ring的依賴,順利編譯完成。

但是,運行時又會有moved的報錯,一看原來準生產redis是集羣,crate redis並不支持集羣方式,找到redis-cluster,用之,建立連接時有錯, 分析並patch,第二天前端反應接口超慢,一開始以爲oracle調整了,各種排查,到下午打日志,看到redis的get請求居然有幾十秒,WTF,換用 td_rredis,世界清靜了。

然後上生產,老是auth required,redis的password是配置了的,於是忍受着堡壘機後面的生產服務器的龜速,打日志,好吧,三主三從,只給三主 配了密碼,其它的還得加。終於上線了,happy。

領導看了,提出意見,改,再上線。

上線時,居然實例一直超時,有很多請求,但也不至於啊。。。 使用openresty將前端的index代理了,ok了。 再看統計數據一天十來萬的注冊量,還行,qps應該不低,那就得找找index的原因了。

而這一切,都發生在幾天的時間裏。尤其是ring的問題,程序都寫好了,跑不起來,都可以讓人懷疑人生了。

總結一下,時間是一個致命點,太短的時間,太多的問題,這個劑量的壓力足以搞死一頭牛。 rust的crate是另一個坑,去crates.io想給ringredis-cluster差評,無奈並沒有這個功能。那麼應該會有人前赴後繼地掉坑吧。

2017年博客只寫了一篇水文,這篇本來也不想寫的,怕2018一篇都沒有,聊充個數吧。