于君澤，螞蟻金服支付核算技術部負責人、互聯網金融業務近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余年互聯網行業從業經驗，負責中間件、微服務、分布式架構、運維、安全等方面工作。

京東購書，掃描二維碼：

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。