于君澤，螞蟻金服支付核算技術(shù)部負責人、互聯(lián)網(wǎng)金融業(yè)務(wù)近8年，電信業(yè)務(wù)8年經(jīng)驗。興趣在高可用分布式架構(gòu)應(yīng)用，研發(fā)管理，內(nèi)建質(zhì)量等。維護公眾號：技術(shù)瑣話?！渡钊敕植际骄彺妗芬粫?lián)合作者，總策劃。

曹洪偉，《深入分布式緩存》一書的作者之一。 70后老碼農(nóng)，全棧工匠一枚，在多家世界500強企業(yè)從事軟硬件開發(fā)工作，后投身創(chuàng)業(yè)企業(yè)側(cè)重研發(fā)管理和體系架構(gòu)，曾出版過幾本技術(shù)小冊子，發(fā)表過幾篇短文，擁有10幾個國內(nèi)外專利的署名權(quán)。不忙的時候，偶爾在技術(shù)會議上分享一點心得，同時維護著公眾號wireless_com和同名的博客。目前，投身于智能硬件領(lǐng)域，任渡鴉科技的CTO，產(chǎn)品Raven-H 已經(jīng)在線預(yù)售，歡迎訪問www.raventech.cn看一下他們的研發(fā)成果。

—————————————————————————————————————————————————————

技術(shù)領(lǐng)導力：據(jù)我了解，您可以說有著豐富的實戰(zhàn)經(jīng)驗，在您的職業(yè)生涯里有沒有重要的里程碑和轉(zhuǎn)折點？

?曹洪偉：20多年的職業(yè)生涯，有很多轉(zhuǎn)折點，比如2000年互聯(lián)網(wǎng)泡沫破滅導致的創(chuàng)業(yè)失敗，移動互聯(lián)網(wǎng)產(chǎn)業(yè)鏈生態(tài)的從無到有，比如創(chuàng)業(yè)維艱而步履蹣跚蹣跚，軟硬件敏捷一體化的摩擦陣痛等等。

而最重要的里程碑和轉(zhuǎn)折點是在入行時轉(zhuǎn)折，從一個硬件工程師轉(zhuǎn)型測試再轉(zhuǎn)到軟件開發(fā)，具體地，我在《挨踢部落故事匯(2):機緣所致轉(zhuǎn)型之路》記載了這段經(jīng)歷，這里不再贅述。 20年， 一個輪回，現(xiàn)在重新來到了這個領(lǐng)域，已經(jīng)成為了智能硬件， AI 已經(jīng)開始為硬件賦能了。

?

技術(shù)領(lǐng)導力：怎么會想到要寫《深入分布式緩存：從原理到實踐》這本書？大概歷時多久完成的？在這期間有沒有難忘的人或事？

于君澤：本書的產(chǎn)生要追溯到N年前，我一直對緩存技術(shù)抱有熱情，關(guān)注開源框架的發(fā)展，亦在工作中關(guān)注所遇所見、乃至所聽的案例。從應(yīng)用程序研發(fā)方面看分布式緩存，并需要所有的程序員都具備開發(fā)一套組件的能力，但是需要具備正確使用它的能力。如易寶CTO陳斌老師所言，“解決雪崩問題的最好辦法是不發(fā)生雪崩”。不論是在硅谷互聯(lián)網(wǎng)公司?還是在國內(nèi)的互聯(lián)網(wǎng)平臺上，曾多次遇到過海量規(guī)模的交易瞬間吞噬平臺的悲慘故事。我亦了解一些緩存因為代碼缺陷或者使用不當被擊穿的案例，不同數(shù)量級的請求產(chǎn)生的結(jié)果天壤之別，不可不慎。

2年前偶遇機械工業(yè)出版社的楊福川老師，攀談之下就萌發(fā)了創(chuàng)作本書的念頭。但由于工作繁忙且想呈現(xiàn)心中所想之提綱，應(yīng)邀請一些不同場景下的專家共同完成。組團過程多有波折，特別感動的是北京的孔慶龍兄。他非常有興趣參與合作，但時逢小孩即將出生，為此，孔兄開了一次家庭會議來討論此事。雖然孔兄后續(xù)未決定參與，但可見其待人之真、之誠，是值得交的朋友。2年間發(fā)生了不少事情，劉暻宇leo、何濤、曹洪偉總和程超都換了工作。KickOff前程超家的小朋友還未出生，現(xiàn)在都快2歲了。大家都很忙，大約1個月碰一下進度，有時候可能一點都沒有進展。期間，程超和leo都一度要退出，終堅持了下來。還有些朋友中間退出了，同時有陳波、王曉波等朋友加入了進來。到這時，啥時候出版不那么心焦了，水到渠成。就是問初心，我們有沒有盡自己的努力來呈現(xiàn)一份關(guān)于工具書的紀念！

?曹洪偉：當時懷著“挖人”的險惡用心，進入了中生代技術(shù)社區(qū)，認識了右軍等諸多有趣的技術(shù)人。后因為自己在公眾號的一篇隨筆《老曹眼中的緩存》，右軍找到了我，于是開始參與《深入分布式緩存》一書的寫作。我加入的時候，本書的架構(gòu)已經(jīng)幾本成型，于是，我主要負責開篇和面向云服務(wù)的分布式緩存，同時review 伙伴們的部分章節(jié)。

虛擬團隊合作本身就是一種挑戰(zhàn)，更何況作者們的本職工作都很繁重，期間又經(jīng)歷了部分伙伴生小孩，換工作等等，使得整本書的寫作進度差點失控。大家最后堅持了下來， 堅守著對伙伴的承諾，這本身就是一件難忘的事。

?

技術(shù)領(lǐng)導力：在大型網(wǎng)站應(yīng)用當中，分布式系統(tǒng)設(shè)計有哪些策略？哪些實踐？能否就其中一二詳細說說呢？

曹洪偉：個人最早接觸的分布式系統(tǒng)是基于Corba 的orbix。 分布式系統(tǒng)是用戶需求導致技術(shù)演變的必然結(jié)果。大型網(wǎng)站應(yīng)用中，分布式系統(tǒng)的設(shè)計策略取決于業(yè)務(wù)場景的具體需求，脫離業(yè)務(wù)談架構(gòu)設(shè)計大多被認為是“耍流氓”。

例如CAP理論的實踐，AP和CP 的選擇與具體的業(yè)務(wù)場景強相關(guān)。關(guān)于CAP較詳細的一種解讀可以參見 右軍在公眾號“技術(shù)瑣話”中的一篇文字《CAP的相對論》。

具體設(shè)計策略包括分布式服務(wù)的粒度劃分，通信方式，心跳檢測與服務(wù)監(jiān)控，容錯機制，服務(wù)降級與限流，負載均衡與并發(fā)性等等。更多關(guān)于分布式系統(tǒng)設(shè)計的策略描述可以參見《深入分布式緩存》一書的第二章。

于君澤：網(wǎng)上有很多談一個網(wǎng)站演進的文章，比如如何上緩存，數(shù)據(jù)庫讀寫分離，數(shù)據(jù)拆分等。我之前總結(jié)了一篇文章，互聯(lián)網(wǎng)架構(gòu)的三板斧（https://yq.aliyun.com/articles/54449） 。那三板斧呢？活下來、簡單可擴展、去并發(fā)。這三板斧解決的是穩(wěn)定性，可擴展性以及對于高并發(fā)的處理。當然，還有運維，監(jiān)控，治理等。這篇文章更側(cè)重于幾個涉及原則。

技術(shù)領(lǐng)導力：實現(xiàn)一個緩存框架，需要考慮哪些要素？有哪些分類？能否結(jié)合實際經(jīng)驗分享在這方面的心得呢？

曹洪偉：緩存本身有不同的分類。緩存框架一般歸為平臺級緩存框架和應(yīng)用級環(huán)境框架。應(yīng)用級緩存框架本身又有不同的分類，所以單純說緩存框架的實現(xiàn)是一個模糊的概念。

就分布式緩存框架而言，主要考慮的要素數(shù)據(jù)存儲，讀寫性能，冷啟動，失效策略，更新策略， 高可用與高并發(fā)等等。以一個廣告系統(tǒng)的緩存框架為例，采用了AS作為存儲數(shù)據(jù)庫，主要是實現(xiàn)了高實時性的約束。具體的實現(xiàn)方式可以參考《深入分布式緩存》一書的第11章　“Aerospike原理及廣告業(yè)務(wù)應(yīng)用”

于君澤：《深入分布式緩存》一書用了一個章節(jié)來說緩存框架這件事，是第三章：動手寫緩存。但這些都是基本服務(wù)，其他特性需要考慮場景，不同場景采取不同的方案。

技術(shù)領(lǐng)導力：Ehcache、Memcached、Redis等緩存框架，主要的特點是什么？分別適用于哪些業(yè)務(wù)場景？

?曹洪偉：EHcache 是java 平臺上比較優(yōu)秀的緩存框架，是從hibernate的緩存開始被廣泛使用起來的。數(shù)據(jù)可以伸縮到數(shù)G字節(jié)，節(jié)點可以到數(shù)百個，提供了對JSR107 JCACHE API最完整的實現(xiàn)。節(jié)點發(fā)現(xiàn)，冗余器和監(jiān)聽器都可以插件化。同時，提供了許多對緩存事件發(fā)生后的處理機制，兼具靈活性和擴展性。

EHcache 在很多企業(yè)級應(yīng)用中應(yīng)用廣泛。

Memcached是一個高性能的分布式的內(nèi)存對象緩存系統(tǒng)，通過在內(nèi)存里維護一個統(tǒng)一的巨大的hash表，它能夠用來存儲各種格式的數(shù)據(jù)，包括圖像、視頻、文件以及數(shù)據(jù)庫檢索的結(jié)果等。簡單的說就是將數(shù)據(jù)調(diào)用到內(nèi)存中，然后從內(nèi)存中讀取，從而大大提高讀取速度。

Memcached 支持對象緩存，一度成為很多互聯(lián)網(wǎng)應(yīng)用的首選，尤其是與mysql數(shù)據(jù)庫的高度集成。

Redis 是一款高級鍵值對緩存和存儲系統(tǒng)，在應(yīng)用級緩存中的作用舉足輕重。 Redis支持主從同步，可執(zhí)行單層樹狀復(fù)制。由于完全實現(xiàn)了發(fā)布/訂閱機制，使得從數(shù)據(jù)庫在任何地方同步樹的時侯，可訂閱一個頻道并接收主服務(wù)器完整的消息發(fā)布記錄。同步對讀取操作的可擴展性和數(shù)據(jù)冗余很有作用。Redis 3.0版本加入cluster功能，解決了Redis單點無法橫向擴展的問題。

Redis 是當前互聯(lián)網(wǎng)應(yīng)用的主流緩存架構(gòu)，例如同城旅游的redis實踐等等。

《深入分布式緩存》一書給出了大量的實踐案例。

?

技術(shù)領(lǐng)導力：在社交場景中，主要的業(yè)務(wù)特點是什么？緩存的設(shè)計和使用，會遇到哪些問題？以及如何解決這些問題？

?曹洪偉：一個典型社交類系統(tǒng)的典型特性歸結(jié)為三個關(guān)鍵詞：大數(shù)據(jù)量、高訪問量、非均勻性。

1）海量的數(shù)據(jù)。億級的用戶數(shù)量，每個用戶千級的post數(shù)量，平均千級的follower/followee數(shù)量。

2）高訪問量。每秒十萬量級的平均頁面訪問，每秒萬量級的post發(fā)布。

3）用戶分布的非均勻。部分用戶的post數(shù)量/follower數(shù)量、相關(guān)頁面訪問量會超出其它用戶一到數(shù)個量級。

4）時間分布的非均勻。高峰時段的訪問量、數(shù)據(jù)變更量高出非高峰時段一到數(shù)個量級

；高峰時段的長短也非均勻分布，存在日常的高峰時段和突發(fā)事件的高峰時段。

5）用戶+時間的非均勻分布。某個用戶可能突然某個時間成為熱點用戶，其follower可能陡增數(shù)個量級

隨著用戶規(guī)模的增長，會遇到各種各樣的問題，例如用戶關(guān)系表的膨脹，熱點用戶的信息廣播，所有用戶的信息摘要等等。都可以通過數(shù)據(jù)庫sharding，引入分布式緩存的方式解決。詳情請參考《深入分布式緩存》一書的第12章和第13章。

技術(shù)領(lǐng)導力：典型的電商類應(yīng)用，面臨哪些挑戰(zhàn)？數(shù)據(jù)靜態(tài)化、多級緩存等方案是如何運用的？

于君澤：電商類應(yīng)用具有如下特點：

1）穩(wěn)定性決定服務(wù)能力：在前幾個月，某電商網(wǎng)站搞【買200減100的】活動，才進行了2小時就卡得不行。購物車的商品無法下單結(jié)算，查看商品詳情也非常慢，屬于一路塞車的節(jié)奏。該網(wǎng)站研發(fā)團隊通過限流恢復(fù)了部分能力，但是對于蜂擁而至的用戶而言，大部分用戶的體驗很差，因為他們買不到商品。

2）高并發(fā)性場景：大家都知道，擴展分為Scale Out和Scale Up 2種模式。

Scale Out：橫向擴展，增加處理節(jié)點提高整體處理能力，俗稱加機器。

Scale Up：縱向擴展，通過提升單個節(jié)點的處理能力達到提升整體處理能力的目的。

在互聯(lián)網(wǎng)架構(gòu)中，采用廉價的服務(wù)器做Scale Out已經(jīng)是非常通用的手段了，但是是不是所有場景扛不住都可以加機器？比如秒殺場景，除了高流量以外，壓力在于秒殺商品的高并發(fā)，那么熱點商品拆分、上緩存、隊列等技術(shù)自然就很重要了

3）業(yè)務(wù)發(fā)展性能也得發(fā)展：舉一個例子，有一個系統(tǒng)作支付鏈路的規(guī)則決策，起初可能就4萬行代碼；后來增加到8萬，現(xiàn)在又增加到10萬。代碼行增加了，該應(yīng)用的職責增加了，也可能調(diào)用邏輯的運算復(fù)雜度。那么如何保持對外API的TPS不降低，RT不降低？每次release不僅要完成功能用例的構(gòu)建，亦要完成性能的測試。

4）產(chǎn)品快速試錯：多年前，就有人想把軟件從業(yè)者變成像制造工人一樣的，不斷流水線工作。但是這幾乎沒什么可能，因為要解決的問題域太復(fù)雜。雖然業(yè)界有很多規(guī)范、標準、套裝軟件，但是仍然未解決問題之萬一。我們來看一下是如何復(fù)雜的。

以我們的一個team為例，7個人1年做了400多個需求。大家都知道滿足需求，實現(xiàn)業(yè)務(wù)價值是軟件的天職，至于為了更好適應(yīng)未來發(fā)展的平臺化能力也好，新特性也好只能在業(yè)務(wù)發(fā)展的過程中做掉。在這么多需求的過程中，除了技術(shù)以外，對于業(yè)務(wù)包括規(guī)則要有深度把握，包括上下游的一些問題。如有評估不到位，問題就大了。分析到設(shè)計階段的缺失，到代碼、測試、發(fā)布這些階段可能一如既往的缺失了。早些年，某些系統(tǒng)已經(jīng)復(fù)雜到只有1-2個人能搞懂部分了，幸好這些系統(tǒng)今天都完成了拆分和治理。

數(shù)據(jù)靜態(tài)化、多級緩存的部分幾句話說不清楚，建議閱讀我們的書《典型電商應(yīng)用與緩存》章節(jié)。前幾天看到有朋友再說，熱點的數(shù)據(jù)是不是一定要用多級緩存呢？ 最簡單粗暴的是可以把熱點key的數(shù)據(jù)拆分幾份放到不同server上，規(guī)避過熱數(shù)據(jù)把服務(wù)器擊穿。但是如果熱點key沒有事前預(yù)期呢？ 則需要一套發(fā)現(xiàn)熱點key的機制了；另外多級緩存提升了性能，也保護了遠程緩存服務(wù)器。所以，沒有絕對正確的方法，只有相對合適的方案。

?

新書推薦：《深入分布式緩存》

作者介紹：

于君澤：螞蟻金服高級技術(shù)專家、花名右軍，IT從業(yè)超過十五年。對高并發(fā)、分布式架構(gòu)、內(nèi)建質(zhì)量、研發(fā)管理有一些心得。維護公眾號“技術(shù)瑣話”。

程超：“愛農(nóng)驛站”首席支付技術(shù)專家。InfoQ、中生代技術(shù)社區(qū)簽約作者，CSDN博主專家，Springfor all社區(qū)貢獻者，擅長微服務(wù)和分布式架構(gòu)。

邱碩：螞蟻金服技術(shù)專家，花名牧丘，在阿里和支付寶從事中間件、應(yīng)用系統(tǒng)的性能/穩(wěn)定性技術(shù)風險相關(guān)工作。Cobar主要作者。

曹洪偉：70后老碼農(nóng)，全棧工匠一枚，服務(wù)過多家世界500強，后連續(xù)創(chuàng)業(yè)，現(xiàn)任渡鴉科技CTO，致力于人工智能硬件，維護有“wireless_com”公眾號和博客

?劉璟宇：拍拍貸資深架構(gòu)師，十余年互聯(lián)網(wǎng)行業(yè)從業(yè)經(jīng)驗，主要研究云計算、服務(wù)化基礎(chǔ)框架以及各種基礎(chǔ)組件。

?張開濤：京東架構(gòu)師，暢銷書《億級流量網(wǎng)站架構(gòu)核心技術(shù)》作者，維護有“開濤的博客”公眾號。

?何濤：網(wǎng)聯(lián)高級架構(gòu)師，對高流量下的架構(gòu)設(shè)計有豐富的實踐經(jīng)驗，熱衷于高可用、高并發(fā)和高性能的架構(gòu)研究。

?宋慧慶：勤誠互動研發(fā)總監(jiān)兼高級架構(gòu)師，十年互聯(lián)網(wǎng)廣告行業(yè)經(jīng)驗，主要研究高可用架構(gòu)技術(shù)，為流量變現(xiàn)提供更好的服務(wù)。

?陳波：新浪微博技術(shù)專家，負責平臺基礎(chǔ)架構(gòu)及優(yōu)化，經(jīng)歷了微博從起步到成為數(shù)億用戶的大型互聯(lián)網(wǎng)系統(tǒng)的演進過程。

?王曉波：同程旅游首席架構(gòu)師，10余年互聯(lián)網(wǎng)行業(yè)從業(yè)經(jīng)驗，負責中間件、微服務(wù)、分布式架構(gòu)、運維、安全等方面工作。

京東購書，掃描二維碼：

總結(jié)

以上是生活随笔為你收集整理的技术领导力： 深度访谈《深入分布式缓存》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。