讀書筆記: 《億級流量網站架構核心技術》(開濤的那本)
- 任何事都沒有表面看起來那麼簡單。
- 所有的事都會比你預計的時間長。
- 可能出錯的事總和出錯。
- 如果你擔心某種情況發生,那麼它就更有可能發生。
- 系統架構是公司組織架構的反映。
- 應該按照業務閉環進行系統拆分/組織架構劃分,實現閉環/高內聚/低耦合,減少溝通成本。
- 如果溝通出現問題,那麼久應該考慮進行系統好組織架構的調整。
- 在合適時機進行系統拆分,不要一開始就把系統/服務拆分得非常細,雖然閉環,但是每個人維護的系統多,維護成本高。
- 將請求解析和業務處理執行緒池分離
- 執行緒池隔離可以方便對整個系統的把控,如根據業務重要性對執行緒池分解、隔離、監控、運維、降級
- 非同步化可以帶來更高的吞吐量,但響應時間也會變長。非同步化並不會提升響應時間,但會增加吞吐量和我們需要的靈活性。
- 代理層超時與重試
- Web容器超時
- 中介軟體客戶端超時與重試
- 資料庫客戶端超時
- NoSql客戶端超時
- 業務超時(如訂單超時未支付取消任務、活動超時自動關閉等)
- 前端Ajax超時
- 重試(等一會再試、嘗試其他分組服務、嘗試其他機房服務,重試演算法可考慮使用如指數退避演算法)
- 摘掉不存活節點(負載均衡/分散式快取場景下)
- 託底資料(返回歷史資料/靜態資料/快取資料/)
- 等待頁或者錯誤頁
- 堆快取(最快,沒有序列化/反序列化,但GC暫停時間會變長)(Guava Cache、Ehcache 3.x、MapDB)
- 堆外快取(比堆快取慢,需要序列化/反序列化,可以減少GC暫停時間)(Ehcache 3.x、MapDB)
- 磁碟快取(Ehcache 3.x、MapDB)
- 分散式快取(Redis、Memcached)
- Cache-Aside,即業務程式碼圍繞著Cache寫,是由業務程式碼直接維護快取。Cache-Aside適合使用AOP模式去實現。
- Cache-AS-SoR(system of record,或者可以叫資料來源),所有的操作都是對Cache進行,然後再委託給SoR進行真實的讀/寫。即業務程式碼中只看到Cache的操作,看不到關於SoR相關的程式碼。
- Read-Through,業務程式碼首先呼叫Cache,如果Cache不命中,由Cache回源到SoR,而不是業務程式碼(即由Cache讀SoR)。Guava Cache和Ehcache 3.x都支援該模式。
- Write-Through,被稱為穿透寫模式/直寫模式。業務程式碼首先呼叫Cache寫(新增/修改)資料,然後由Cache負責寫快取和寫SoR,而不是業務程式碼。Ehcache 3.x支援。
- Write-Behind,也叫Write-Back,我們稱之為回寫模式。不同於Write-Through是同步寫SoR和Cache,Write-Behind是非同步寫。非同步之後可以實現批量寫、合併寫、延時和限流。
- 服務端響應的Last-Modified會在下次請求時,將If-Modified-Since請求頭帶到伺服器端進行文件是否修改的驗證,如果沒有修改則返回304,瀏覽器可以直接使用快取內容
- Cache-Control:max-age和Expires用於決定瀏覽器端內容快取多久,即多久過期,過期後則刪除快取重新從伺服器端獲取最新的。另外,可以用於from cache場景。
- HTTP/1.1規範定義ETag為“被請求變數的實體值”,可簡單理解為文件內容摘要,ETag可用來判斷頁面內容是否已經被修改了。
- 負載較低時,使用一致性雜湊。
- 熱點請求降級一致性雜湊為輪詢,或者如果請求資料有規律,則可考慮帶權重的一致性雜湊。
- 將熱點資料推送到接入層Nginx,直接響應給使用者。
- 訂閱資料變更訊息
- 如果無法訂閱訊息或者訂閱訊息成本比較高,並且對短暫的資料一致性要求不嚴格(比如,在商品詳情頁看到的庫存,可以短暫的不一致,只要保證下單時一致即可),那麼可以設定合理的過期時間,過期後再查詢新的資料。
- 如果是秒殺之類的(熱點資料),可以訂閱活動開啟訊息,將相關資料提前推送到前端應用,並將負載均衡機制降級為輪詢。
- 建立實時熱點發現系統來對熱點進行統一推送和更新
- 主從機制,做好冗餘,即其中一部分不可用,將對等的部分補上去。
- 如果因為快取導致應用可用性已經下降,可以考慮部分使用者降級,然後慢慢減少降級量,後臺通過Worker預熱快取資料。
- 注意網路阻塞/不穩定時的級聯效應,連線池內部應該根據當前網路的狀態(比如超時次數太多),對於一定時間內的(如100ms)全部timeout,根本不進行await(maxWait),即有熔斷和快速失敗機制。
- 當前等待連線池的數目超過一定量時,接下來的等待是沒有意義的,還會造成滾雪球效應
- 等待超時應儘可能小點(除非很必要)。即使返回錯誤頁,也比等待並阻塞強。
- 根據任務型別是IO密集型還是CPU密集型、CPU核數,來設定合理的執行緒池大小、佇列大小、拒絕策略,並進行壓測和調優來決定適合場景的引數。
- 使用執行緒池時務必設定池大小、佇列大小並設定相應的拒絕策略。不如可能導致瞬間執行緒數過高、GC慢等問題,造成系統響應慢甚至OOM。
- 資料閉環
- 資料維度化
- 拆分系統
- Worker無狀態化+任務化
- 非同步化+併發化
- 多級快取化
- 動態化(資料動態化、模板渲染實時化、重啟應用秒級化、需求上線快速化)
- 彈性化(軟體打包成基礎映象,自動擴容)
- 降級開關
- 多機房多活
- Web應用:會進行一些業務邏輯處理,設定進行CPU的模板渲染,一般流程包括mysql/Redis/HTTP獲取資料、業務處理、產生JSON/XML/模板渲染內容,比如,京東的列表頁/商品詳情頁。
- 接入閘道器:實現如資料校驗前置、快取前置、資料過濾、API請求聚合、A/B測試、灰度釋出、降級、監控等功能,比如,京東的交易大Nginx節點、無線部門的無線閘道器、單品頁統一服務、實時價格、動態服務。
- Web防火牆:可以進行IP/URL/UserAgent/Referer黑名單、限流等功能。
- 快取伺服器:可以對響應內容進行快取,減少到底後端的請求,從而提升效能。
- 其他:如靜態資源伺服器、訊息推送服務、縮圖裁剪等。
- 負載均衡
- 單機閉環
- 分散式閉環
- 接入閘道器
- 在開放Nginx應用時,使用UTF-8編碼可以減少很多麻煩。
- GBK轉碼解碼時,應使用GB18030,否則一些特殊字元會出現亂碼。
- cjson庫對於像\uab1這種錯誤的Unicode轉碼會失敗,可以使用純Lua編寫的dkjson。
- 社群版Nginx不支援upstream的域名動態解析,可以考慮proxy_pass,然後配合resolver來實現。或者在Lua中進行HTTP呼叫。如果DNS遇到效能瓶頸,則可以考慮再本機部署如dnsmasq來快取,或者考慮使用balancer_by_lua功能實現動態upstream。
- 為響應新增處理伺服器IP的響應頭,方便定位問題
- 根據業務設定合理的超時時間。
- 執行CDN的業務,當發生錯誤時,不要給返回的500/503/302/301等非正常響應設定快取。
- 頁面模板部分變更類需要重新全部生成
- 動態化模板渲染支援
- 資料和模板的多版本化:生成版本、灰度版和預釋出版本
- 版本回滾問題,假設當前釋出的生成版本出問題了,如何快速回滾到上一個版本。
- 異常問題,假設渲染模板時,遇到了異常情況(比如Redis出問題了),該如何處理
- 灰度釋出問題,比如切20%量給灰度版本。
- 預釋出問題,目的是在正式環境測試資料和模板的正確
- 本機從“釋出資料儲存Redis”和主“釋出資料儲存Redis”都不能用了,那麼可以直接呼叫CMS系統暴露的HTTP服務,直接從元資料儲存Mysql獲取資料。
- 資料和模板獲取到了,但是渲染模板出錯了,比如遇到500、503。解決方案是使用上一個版本的資料進行渲染。
- 資料和模板都沒問題,但是因為一些疏忽,渲染出來的頁面錯亂了,或者有些區域出現了空白。對於這種問題沒有很好的解決方案。可以根據自己的場景定義異常掃描庫,掃到當前版本有異常就發警告給相關人員,並自動降級到上一個版本。
相關推薦
讀書筆記: 《億級流量網站架構核心技術》(開濤的那本)
這本書知識範圍廣,但都淺嘗輒止,可以用來開闊視野,由於之前看過李智慧的《大型網站技術架構》,有部分內容是重合的,所以翻起來比較快。這裡只記錄下之前沒太瞭解的點第1章:交易型系統設計的一些原則開場白太棒了,想全部記錄下來,本章還記錄了一些設計的原則。1、一個好的設計要做到,解決
《億級流量網站架構核心技術》讀書筆記 —— 交易型系統設計的一些原則
設計一個系統,不僅需要考慮實現業務功能,還要保證系統高併發、高可用、高可靠等,在系統容量規劃(流量、容量)、SLA指定(吞吐量、響應時間、可用性、降級方案等)、壓測方案(線上、線下等)、監控報警(機器負載、響應時間、可用率等)、應急預案(容災、降級、限流、隔離、
《億級流量網站架構核心技術》讀書筆記
雖然本人平時主要從事OA系統的開發,系統併發量不會特別大,主要是注重業務邏輯和快速交付,但是通過學習電商網站對高併發高可用的處理,可以促進自己對系統架構的思考,提升自己的業務水平,以後出現高併發高可用問題的時候,才不會手足無措,而且,系統架構原理是想通的,即使是
Nginx負載均衡與反向代理—《億級流量網站架構核心技術》
小時 維護 額外 nat gzip 網站架構 weight 2.7 熱點 當我們的應用單實例不能支撐用戶請求時,此時就需要擴容,從一臺服務器擴容到兩臺、幾十臺、幾百臺。然而,用戶訪問時是通過如http://www.XX.com的方式訪問,在請求時,瀏覽器首先會查詢DNS服務
觀《億級流量網站架構核心技術》一書有感
並發編程 轉移 tin 前置 發的 中斷 有效 不難 分類 本文的架子參考張開套的《億級流量網站架構核心技術》這本書分為四個部分:指導原則,高可用,高並發,實踐案例。這篇文章說一說前三個部分,大部分內容都是我自己的思考,書只作為參考。指導原則高可用事前副本技術隔離技術配額技
《億級流量網站架構核心技術》目錄一覽
在2011年年底的時候筆者就曾規劃寫一本Spring的書,但是因為是Spring入門型別的書,框架的內容更新太快,覺得還是寫部落格好一些,因此就把寫完的書稿放到了部落格(jinnianshilongnian.iteye.com,因為是龍年開的部落格,所以很多網友喊我龍年兄),並持續更新,到現在已經不
解祕億級網站的一本書——億級流量網站架構核心技術
網站是直接面對廣大客戶的,是公司的門戶,必須快速響應,必須持續可用,必須抗得住洪峰。任何一個網站的發展過程中都出現過問題,影響客戶體驗和商業利益,公司業務規模越大,網站出現問題的損失越大。此時此刻,有這樣一本書可以幫到您,那就是《億級流量網站架構核心技術 跟開濤
降級特技之使用Hystrix實現降級和熔斷—《億級流量網站架構核心技術》
使用Hystrix實現降級 通過配置中心可以人工進行降級,而我們也需要根據服務的超時時間進行自動降級,本部分將演示使用Hystrix實現超時自動降級。Hystrix介紹請參考“第3章 隔離術”中的Hystrix簡介部分。 public class GetStockS
《億級流量網站架構核心技術》總結
nginx後端節點健康檢查 主要有三種實現方式: 1. 本身自帶的ngx_http_proxy_module模組和ngx_http_upstream_module模組,屬於惰性檢測。 ngx_http_proxy_module:proxy_connect_
讀《億級流量網站架構核心技術》
張開濤 著 許多京東人編寫的序,寫的超級多,超級無聊。浪費紙張。 書中主要從 nginx + lua , OpenResty 這些工具介紹一些架構實現,如何配置 nginx lua 等。 Consul 是什麼?使用的架構圖是什麼樣的。這種。 Lua 是一種輕量級、
億級流量網站架構核心技術
spa ron size 擴展 環境 配置文件 需要 指定 strong 第一章 交易型系統設計的一些原則 1.1 高並發原則 1.1 高並發原則 1.1.1 無狀態
關於億級流量網站架構一書緩存機制的探討
obj dpa array ride 定義 from 有客 build 遠程 在京東的億級流量網站架構一書,175頁介紹緩存有這樣一段話 僅就這段代碼來看,在高並發情況下,實際上並不能阻止大量線程調用loadSync函數 當然這個書裏的代碼是作者的簡寫,這裏探討只是針對書
讀書筆記:java多執行緒程式設計核心技術
讀書筆記,簡單記錄....(都是從我的有道雲筆記直接複製的,沒有進行發表修改, 讀者見諒!) 第一章 掌握執行緒的啟動 暫停 停止 優先順序 安全性等 1.1程序 與 執行緒 程序 作業系統結構的基礎,是一次程式的執行,是系統進行資源分配和排程的獨立單位,簡單理解
億級流量系統架構之如何設計高容錯分散式計算系統【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 億級流量架構專欄: 億級流量系統架構之如何支撐百億級資料的儲存與計算 億級流量系統架構之如何設計高容錯分散式計算系統 億級流量系統架構之如何設計承載百億流量的高效能架構【敬請期待】 億級流
億級流量系統架構之如何設計承載百億流量的高效能架構【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 一、往期回顧 上篇文章《大型系統架構演進之如何設計高容錯分散式計算系統》,主要聊了一下將單塊系統重構為分散式系統,以此來避免單臺機器的負載過高。同時引申出來了彈性資源排程、分散式
億級流量系統架構之如何設計每秒十萬查詢的高併發架構【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 億級流量架構專欄: 億級流量系統架構之如何支撐百億級資料的儲存與計算 億級流量系統架構之如何設計高容錯分散式計算系統 億級流量系統
億級流量系統架構之如何設計全鏈路99.99%高可用架構【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 一、前情回顧 上篇文章(《億級流量系統架構之如何設計每秒十萬查詢的高併發架構》),聊了一下系統架構中的查詢平臺。 我們採用冷熱資料分離: 冷資料基於HBase+Elasticsearch+純記
億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 一、寫在前面 之前更新過一個“億級流量系統架構”系列,主要講述了一個大規模商家資料平臺的如下幾個方面: 如何承載百億級資料儲存 如何設計高容錯的分散式架構 如何設計承載百億流量的高效能架構
億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 目錄 一、前情提示 二、清晰劃分系統邊界 三、引入訊息中介軟體解耦 四、利用訊息中介軟體削峰填谷 五、手動流量開關配合資料庫運維 六、支援多系統同時訂閱資料 七、系統解耦後的感受 八、下集預告
億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?【石杉的架構筆記】
歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100) 週一至週五早8點半!精品技術文章準時送上! 一、前情提示 上一篇文章億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?分析了一下如何利用訊息中介軟體對系統進行解耦處理。 同時,我們也提到了使用訊息中介軟體還有利