技术领导力: 深度访谈《深入分布式缓存》
于君澤,螞蟻金服支付核算技術部負責人、互聯網金融業務近8年,電信業務8年經驗。興趣在高可用分布式架構應用,研發管理,內建質量等。維護公眾號:技術瑣話。《深入分布式緩存》一書聯合作者,總策劃。
曹洪偉,《深入分布式緩存》一書的作者之一。 70后老碼農,全棧工匠一枚,在多家世界500強企業從事軟硬件開發工作,后投身創業企業側重研發管理和體系架構,曾出版過幾本技術小冊子,發表過幾篇短文,擁有10幾個國內外專利的署名權。不忙的時候,偶爾在技術會議上分享一點心得,同時維護著公眾號wireless_com和同名的博客。目前,投身于智能硬件領域,任渡鴉科技的CTO,產品Raven-H 已經在線預售,歡迎訪問www.raventech.cn看一下他們的研發成果。
—————————————————————————————————————————————————————
技術領導力:據我了解,您可以說有著豐富的實戰經驗,在您的職業生涯里有沒有重要的里程碑和轉折點?
?曹洪偉:20多年的職業生涯,有很多轉折點,比如2000年互聯網泡沫破滅導致的創業失敗,移動互聯網產業鏈生態的從無到有,比如創業維艱而步履蹣跚蹣跚,軟硬件敏捷一體化的摩擦陣痛等等。
而最重要的里程碑和轉折點是在入行時轉折,從一個硬件工程師轉型測試再轉到軟件開發,具體地,我在《挨踢部落故事匯(2):機緣所致轉型之路》記載了這段經歷,這里不再贅述。 20年, 一個輪回,現在重新來到了這個領域,已經成為了智能硬件, AI 已經開始為硬件賦能了。
?
技術領導力:怎么會想到要寫《深入分布式緩存:從原理到實踐》這本書?大概歷時多久完成的?在這期間有沒有難忘的人或事?
于君澤:本書的產生要追溯到N年前,我一直對緩存技術抱有熱情,關注開源框架的發展,亦在工作中關注所遇所見、乃至所聽的案例。從應用程序研發方面看分布式緩存,并需要所有的程序員都具備開發一套組件的能力,但是需要具備正確使用它的能力。如易寶CTO陳斌老師所言,“解決雪崩問題的最好辦法是不發生雪崩”。不論是在硅谷互聯網公司?還是在國內的互聯網平臺上,曾多次遇到過海量規模的交易瞬間吞噬平臺的悲慘故事。我亦了解一些緩存因為代碼缺陷或者使用不當被擊穿的案例,不同數量級的請求產生的結果天壤之別,不可不慎。
2年前偶遇機械工業出版社的楊福川老師,攀談之下就萌發了創作本書的念頭。但由于工作繁忙且想呈現心中所想之提綱,應邀請一些不同場景下的專家共同完成。組團過程多有波折,特別感動的是北京的孔慶龍兄。他非常有興趣參與合作,但時逢小孩即將出生,為此,孔兄開了一次家庭會議來討論此事。雖然孔兄后續未決定參與,但可見其待人之真、之誠,是值得交的朋友。2年間發生了不少事情,劉暻宇leo、何濤、曹洪偉總和程超都換了工作。KickOff前程超家的小朋友還未出生,現在都快2歲了。大家都很忙,大約1個月碰一下進度,有時候可能一點都沒有進展。期間,程超和leo都一度要退出,終堅持了下來。還有些朋友中間退出了,同時有陳波、王曉波等朋友加入了進來。到這時,啥時候出版不那么心焦了,水到渠成。就是問初心,我們有沒有盡自己的努力來呈現一份關于工具書的紀念!
?曹洪偉:當時懷著“挖人”的險惡用心,進入了中生代技術社區,認識了右軍等諸多有趣的技術人。后因為自己在公眾號的一篇隨筆《老曹眼中的緩存》,右軍找到了我,于是開始參與《深入分布式緩存》一書的寫作。我加入的時候,本書的架構已經幾本成型,于是,我主要負責開篇和面向云服務的分布式緩存,同時review 伙伴們的部分章節。
虛擬團隊合作本身就是一種挑戰,更何況作者們的本職工作都很繁重,期間又經歷了部分伙伴生小孩,換工作等等,使得整本書的寫作進度差點失控。大家最后堅持了下來, 堅守著對伙伴的承諾,這本身就是一件難忘的事。
?
技術領導力:在大型網站應用當中,分布式系統設計有哪些策略?哪些實踐?能否就其中一二詳細說說呢?
曹洪偉:個人最早接觸的分布式系統是基于Corba 的orbix。 分布式系統是用戶需求導致技術演變的必然結果。大型網站應用中,分布式系統的設計策略取決于業務場景的具體需求,脫離業務談架構設計大多被認為是“耍流氓”。
例如CAP理論的實踐,AP和CP 的選擇與具體的業務場景強相關。關于CAP較詳細的一種解讀可以參見 右軍在公眾號“技術瑣話”中的一篇文字《CAP的相對論》。
具體設計策略包括分布式服務的粒度劃分,通信方式,心跳檢測與服務監控,容錯機制,服務降級與限流,負載均衡與并發性等等。更多關于分布式系統設計的策略描述可以參見《深入分布式緩存》一書的第二章。
于君澤:網上有很多談一個網站演進的文章,比如如何上緩存,數據庫讀寫分離,數據拆分等。我之前總結了一篇文章,互聯網架構的三板斧(https://yq.aliyun.com/articles/54449) 。那三板斧呢?活下來、簡單可擴展、去并發。這三板斧解決的是穩定性,可擴展性以及對于高并發的處理。當然,還有運維,監控,治理等。這篇文章更側重于幾個涉及原則。
技術領導力:實現一個緩存框架,需要考慮哪些要素?有哪些分類?能否結合實際經驗分享在這方面的心得呢?
曹洪偉:緩存本身有不同的分類。緩存框架一般歸為平臺級緩存框架和應用級環境框架。應用級緩存框架本身又有不同的分類,所以單純說緩存框架的實現是一個模糊的概念。
就分布式緩存框架而言,主要考慮的要素數據存儲,讀寫性能,冷啟動,失效策略,更新策略, 高可用與高并發等等。以一個廣告系統的緩存框架為例,采用了AS作為存儲數據庫,主要是實現了高實時性的約束。具體的實現方式可以參考《深入分布式緩存》一書的第11章 “Aerospike原理及廣告業務應用”
于君澤:《深入分布式緩存》一書用了一個章節來說緩存框架這件事,是第三章:動手寫緩存。但這些都是基本服務,其他特性需要考慮場景,不同場景采取不同的方案。
技術領導力:Ehcache、Memcached、Redis等緩存框架,主要的特點是什么?分別適用于哪些業務場景?
?曹洪偉:EHcache 是java 平臺上比較優秀的緩存框架,是從hibernate的緩存開始被廣泛使用起來的。數據可以伸縮到數G字節,節點可以到數百個,提供了對JSR107 JCACHE API最完整的實現。節點發現,冗余器和監聽器都可以插件化。同時,提供了許多對緩存事件發生后的處理機制,兼具靈活性和擴展性。
EHcache 在很多企業級應用中應用廣泛。
Memcached是一個高性能的分布式的內存對象緩存系統,通過在內存里維護一個統一的巨大的hash表,它能夠用來存儲各種格式的數據,包括圖像、視頻、文件以及數據庫檢索的結果等。簡單的說就是將數據調用到內存中,然后從內存中讀取,從而大大提高讀取速度。
Memcached 支持對象緩存,一度成為很多互聯網應用的首選,尤其是與mysql數據庫的高度集成。
Redis 是一款高級鍵值對緩存和存儲系統,在應用級緩存中的作用舉足輕重。 Redis支持主從同步,可執行單層樹狀復制。由于完全實現了發布/訂閱機制,使得從數據庫在任何地方同步樹的時侯,可訂閱一個頻道并接收主服務器完整的消息發布記錄。同步對讀取操作的可擴展性和數據冗余很有作用。Redis 3.0版本加入cluster功能,解決了Redis單點無法橫向擴展的問題。
Redis 是當前互聯網應用的主流緩存架構,例如同城旅游的redis實踐等等。
《深入分布式緩存》一書給出了大量的實踐案例。
?
技術領導力:在社交場景中,主要的業務特點是什么?緩存的設計和使用,會遇到哪些問題?以及如何解決這些問題?
?曹洪偉:一個典型社交類系統的典型特性歸結為三個關鍵詞:大數據量、高訪問量、非均勻性。
1)海量的數據。億級的用戶數量,每個用戶千級的post數量,平均千級的follower/followee數量。
2)高訪問量。每秒十萬量級的平均頁面訪問,每秒萬量級的post發布。
3)用戶分布的非均勻。部分用戶的post數量/follower數量、相關頁面訪問量會超出其它用戶一到數個量級。
4)時間分布的非均勻。高峰時段的訪問量、數據變更量高出非高峰時段一到數個量級
;高峰時段的長短也非均勻分布,存在日常的高峰時段和突發事件的高峰時段。
5)用戶+時間的非均勻分布。某個用戶可能突然某個時間成為熱點用戶,其follower可能陡增數個量級
隨著用戶規模的增長,會遇到各種各樣的問題,例如用戶關系表的膨脹,熱點用戶的信息廣播,所有用戶的信息摘要等等。都可以通過數據庫sharding,引入分布式緩存的方式解決。詳情請參考《深入分布式緩存》一書的第12章和第13章。
技術領導力:典型的電商類應用,面臨哪些挑戰?數據靜態化、多級緩存等方案是如何運用的?
于君澤:電商類應用具有如下特點:
1)穩定性決定服務能力:在前幾個月,某電商網站搞【買200減100的】活動,才進行了2小時就卡得不行。購物車的商品無法下單結算,查看商品詳情也非常慢,屬于一路塞車的節奏。該網站研發團隊通過限流恢復了部分能力,但是對于蜂擁而至的用戶而言,大部分用戶的體驗很差,因為他們買不到商品。
2)高并發性場景:大家都知道,擴展分為Scale Out和Scale Up 2種模式。
Scale Out:橫向擴展,增加處理節點提高整體處理能力,俗稱加機器。
Scale Up:縱向擴展,通過提升單個節點的處理能力達到提升整體處理能力的目的。
在互聯網架構中,采用廉價的服務器做Scale Out已經是非常通用的手段了,但是是不是所有場景扛不住都可以加機器?比如秒殺場景,除了高流量以外,壓力在于秒殺商品的高并發,那么熱點商品拆分、上緩存、隊列等技術自然就很重要了
3)業務發展性能也得發展:舉一個例子,有一個系統作支付鏈路的規則決策,起初可能就4萬行代碼;后來增加到8萬,現在又增加到10萬。代碼行增加了,該應用的職責增加了,也可能調用邏輯的運算復雜度。那么如何保持對外API的TPS不降低,RT不降低?每次release不僅要完成功能用例的構建,亦要完成性能的測試。
4)產品快速試錯:多年前,就有人想把軟件從業者變成像制造工人一樣的,不斷流水線工作。但是這幾乎沒什么可能,因為要解決的問題域太復雜。雖然業界有很多規范、標準、套裝軟件,但是仍然未解決問題之萬一。我們來看一下是如何復雜的。
以我們的一個team為例,7個人1年做了400多個需求。大家都知道滿足需求,實現業務價值是軟件的天職,至于為了更好適應未來發展的平臺化能力也好,新特性也好只能在業務發展的過程中做掉。在這么多需求的過程中,除了技術以外,對于業務包括規則要有深度把握,包括上下游的一些問題。如有評估不到位,問題就大了。分析到設計階段的缺失,到代碼、測試、發布這些階段可能一如既往的缺失了。早些年,某些系統已經復雜到只有1-2個人能搞懂部分了,幸好這些系統今天都完成了拆分和治理。
數據靜態化、多級緩存的部分幾句話說不清楚,建議閱讀我們的書《典型電商應用與緩存》章節。前幾天看到有朋友再說,熱點的數據是不是一定要用多級緩存呢? 最簡單粗暴的是可以把熱點key的數據拆分幾份放到不同server上,規避過熱數據把服務器擊穿。但是如果熱點key沒有事前預期呢? 則需要一套發現熱點key的機制了;另外多級緩存提升了性能,也保護了遠程緩存服務器。所以,沒有絕對正確的方法,只有相對合適的方案。
?
新書推薦:《深入分布式緩存》
作者介紹:
于君澤:螞蟻金服高級技術專家、花名右軍,IT從業超過十五年。對高并發、分布式架構、內建質量、研發管理有一些心得。維護公眾號“技術瑣話”。
程超:“愛農驛站”首席支付技術專家。InfoQ、中生代技術社區簽約作者,CSDN博主專家,Springfor all社區貢獻者,擅長微服務和分布式架構。
邱碩:螞蟻金服技術專家,花名牧丘,在阿里和支付寶從事中間件、應用系統的性能/穩定性技術風險相關工作。Cobar主要作者。
曹洪偉:70后老碼農,全棧工匠一枚,服務過多家世界500強,后連續創業,現任渡鴉科技CTO,致力于人工智能硬件,維護有“wireless_com”公眾號和博客
?劉璟宇:拍拍貸資深架構師,十余年互聯網行業從業經驗,主要研究云計算、服務化基礎框架以及各種基礎組件。
?張開濤:京東架構師,暢銷書《億級流量網站架構核心技術》作者,維護有“開濤的博客”公眾號。
?何濤:網聯高級架構師,對高流量下的架構設計有豐富的實踐經驗,熱衷于高可用、高并發和高性能的架構研究。
?宋慧慶:勤誠互動研發總監兼高級架構師,十年互聯網廣告行業經驗,主要研究高可用架構技術,為流量變現提供更好的服務。
?陳波:新浪微博技術專家,負責平臺基礎架構及優化,經歷了微博從起步到成為數億用戶的大型互聯網系統的演進過程。
?王曉波:同程旅游首席架構師,10余年互聯網行業從業經驗,負責中間件、微服務、分布式架構、運維、安全等方面工作。
京東購書,掃描二維碼:
總結
以上是生活随笔為你收集整理的技术领导力: 深度访谈《深入分布式缓存》的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 你和那位明星同月同日出生(呵呵。。你就别
- 下一篇: ipv4协议的详解