《沉澱》是雲栖社群品牌欄目,在品味技術人百味人生的同時,也能夠幫助你沉澱技術,獲得點撥。工作中,如果有不錯的大牛讓你受益匪淺,也歡迎通過電子郵件([email protected])推薦采訪,讓更多人受益。我們的想法是:“如果你覺得某個技術挺棒的,不妨品味這些技術人背後的沉澱。”
1.畢業之後從事搜尋引擎工作,曾經負責三淘的搜尋業務(淘寶 天貓 一淘); 2.搜尋對穩定性和延遲的要求非常高,是以會有機會碰到各種問題,比如逾時、抖動等等,在解決這些問題的過程中積累了大量經驗也結識了很多人; 3.後來覺得雲計算在這塊會有更大的發揮空間,是以來了阿裡雲; 4.解了rds全鍊路上的很多重大的穩定性問題,如慢記憶體、erlang虛拟機排程不均衡、iohang等問題,同時也幫客戶解了很多自身的問題,進而挽留住了很多客戶; 5.将這些專家知識沉澱成天象系統,利用天象的資料再去驅動解決更多問題; 6.在rds期間也将沉澱的很多搜尋知識與資料庫相結合,探索出更多的産品形态,如petadata+sphinx; 7.随着對産品、技術、團隊了解的加深,接手ocs和kvstore的工作; 8.後續我們會如何發展kvstore/redis,參與社群建設、專注于核心、根據客戶需求推出更多豐富的産品形态; 9.nosql産品對延遲要求很高,而且是一個客戶的生命線,如何在業務飛速發展時給系統換輪胎,如何帶團隊探索更多的可能性; 10.對團隊的要求是做事情要麼不做,要做就要做到業界領先,不然對不起那麼好的機會和客戶的信賴.

圖:子嘉認為,隻要不退縮,一切問題都會有答案
雖然和子嘉一直是線上上溝通,從來沒有見過面,但給我的感覺,他是一個很為人着想的人。技術一般都很忙,尤其是帶團隊的技術人,然而面對郵件采訪前的準備,他一直很耐心地回複我種種疑惑。他很為人着想,怕自己太忙忘記回複,主動說起“記得提醒我”,甚至他還細心地整理了上述素材,供我靈活組織。
子嘉是一個很喜歡挑戰的人。因為挑戰,他一開始就選擇做搜尋引擎;因為挑戰,在擁有五年工作經驗後轉型到阿裡雲。那時的阿裡雲還是一個“大工地”,有太多的東西需要建設,有太多挑戰需要去面對,但他很自信,“如果你覺得這是一種信仰并堅信一定能行,其它的一切都不足為慮。”他說。
郵件采訪中,子嘉着重分享了他在工作上的一些信念。他認為,平時努力工作就是對未來最好的準備。面對一些技術難題,他堅信:“隻要不退縮,一切問題都會有答案。無論多難的問題,都應該給自己設立一個期限,然後提着頭就上。”
當然,他過去也有一些局限,看到每天都有人會問出同樣的問題,并且對同一個人解釋多次,也會有些生氣。當他突破這種局限,發現自己狹隘後,一個天象系統出來了,這個孕育出的産品和達成的效果都給他和他的大團隊帶來了很大的驚喜。
子嘉先後接觸過搜尋、雲計算、redis、nosql等技術,在這些領域不僅做的很好,還有所創新,他是如何做到的?他說,不挑活、勤思考、肯擔當,工作就是最好的學習途徑,“記住千萬不要挑活,有的同學覺得這個活沒有技術含量,那個活沒有前途,但是就沒想過這些‘沒技術含量’的活都做不好,怎麼能去幹那些有技術含量的活呢?”他很笃定,今天種下的種子在未來的一天終會發芽。
對于成長經曆,除了上面的“不挑活”,他還總結了另外九字:勤思考、多總結和肯擔當。“勤思考,幹活的時候多擡頭看看天,看看方向;多總結,很多人偏于執行而疏于規劃,這種習慣會造成中長期的悲劇,我自己也曾經犯過這個錯誤,交了很多學費;肯擔當,要努力讓自己成為團隊中可以依賴的人,不要讓自己成為可有可無的人,逃避責任隻會讓自己越來越被動。”
雲栖社群:請介紹下自己以及所從事的工作。
子嘉:我真實姓名叫蔡松露,2009年碩士畢業于上海交通大學,到阿裡工作已有7年多。目前主要負責阿裡雲的雲資料庫memcache(原ocs)和雲資料庫redis(原kvstore)産品。
雲栖社群:一開始為什麼會選擇走搜尋引擎的道路?
子嘉:主觀上當時覺得搜尋引擎對工程和算法的挑戰都非常大,我喜歡這種挑戰;客觀上當年金融危機,職位真心不多,hc也少,沒得選擇。
雲栖社群:面試阿裡的過程順利嗎,有沒有特别有意思的事分享一下?
子嘉:不算順利,面試了兩次,第一次應該是表現不好被默拒了。
第二次是補招,由于面試地點比較遠我就不想去了,被兩個平時一起玩的同學撺掇着過去的,後來的過程就比較順利了,面試我的是我後來的師兄和主管桂南,撺掇我的兩個同學也和我一起來到了那時的淘寶搜尋團隊。
雲栖社群:五年的淘寶、天貓、一淘搜尋業務有什麼收獲和心得?
子嘉:
收獲還是非常多的,從技術、管理到對業務和産品的規劃中都學到了很多:
2009年整個淘寶系處于業務飛速發展的時期,當時起了大量的項目,我從那時開始做了大量的項目管理的工作。項目管理貌似瑣碎複雜,但是又有中心和原則,有很多硬性的名額如品質和計劃,也有很多需要柔性去處理的風險和沖突,對管理能力和執行力是一種很好的鍛煉。 在做項目管理的過程中為了不使技術荒廢,最開始的時候我會争取了解每一塊技術的架構和細節——當然也是為了能夠做到掌控全局。不過,當項目越來越大的時候,你隻能去依賴和信任你的隊友。 對于工程師來說技術還是安身立命所在,但是每個工程師又是需要一定的項目管理經驗的,不然很多事情沒法開展和落地。項目管理段位太多,從1到10其實你自己都不一定知道處于哪個段位,技術沒做好項目管理段位又不高,練了一身四不像的本事是一件自毀前程的事情,你會發現上不去下不來,就那麼浮着很尴尬。其實判斷自己的段位也很簡單,人都是普遍高估自己,但是和比你優秀的人比一下就知道了,是以我對大家的建議是:起碼要做透做深技術,項目管理經驗是必要的,向比你優秀的人學習(看起來很大一鍋雞湯……)。 另外搜尋對資料的了解和營運也是比較深厚的,在這裡你能看到各種各樣的資料,也養成了我日後用資料說話的習慣。
當然也犯了很多錯誤,還好大家都比較包容我,我的老闆和大老闆都給予了我很大的支援和信任。
雲栖社群:能談談電商行業的搜尋業務和正常的搜尋引擎(如百度)有什麼差別嗎?
子嘉:還是有很大差別的,搜尋引擎的核心是了解、發現并精确比對使用者的需求,但是電商搜尋引擎在滿足這一點的基礎上,還要兼顧流量的公平性和效率的問題,為了維持生态的健康和繁榮,有時還要對抗“馬太效應”這種自然規律,需要tradeoff很多東西,而且你的每一個動作都會影響到很多人的生活,想到這一切都不輕松。
雲栖社群:從事了五年搜尋引擎工作之後,為什麼要投身于雲計算大潮?
子嘉:其實我一直都在關注雲計算,也一直在關注各種資訊和王博士對于雲計算的各種思考和客戶案例。從看不懂到看不清再到後來覺得這東西有點意思,慢慢地自己在這方面也有一些思考,到最終成為一種信仰,我覺得這東西一定能行。
雲栖社群:雲計算的發展已經經過一個階段,在這個階段轉型是否有什麼顧慮?周圍的人當時是怎麼看待你這個決定的?
子嘉:如果你覺得這是一種信仰并堅信一定能行,其它的一切都是不足為慮的。
我加入的時候雲計算剛剛走出泥潭,往滿了說也就是剛有起色,整個阿裡雲還是一個大工地,有太多的東西需要建設,有太多挑戰需要我們去面對,有太多使用者的期待需要你去完成;别人怎麼看你并不重要,關鍵是你怎麼看你自己,而且當你自己想清楚了之後,你周圍的人包括你的老闆都會尊重你的這個決定。
雲栖社群:轉型之路是否順利?為了順利轉型,你都做了哪些努力?
子嘉:挺順利的,沒有為轉型做過什麼特别的準備,隻要平時努力工作就是對未來最好的準備。
值得一提的是在過去的五年中我在搜尋引擎、分布式系統和底層上有了一些積累,而這些積累和雲計算相關的挑戰比較match,我也很喜歡去解集團各種各樣的無頭懸案,在這個過程中也有幸結識了未來的老闆褚霸——江湖人稱霸爺,所有的這些機緣巧合也算是努力的一種結果。
雲栖社群:你到rds團隊之後,解決了很多重大的穩定性問題,比如慢記憶體、erlang虛拟機排程不均衡、iohang等,其中,你對哪個最有成就感?哪個前後曆時最久?請談談過程和技術細節。
子嘉:有了之前的那些積累,解起這些問題來雖然有些挑戰,但也算輕車熟路了,而且最關鍵的是在這個過程中你的信心會被慢慢建立起來,我堅信隻要不退縮,一切問題都會有答案。無論多難的問題,都要給自己設立一個期限,然後提着頭就上。
時間最久的算是iohang了,因為這不是一個技術點的問題而是一個體系的問題,是以解起來周期比較長。
雲栖社群:在rds期間你還将搜尋知識與資料庫相結合,探索出更多的産品形态,如petadata+sphinx,在這個過程中有沒有遇到困難?都是如何解決的?
子嘉:當時是有一個時間序列日志資料庫的需求,為了降低成本,要滿足很多苛刻和變态的限制條件,而且還不能降低使用者體驗。
我做了很多調研和選型,最終決定用petadata+sphinx的方式,原生的sphinx無法處理那麼大的索引資料量,對于實時流式的資料處理也有很多限制,我利用在搜尋上的積累對整個架構做了大量的改造,并最終滿足産品和成本的需求,挑戰還是很大的。
雲栖社群:你還将專家知識沉澱成天象系統,利用天象的資料驅動解決了很多問題,請介紹下什麼是天象系統?為什麼要打造這樣的系統?
子嘉:當時霸爺(褚霸)和鳴嵩都有一個共識,要利用資料去回答,并解決我們系統中存在的問題,這算是天象的萌芽。圍繞着這個目标隻要是對這個目标有益的我們都去做,我們積極地去收集各種資料,然後将各種資料串聯起來,并在不同次元上對這些資料進行整合分析,最終孕育出的産品和達成的效果都給我們帶來了很大的驚喜。
做天象本身也是我自己成長和涅槃的一個過程,我積累了很多專家知識,但是這些知識僅限于我自己知道,我又比較懶,懶得寫文章去宣傳,是以我會看到每天都有人會問出同樣的問題。往往我對同一個人解釋一次,過段時間他又來問了,開始還有些生氣,後來我在做天象時突然意識到自己曾經是那麼狹隘,為什麼不直接用系統告訴大家發生了什麼呢?
是以從那時開始我會把所有解過的問題寫到天象代碼中,把所有之前回答問題的時間都用在了寫代碼沉澱上,希望這些技術能夠普惠更多開發者和客戶。
雲栖社群:請分析下redis優劣吧?
子嘉:redis是一款非常優秀的開源緩存類産品,遵循着簡單的設計哲學,這種哲學讓redis獲得了極大的成功。
當然任何事情都是兩面的,很多簡單的處理方式也帶來了一些問題,比如fork、aof rewrite等問題,我們也在着力去解這些問題。
雲栖社群:你認為什麼樣的架構或什麼類型适合用redis?
子嘉:緩存、kv持久化存儲、隊列服務等等,無法一一枚舉,總之勞動人民的智慧有多少redis可用的場景就有多少。
雲栖社群:redis的性能受制于哪些因素?順便分享下redis上的一些優化心得吧?
子嘉:前面講到的fork、aof rewrite、keys枚舉、弱網環境下主備同步等問題,我們針對這些問題也在做一些優化,心得就是上雲之後一切簡單的東西都會變得複雜,怎麼将這些複雜的東西簡單地呈獻給使用者是我們要思考的。
弱網環境下主備同步這個問題,原生的同步協定在斷網時間過長的時候backlog同步會失效,slave重連master會觸發dump rdb的操作。當執行個體比較多的時候這對主機和整個機房的帶寬都是一個災難,很容易出現機房斷網恢複之後又馬上被打死的重大故障,我們的優化就是如果同步走backlog,失效的時候走aof同步,不用做dump rdb——當然這個地方也是做了大量的優化。
雲栖社群:遇到redis通路異常,你的正常分析思路是什麼?
子嘉:第一是看監控,第二還是看監控,把所有能想到的問題和所有碰到過的問題都做到監控中。
雲栖社群:後續你們将會如何發展kvstore/redis?
子嘉:最近幾個月我們陸續會有多款産品對外釋出,比如全新的備份恢複功能、對lua的支援、多種sharding産品形态、跨機房容災等等。
對于大家無感覺的後端我們也會做大量的改造,比如核心熱更新、aof rewrite去除等,從更長遠的角度看,我們希望給大家提供最穩定、最高效、最豐富的redis産品,歡迎大家使用,也歡迎有志之士來共建。
雲栖社群:請分享下雲産品系統優化上的經驗。
子嘉:雲産品面臨的挑戰都是類似的,比如使用者要保持tcp連結不斷、使用者需要熱更新但是對業務無感覺、使用者需要無縫的擴縮容、使用者需要業務永續等等,基于使用者的這些需求各個雲産品都要去做對應的優化和改造。
比如在redis産品中我們一個最基本的要求就是所有元件都能夠做到不斷連結熱更新,在redis核心部分我們将主體邏輯和主要資料結構都拆成so,當更新redis核心時隻要動态加載一個so就能實作了,在proxy部分我們支援新老版本兩個程序同時跑,然後老版本proxy的所有連結都能通過一個本地接口傳遞給新版本proxy程序,之後老版本proxy程序退出,所有的處理邏輯都在新版本proxy上繼續執行,整個過程使用者是無感覺的。
雲栖社群:在團隊管理上,你奉行什麼原則?為了達到這樣原則,是如何踐行的?
子嘉:我的原則是通戰略,定方向,放大權,抓細。
通過通戰略和定方向讓大家知道要往哪裡走,自己的職業發展如何和我們的未來規劃相比對,自己未來在團隊中的位置是什麼;通過放大權讓他們充分發揮、鼓勵他們試錯、給他們最大的自由度的同時,也給他們最大的責任;通過抓細節來看他們的執行情況和問題所在,在發現問題時及時教育并糾正,最終讓人、産品、團隊都能得到成長。
雲栖社群:你先後接觸過搜尋、雲計算、redis、nosql等技術,在這些領域,你不僅做的很好,還有所創新。能否分享下自己是如何快速學習的?
子嘉:不挑活、勤思考、肯擔當,工作就是最好的學習途徑,記住千萬不要挑活,有的同學覺得這個活沒有技術含量,那個活沒有前途,但是就沒想過這些“沒技術含量”的活都做不好,怎麼能去幹那些有技術含量的活呢?
而且功不唐捐,你今天種下的種子在未來的一天終會發芽,其實技術都是相通的,搜尋、雲計算、redis共性的東西也非常多,人生本就那麼苦短,為何還設那麼多局限?
勤思考,幹活的時候多擡頭看看天,看看方向,多總結,很多人偏于執行而疏于規劃,這種習慣會造成中長期的悲劇,我自己也曾經犯過這個錯誤,交了很多學費;肯擔當,要努力讓自己成為團隊中可以依賴的人,不要讓自己成為可有可無的人,逃避責任隻會讓自己越來越被動。
雲栖社群:redis中國使用者組(crug)在5月20日正式成立,你對它的成立是怎麼看的?
子嘉:這個時間點很有意思,包含了很多。那麼多志同道合的人聚在一起是一個很大的緣分,對redis在中國的發展和交流有着重大和長遠的意義。
阿裡巴巴作為發起者之一,一直是開源的受益者,也一直在不停地回饋社群,我們也希望能通過crug促進redis的良性發展并将自己的一些積累貢獻給社群,然後和整個社群一起成長,和大家一起成長。