於君澤，螞蟻金服支付核算技術部負責人、網際網路金融業務近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餘年網際網路行業從業經驗，負責中介軟體、微服務、分散式架構、運維、安全等方面工作。

京東購書，掃描二維碼：