同程藝龍王曉波:緩存應(yīng)該這樣治理,高并發(fā)場景才能游刃有余!
原創(chuàng)【51CTO.com原創(chuàng)稿件】2018年5月18-19日,由51CTO主辦的全球軟件與運維技術(shù)峰會在北京召開。此次峰會圍繞人工智能、大數(shù)據(jù)、物聯(lián)網(wǎng)、區(qū)塊鏈等12大核心熱點,匯聚海內(nèi)外60位一線專家,是一場高端的技術(shù)盛宴,也是***IT技術(shù)人才學(xué)習(xí)和人脈拓展不容錯過的平臺。
在19日下午“高并發(fā)與實時處理”分會場,同程藝龍機票事業(yè)群CTO王曉波帶來了《高并發(fā)場景的緩存治理》的主題演講,針對如何讓緩存更適合高并發(fā)使用、如何正確使用緩存、如何通過治理化解緩存問題等熱點展開了闡述。會后,51CTO記者根據(jù)王曉波在WOT2018全球軟件與運維技術(shù)峰會的演講內(nèi)容進行了整理。
王曉波演講中談到,在高并發(fā)場景下,很多人都把cache(高速緩沖存儲器)當(dāng)做可以“續(xù)命”的靈丹妙藥,哪里高并發(fā)壓力大,哪里就上傳cache來解決并發(fā)問題。但有時候,即使使用了cache,卻發(fā)現(xiàn)系統(tǒng)依然卡頓宕機,是因為cache技術(shù)不好嗎?非也,其實這是緩存的治理工作沒有做好。
看看同程“趟過的坑”
王曉波比較系統(tǒng)地介紹了同程“趟過的坑”。
為了緩解高并發(fā)的壓力,同程最初選擇memcache(分布式的高速緩存系統(tǒng))技術(shù),后來又轉(zhuǎn)到Redis架構(gòu)(數(shù)據(jù)結(jié)構(gòu)服務(wù)器,可用作數(shù)據(jù)庫高速緩存),部署了接近200臺服務(wù)器。但情況并沒有好轉(zhuǎn),系統(tǒng)經(jīng)常性的宕機,應(yīng)用中調(diào)用的腳本亂七八糟,多實例部署資源不均衡,太脆弱數(shù)據(jù)消失了。
為了實現(xiàn)對這些服務(wù)器的管理,同程開啟了主從+keepalived(IT第3層、第四層、第五層交換機制的軟件)模式,并選擇從單機Redis逐漸升級到集群Redis。很快他們就發(fā)現(xiàn),當(dāng)集群大量部署的時候,運維端沒有辦法做運維,雖然可以通過腳本來統(tǒng)一運行,但是集群不可控,而且很多運維技術(shù)手段還容易導(dǎo)致高并發(fā)系統(tǒng)停機,直接對整體業(yè)務(wù)端產(chǎn)生影響。“當(dāng)時系統(tǒng)隨時可能會掛,運維團隊快崩潰了。”王曉波回憶道。
所有遭遇的問題癥結(jié)在哪里?王曉波總結(jié)到,***的問題在于技術(shù)人員對cache的使用的規(guī)范,人們常常會忘記它本身的缺點,只想到它的好處“快”。他舉了一個例子,在一次系統(tǒng)故障總結(jié)報道里,一名技術(shù)人員寫到,沒想到初始狀態(tài)下只有30000行的代碼的Redis,它竟然帶來如此神奇的功能。這樣的想法以至于讓程序員感覺手里拿了一個錘子,看見釘子就想錘。換而言之,讓他們看見任何的需求都想用緩存去解決。在這樣的誤導(dǎo)下,人們開始頻繁使用基于緩存的日志搜集器、基于緩存的倒計時、基于緩存的計數(shù)器、基于緩存的訂單系統(tǒng)。這些功能出現(xiàn)之后,人們只沉醉于它的快,卻忽視了如何去保障它的正常運行。
緩存真正的故障是什么?王曉波歸納成四點:一是過度依賴,這一點最突出,有時候明明不需要緩存,可技術(shù)人員卻非得去用緩存。二是數(shù)據(jù)落盤,三是超大容量,四是緩存雪崩。為什么會出現(xiàn)這些故障呢,王曉波認為,使用的者的亂用、濫用、懶用是***的問題。此外,運維數(shù)千臺毫無使用規(guī)則的緩存服務(wù)器,運維人員不懂開發(fā),開發(fā)人員不懂運維,導(dǎo)致了緩存在無設(shè)計無控制中被使用,太多的服務(wù)器資源被浪費等都是常見的現(xiàn)象。
到底人們需要一個什么樣的緩存?需要一個什么樣的緩存治理?王曉波認為,其實從真正的開發(fā)哲學(xué)上來說,其實人們想要的是一個“百變的魔術(shù)箱”,能夠神奇地滿足各種高并發(fā)需求。簡單來說,也就是說緩存是大是小、是好是壞,都不需要開發(fā)者關(guān)心。因為開發(fā)人員對緩存技術(shù)了解有限,最怕其胡亂使用。值得警惕的是,很多開發(fā)人員都忽視了現(xiàn)在緩存中的許多數(shù)據(jù)并不是永遠的熱數(shù)據(jù),在高并發(fā)到來前也沒有做充足的估算,導(dǎo)致在應(yīng)用時再發(fā)現(xiàn)瓶頸就晚了。
同程“鳳凰涅槃”
為了真正發(fā)揮出緩存的作用,應(yīng)對高并發(fā),同程技術(shù)團隊最終開發(fā)出phoenix方案。最初設(shè)計時,他們希望這個架構(gòu)中在應(yīng)用端會有一個簡單的SDK能夠讓開發(fā)人員去使用。只要開發(fā)人員聲明所做的項目和相關(guān)數(shù)據(jù)場景,就會得到一個key,有了這個key,SDK就會給開發(fā)人員分配一個新的緩存?zhèn)}庫,可以在上面運行Redis,讓整個調(diào)度平臺來調(diào)用它,速度非常快。除此之外,phoenix還能從客戶端調(diào)用開始全面監(jiān)控,當(dāng)然更重要的是能防止緩存的崩塌,實現(xiàn)動態(tài)擴容縮容。
后來,phoenix方案又加入了代理層。因為客戶端多語言開發(fā)時間成本太大,而且客戶端在應(yīng)用中的升級是個大問題,王曉波透露,幾乎所有的嵌入式應(yīng)用的中間件升級都是一個***的麻煩,一旦升級,系統(tǒng)要重新測試,很容易再度掛掉。所以通過本地緩存控制更好,部分使用頻率不高的可以使用磁盤做緩存。
***,phoenix方案中又加入了容器。當(dāng)實現(xiàn)容器化部署后,通過多個小集群+單節(jié)點、以場景劃分集群、實時平衡調(diào)度數(shù)據(jù),同程的整體監(jiān)控、數(shù)據(jù)遷移、伸縮調(diào)度都變得更靈活更容易操作。以數(shù)據(jù)遷移為例,同程做了整套的遷移系統(tǒng),從流量擴容到數(shù)據(jù)的擴容,從縱向跟橫向的擴容,全部實現(xiàn)了一個比較好的全自動處理。
以上內(nèi)容是51CTO記者根據(jù)同程藝龍機票事業(yè)群CTO王曉波在WOT2018全球軟件與運維技術(shù)峰會的采訪內(nèi)容整理,更多關(guān)于WOT的內(nèi)容請關(guān)注51cto.com。
【51CTO原創(chuàng)稿件,合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】




























