這本書知識範圍廣，但都淺嘗輒止，可以用來開闊視野，由於之前看過李智慧的《大型網站技術架構》，有部分內容是重合的，所以翻起來比較快。這裡只記錄下之前沒太瞭解的點第1章：交易型系統設計的一些原則開場白太棒了，想全部記錄下來，本章還記錄了一些設計的原則。1、一個好的設計要做到，解決現有需求和問題，把控實現和進度風險，預測和規劃未來，不要過度設計，從迭代中演進和完善。2、墨菲定律：

• 任何事都沒有表面看起來那麼簡單。
• 所有的事都會比你預計的時間長。
• 可能出錯的事總和出錯。
• 如果你擔心某種情況發生，那麼它就更有可能發生。

3、康威定律：

• 系統架構是公司組織架構的反映。
• 應該按照業務閉環進行系統拆分/組織架構劃分，實現閉環/高內聚/低耦合，減少溝通成本。
• 如果溝通出現問題，那麼久應該考慮進行系統好組織架構的調整。
• 在合適時機進行系統拆分，不要一開始就把系統/服務拆分得非常細，雖然閉環，但是每個人維護的系統多，維護成本高。

第2章：負載均衡與反向代理第3章：隔離術目的：將系統或資源分隔開，在系統發生故障時，限定傳播範圍和影響範圍，不會出現雪球效應。1、隔離方式：這塊之前瞭解相對較少，可以偶爾翻翻目錄擴充套件下隔離方式技術的視野。包含了執行緒隔離、程序隔離、叢集隔離、機房隔離、讀寫隔離、動靜隔離、爬蟲隔離、熱點隔離。2、Hystrix隔離3、基於Servlet3實現請求隔離

• 將請求解析和業務處理執行緒池分離
• 執行緒池隔離可以方便對整個系統的把控，如根據業務重要性對執行緒池分解、隔離、監控、運維、降級
• 非同步化可以帶來更高的吞吐量，但響應時間也會變長。非同步化並不會提升響應時間，但會增加吞吐量和我們需要的靈活性。

第4章：限流詳解

目的：通過對併發訪問/請求進行限速或者一個時間視窗內的請求進行限速來保護系統，一旦達到限制速率則可用拒絕服務、排隊或等待、降級。1、限流演算法：令牌桶演算法、漏桶演算法2、不同層次限流：應用級限流、分散式限流、接入層限流3、節流：在特定時間視窗內對重複的相同事件最多隻處理一次，或者想限制多個連續相同事件最小執行時間間隔，那麼可使用節流實現，其能防止多個相同事件連續重複執行。節流主要有幾種用法：throttleFirst、throttleLast、throttleWithTimeout。第5章：降級特技目的：降級的最終目的是保證核心服務可用，即使是有損的。1、降級預案：頁面降級、頁面片段降級、頁面非同步請求降級、服務功能降級、讀降級、寫降級、爬蟲降級、風控降級2、關鍵字：自動開關降級、人工開關降級、讀服務獎、寫服務降級、多級降級、統一配置中心（參考有贊降級熱熔斷系統Tesla）3、Hystrix原理實現這部分之前收集的部落格系列更加詳細。第6章：超時與重試機制

1、使用超時與重試機制的原因實際開發過程中，有許多是因為沒有設定超時或者設定得不對而造成的。如果應用不設定超時，則可能會導致請求響應慢，慢請求累積導致連鎖反應，甚至造成應用雪崩。讀服務天然適合重試，寫服務需要根據實際情況（如是否做冪等）。重試次數太多會導致多倍請求流量，即模擬了DDos攻擊（參考有讚的Token鑑權超時重試導致流量翻倍，擊垮五倍容災的機器，進而影響線上）。2、超時與重試機制的分類

• 代理層超時與重試
• Web容器超時
• 中介軟體客戶端超時與重試
• 資料庫客戶端超時
• NoSql客戶端超時
• 業務超時（如訂單超時未支付取消任務、活動超時自動關閉等）
• 前端Ajax超時

3、超時策略處理

• 重試（等一會再試、嘗試其他分組服務、嘗試其他機房服務，重試演算法可考慮使用如指數退避演算法）
• 摘掉不存活節點（負載均衡/分散式快取場景下）
• 託底資料（返回歷史資料/靜態資料/快取資料/）
• 等待頁或者錯誤頁

第7章：回滾機制1、回滾概念當程式或資料出錯時，將程式或資料恢復到最近的一個正確版本的行為。最常見的如事務回滾、程式碼庫回滾、部署版本回滾、資料版本回滾、靜態資源版本回滾等。通過回滾機制可以保證系統在某些場景下的高可用。2、事務回滾單庫事務回滾這裡就不多說了分散式事務：最常見的如兩階段提交、三階段提交協議，這種方式實現事務回滾難度較低，但是對效能影響較大，因為我們大多數場景中需要的是最終一致性，而不是強一致性。因此，可以考慮如事務表、訊息佇列、補償機制（執行/回滾）、TCC模式（預佔/確認/取消）、Sagas模式（拆分事務+補償機制）等實現最終一致性。3、部署版本回滾：部署版本化、小版本增量釋出、大版本灰度釋出、架構升級併發釋出第8章：壓測與預案在大促來臨前，一般會對現有系統進行梳理，發現系統瓶頸和問題，然後進行系統調優來提升系統的健壯性和處理能力。一般通過系統壓測來發現系統瓶頸和問題，然後進行系統優化和容災（如系統引數調優、單機房容災、多機房容災等）。即使系統優化和容災做的非常好，也存在一些不穩定因素，如網路、依賴服務的SLA不穩定等，這就需要我們制定應急預案，在出現這些因素後進行路由切換或降級處理。在大促前進行預案演戲，確定預案的有效性。1、系統壓測流程壓測前要有壓測方案【如壓測介面、併發量、壓測策略（突發、逐步加壓、併發量）、壓測指標（機器負載、QPS/TPS、響應時間）】，之後要產出壓測報告【壓測方案、機器負載、QPS/TPS、響應時間（平均、最小、最大）、成功率、相關引數（JVM引數、壓縮引數）等】，最後根據壓測報告分析的結果進行系統優化和容災。2、線下壓測通過如JMeter、Apache ab壓測系統的某個介面或者某個元件，然後進行調優，實現單個介面或元件的效能最優。3、線上壓測按讀寫分為讀壓測、寫壓測和混合壓測，按資料模擬度分為模擬壓測和引流壓測，按是否給使用者提供服務分為隔離叢集壓測和線上叢集壓測。單機壓測可以評估出單機極限處理能力，但單機壓測結果不能反映叢集整體處理能力。在壓測時，需要選擇離散壓測，即選擇的資料應該是分散的或者長尾的。為了保證壓測的真實性，應該進行全鏈路壓測。3、系統優化拿到壓測報告後，接下來會分析報告，然後進行一些有針對性的優化，如硬體升級、系統擴容、引數調優、程式碼優化（如程式碼同步概非同步）、配置調優、慢查詢優化、架構優化（如加快取、讀寫分離、歷史資料歸檔）等。4、應用擴容可根據去年流量、與運營業務方溝通促銷力度、最近一段時間的流量、預計GMV增長等來評估出是否需要進行擴容，需要擴容多少倍。擴容之後還要預留一些機器應對突發情況，在擴容上儘量支援快速擴容，從而在出現突發情況時可以幾分鐘內完成擴容。5、系統容災在擴容時要考慮系統容災，比如分組部署、跨機房部署。容災是通過部署多組（單機房/多機房）相同應用系統，當其中一組出現問題時，可以切換到另一個分組，保證系統可用。6、需要應急預案的原因在進行系統容災後，仍然會存在一些風險，如網路抖動、某臺機器負載過高、某個服務變慢、資料庫oad值過高等，為了防止因為這些問題而出現系統雪崩，需要針對這些情況制定應急預案，從而出現突發情況時，有相應的措施來解決掉這些掉這些問題。7、應急預發步驟首先進行系統分級，然後進行全鏈路分析、配置監控報警，最後制定應急預案，預案演練等。8、系統分級針對交易型系統可以按照交易核心系統和交易支撐系統進行劃分。實際系統分級要根據公司特色進行，目的是對不同級別的系統實施不同的質量保障，核心系統要投入更多資源保障系統高可用，外圍系統要投入較少資源允許系統暫時不可用。9、全鏈路分析，制定應急預案對核心場景進行全鏈路分析，從使用者入口到後端儲存，梳理出各個關鍵路徑，對相關路徑進行評估並制定預案。即當出現問題時，該路徑可以執行什麼操作來保證使用者可下單、可購物，並且也要防止問題的級聯效應和雪崩效應。梳理系統關鍵路徑，包括網路接入層、應用接入層、Web應用層、服務層、資料層等，並制定應急預案。P149展示了應急預案的格式。第9章：應用級快取1、快取回收策略基於空間、基於容量、基於時間（TTL、TTI）、基於Java物件引用（軟引用、弱引用）、基於會是演算法（FIFO、LRU（Leas Recently Used）、LFU（Lease Frequently Used））2、Java快取型別

• 堆快取（最快，沒有序列化/反序列化，但GC暫停時間會變長）（Guava Cache、Ehcache 3.x、MapDB）
• 堆外快取（比堆快取慢，需要序列化/反序列化，可以減少GC暫停時間）（Ehcache 3.x、MapDB）
• 磁碟快取（Ehcache 3.x、MapDB）
• 分散式快取（Redis、Memcached）

3、快取使用模式

• Cache-Aside，即業務程式碼圍繞著Cache寫，是由業務程式碼直接維護快取。Cache-Aside適合使用AOP模式去實現。
• Cache-AS-SoR（system of record，或者可以叫資料來源），所有的操作都是對Cache進行，然後再委託給SoR進行真實的讀/寫。即業務程式碼中只看到Cache的操作，看不到關於SoR相關的程式碼。

4、Cache-AS-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是非同步寫。非同步之後可以實現批量寫、合併寫、延時和限流。

第10章：HTTP快取1、HTTP快取

• 服務端響應的Last-Modified會在下次請求時，將If-Modified-Since請求頭帶到伺服器端進行文件是否修改的驗證，如果沒有修改則返回304，瀏覽器可以直接使用快取內容
• Cache-Control:max-age和Expires用於決定瀏覽器端內容快取多久，即多久過期，過期後則刪除快取重新從伺服器端獲取最新的。另外，可以用於from cache場景。
• HTTP/1.1規範定義ETag為“被請求變數的實體值”，可簡單理解為文件內容摘要，ETag可用來判斷頁面內容是否已經被修改了。

2、HttpClient客戶端快取、Nginx配置、Nginx代理層快取第11章：多級快取多級快取，是指在整個系統架構的不同系統層級進行資料快取，以提升訪問效率，這是應用最廣的方案之一。1、維度華快取與增量快取、大Value快取處理、熱點快取處理2、快取分散式及應用負責均衡演算法選擇

• 負載較低時，使用一致性雜湊。
• 熱點請求降級一致性雜湊為輪詢，或者如果請求資料有規律，則可考慮帶權重的一致性雜湊。
• 將熱點資料推送到接入層Nginx，直接響應給使用者。

3、熱點資料熱點資料會造成伺服器壓力過大，導致伺服器效能、吞吐量、頻寬達到極限，出現響應慢或者拒絕服務的情況，這肯定是不允許的。4、單機全量快取+主從（熱點資料解決方案1）一般不採用，針對快取量比較大的應用不適用。5、分散式快取+應用本地熱點（熱點資料解決方案2）①接入Nginx將請求轉發給應用Nginx。（這種更適合應用層面的，對於服務內部的快取，還可以採用Guava cache等本地的堆內快取、堆外快取等。）②應用Nginx首先讀取本地快取。如果命中，則直接返回，不命中會讀取分散式快取、回源到Tomcat進行處理。③應用Nginx會將請求上報給實時熱點發現系統，上報給實時熱點發現系統後，它將進行熱點統計。④根據設定的閾值將熱點資料推送到應用Nginx本地快取。6、快取資料一致性

• 訂閱資料變更訊息
• 如果無法訂閱訊息或者訂閱訊息成本比較高，並且對短暫的資料一致性要求不嚴格（比如，在商品詳情頁看到的庫存，可以短暫的不一致，只要保證下單時一致即可），那麼可以設定合理的過期時間，過期後再查詢新的資料。
• 如果是秒殺之類的（熱點資料），可以訂閱活動開啟訊息，將相關資料提前推送到前端應用，並將負載均衡機制降級為輪詢。
• 建立實時熱點發現系統來對熱點進行統一推送和更新

7、快取崩潰恢復

• 主從機制，做好冗餘，即其中一部分不可用，將對等的部分補上去。
• 如果因為快取導致應用可用性已經下降，可以考慮部分使用者降級，然後慢慢減少降級量，後臺通過Worker預熱快取資料。

第12章：連線池執行緒池詳解1、池化技術在應用系統開發中，我們經常會用到池化技術，如物件池、連線池、執行緒池等，通過池化來減少一些消耗，以提升效能。物件池通過複用物件從而減少建立物件、垃圾回收的開銷，但是池不能太大，太大會影響GC時的掃描時間。連線池如資料庫連線池、Redis連線池、HTTP連線池，通過複用TCP連線來減少建立和釋放連線的時間來提升效能。執行緒池也是類似的，通過複用執行緒提升效能。也就是說池化的目的是通過複用技術提升效能。2、連線池使用的建議

• 注意網路阻塞/不穩定時的級聯效應，連線池內部應該根據當前網路的狀態（比如超時次數太多），對於一定時間內的（如100ms）全部timeout，根本不進行await（maxWait），即有熔斷和快速失敗機制。
• 當前等待連線池的數目超過一定量時，接下來的等待是沒有意義的，還會造成滾雪球效應
• 等待超時應儘可能小點（除非很必要）。即使返回錯誤頁，也比等待並阻塞強。

3、執行緒池更多的Java TreadExecutors相關的內容。相關配置項如：核心執行緒池大小、執行緒池最大大小、執行緒的最大空閒時間（超過則回收，直到執行緒數減為核心執行緒大小）、執行緒池的任務緩衝佇列、建立執行緒的工廠、緩衝佇列滿後的拒絕策略等。另外還有支援延時任務的執行緒池。4、執行緒池使用的建議

• 根據任務型別是IO密集型還是CPU密集型、CPU核數，來設定合理的執行緒池大小、佇列大小、拒絕策略，並進行壓測和調優來決定適合場景的引數。
• 使用執行緒池時務必設定池大小、佇列大小並設定相應的拒絕策略。不如可能導致瞬間執行緒數過高、GC慢等問題，造成系統響應慢甚至OOM。

第13章：非同步併發實戰1、非同步與併發當一個執行緒在處理任務時，通過Fork多個執行緒來處理任務並等待這些執行緒的處理結果，這種並不是真正的非同步，這只是併發。非同步是針對CPU和IO的，當IO沒有就緒時，要讓出CPU來處理其他任務，這才是非同步。2、非同步Future執行緒池配合Future實現，但是阻塞主請求流程，高併發時依然會造成執行緒數過多、CPU上下文切換。3、非同步Callback通過回撥機制實現，即首先發出網路請求，當網路返回時回撥相關方法，採用執行緒池分發事件通知，從而有效支撐大量併發連線。這種機制並不能提升效能，而是為了支撐大量併發連線或者提升吞吐量。4、非同步編排CompletableFutureJDK 8 CompletableFuture提供了新的非同步程式設計思路，可以對多個非同步處理進行編排，實現更復雜的非同步處理，其內部使用了ForkJoinPool實現非同步處理。比如三個服務非同步併發呼叫、兩個服務併發呼叫、服務1執行完後再併發執行服務2服務3等場景。5、非同步Web服務實現6、請求快取7、請求合併第14章：如何擴容1、跨庫事務當然分散式事務是一種方式，另一種方式可以考慮sharding-jdbc提供的柔性事務實現。目前支援最大努力送達，就是當事務失敗後通過最大努力反覆嘗試，是在假定資料庫操作一定可以成功的前提下進行的，保證資料最終的一致性。其使用場景是冪等性操作，如根據主鍵刪除資料、帶主鍵插入資料。2、柔性事務sharding-jdbc的最大努力送達型柔性事務分為同步送達和非同步送達兩種，同步送達不需要Zookeeper和elastic-job，內建在柔性事務模組中。非同步送達比較複雜，是對柔性事務的最終補充，不能和應用程式部署在一起，需要額外地通過elastic-job實現。最大努力送達型事務也可能出現錯誤，即無論如何補充都不能正確提交。為了避免反覆嘗試帶來的系統開銷，同步送達和非同步送達均可配置最大重試次數，超過最大重試次數的事務將進入失敗列表。3、資料異構查詢維度異構、聚合據異構4、分散式任務Quartz支援任務的叢集排程，如果一個例項失效，則可以漂移到其他例項進行處理，但是其不支援任務分片。tbschedule和elastic-job除了支援叢集排程特性，還不支援任務分片，從而可以進行動態擴容/縮容5、Elastic-JobElastic-Job是噹噹開源的一款分散式任務排程框架，目前提供了兩個獨立子專案：Elastic-Job-Lite和Elastic-Job-Cloud。Elastic-Job-Lite定位為輕量級無中心解決方案，可以動態暫停/恢復任務例項，目前不支援動態擴容任務例項。Elastic-Job-Cloud使用Mesos+Docker解決方案，可以根據任務負載來動態實現啟動/停止任務例項，以及任務治理。6、Elastic-Job-Lite功能與架構Elastic-Job-Lite實現了分散式任務排程、動態擴容縮容、任務分片、失效轉移、運維平臺等功能。Elastic-Job-Lite採用去中心化的排程方案，由Elastic-Job-Lite的客戶端定時自動觸發任務排程，通過任務分片的概念實現伺服器負載的動態擴容/縮容，並且使用Zookeeper作為分散式任務排程的註冊和協調中心，當某任務例項崩潰後，自動失效轉移，實現高可用，並提供了運維控制檯，實現任務引數的動態修改。第15章：佇列術1、使用佇列注意點我們要考慮是否需要保證訊息處理的有序性及如何保證，是否能重複消費及如何保證重複消費的冪等性。2、佇列應用場景非同步處理、系統解耦、資料同步、流量削鋒、擴充套件性、緩衝等。3、緩衝佇列比如Log4j日誌緩衝區就是使用的緩衝佇列。使用緩衝佇列應對突發流量時，並不能使處理速度變快，而是使處理速度平滑，從而不因瞬間壓力太大而壓垮應用。通過緩衝區佇列可以實現批量處理、非同步處理和平滑流量。4、任務佇列使用任務佇列可以將一些不需要與主執行緒同步執行的任務扔到任務佇列進行非同步處理。可以實現非同步處理、任務分解/聚合處理。5、訊息佇列通過訊息佇列可以實現非同步處理、系統解耦和資料異構。6、請求佇列類似在Web環境下對使用者請求排隊，從而進行一些特殊控制：流量控制、請求分級、請求隔離。例如將請求按照功能劃分不同的佇列，從而使得不同的隊列出問題後相互不影響。還可以對請求分級，一些重要的請求可以優先處理（發展到一定程度應將功能物理分離）。7、資料匯流排佇列8、混合佇列如MQ與Redis的協同組合使用。Disruptor+Redis佇列（P303）9、下單系統水平可擴充套件架構P311 緩衝表+快取+同步worker+降級10、基於Canal實現資料異構背景：在大型網站架構中，一般會採用分庫分表來解決容量和效能問題。但分庫分表後，不同維度的查詢或者聚合查詢就會非常棘手，而且這種方式在大流量系統架構中肯定是不行的。一種解決方式就是資料異構，可以包含具體場景介面的異構、商家維度的異構、ES搜尋異構、訂單快取異構等。第16章：構建需求響應式億級商品詳情頁1、單品頁流量特點單品頁流量的特點是離散資料、熱點少，可以使用各種爬蟲、比價軟體抓取。2、商品詳情頁架構設計原則

• 資料閉環
• 資料維度化
• 拆分系統
• Worker無狀態化+任務化
• 非同步化+併發化
• 多級快取化
• 動態化（資料動態化、模板渲染實時化、重啟應用秒級化、需求上線快速化）
• 彈性化（軟體打包成基礎映象，自動擴容）
• 降級開關
• 多機房多活

本章比較雜、淺，更多的是提供一種思路，需要複習還是通過瀏覽目錄更好。第17章：京東商品詳情頁服務閉環實踐1、設計一個高度靈活的系統時，要想著當出現問題時怎麼辦是否可降級？不可降級怎麼處理？是否會發送滾雪球問題？如何快速響應異常？服務如何更好更有效或者在異常下工作？2、京東商品詳情頁整體流程①請求首先進入Nginx，Nginx呼叫Lua進行一些前置邏輯處理，如果前置邏輯不合法，那麼直接返回，然後查詢本地快取，如果命中，則直接返回資料。②如果本地快取未命中資料，則查詢分散式Redis叢集：如果命中資料，則直接返回。③如果分散式Redis叢集未命中資料，則呼叫Tomcat進行回源處理。然後把結果非同步寫入Redis叢集，並返回。本章比較雜、淺，更多的是提供一種思路，需要複習還是通過瀏覽目錄更好。第18章：使用OpenRestry開發高效能Web應用1、OpenResty簡介OpenResty由Nginx、Lua、ngx_lua模組構成。ngx_lua是章亦春編寫的Nginx的一個模組，將Lua嵌入到Nginx中，從而可以使用Lua來編寫指令碼，部署到Nginx中執行，即Nginx變成了一個Web容器。這樣就可以使用Lua來開發高效能的Web應用了。2、OpenResty生態OpenResty提供了一些常用的ngx_lua開發模組，如lua-resty-memcached、lua-resty-mysql、lua-resty-redis、lua-resty-dns、lua-resty-dns、lua-resty-limit-traffic、lua-resty-template。這些模組涉及如Mysql資料庫、Redis、限流、模組渲染等常用功能元件。另外，也有很多第三方的ngx_lua元件供我們使用。3、京東使用OpenResty場景

• Web應用：會進行一些業務邏輯處理，設定進行CPU的模板渲染，一般流程包括mysql/Redis/HTTP獲取資料、業務處理、產生JSON/XML/模板渲染內容，比如，京東的列表頁/商品詳情頁。
• 接入閘道器：實現如資料校驗前置、快取前置、資料過濾、API請求聚合、A/B測試、灰度釋出、降級、監控等功能，比如，京東的交易大Nginx節點、無線部門的無線閘道器、單品頁統一服務、實時價格、動態服務。
• Web防火牆：可以進行IP/URL/UserAgent/Referer黑名單、限流等功能。
• 快取伺服器：可以對響應內容進行快取，減少到底後端的請求，從而提升效能。
• 其他：如靜態資源伺服器、訊息推送服務、縮圖裁剪等。

4、基於OpenResty的常用架構模式

• 負載均衡
• 單機閉環
• 分散式閉環
• 接入閘道器

5、常見的一些問題

• 在開放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等非正常響應設定快取。

第19章：應用資料靜態化架構高效能單頁Web應用1、傳統靜態化及頁面構建需要考慮的問題

• 頁面模板部分變更類需要重新全部生成
• 動態化模板渲染支援
• 資料和模板的多版本化：生成版本、灰度版和預釋出版本
• 版本回滾問題，假設當前釋出的生成版本出問題了，如何快速回滾到上一個版本。
• 異常問題，假設渲染模板時，遇到了異常情況（比如Redis出問題了），該如何處理
• 灰度釋出問題，比如切20%量給灰度版本。
• 預釋出問題，目的是在正式環境測試資料和模板的正確

2、常見異常問題

• 本機從“釋出資料儲存Redis”和主“釋出資料儲存Redis”都不能用了，那麼可以直接呼叫CMS系統暴露的HTTP服務，直接從元資料儲存Mysql獲取資料。
• 資料和模板獲取到了，但是渲染模板出錯了，比如遇到500、503。解決方案是使用上一個版本的資料進行渲染。
• 資料和模板都沒問題，但是因為一些疏忽，渲染出來的頁面錯亂了，或者有些區域出現了空白。對於這種問題沒有很好的解決方案。可以根據自己的場景定義異常掃描庫，掃到當前版本有異常就發警告給相關人員，並自動降級到上一個版本。

第20、21章內容均為OpenResty的實踐運用，這裡簡單過下就行，真實使用時再細研