cdn本質也是快取，屬於部署在網路服務**商機房中的快取
反向**伺服器本質上也是快取，屬於使用者資料中心最前端的快取
資料庫中的熱點資料，在應用伺服器集群中有一級快取，在快取服務集群中有二級快取
用於url和伺服器ip位址轉換dns伺服器，為了減少重複查詢次數也採用了快取
如果讀取成功，我們稱之為快取命中可以在很大程度上降低訪問資料庫的時間開銷
如果沒有讀取到資料或者快取失效，那麼程式會訪問資料庫，獲取資料後，把資料返回給應用程式同時，還會把資料寫入快取中
在測試執行時需要考慮哪些與快取相關的測試場景
對於前端測試場景，需要分別考慮混村命中和快取不命中情況下頁面載入時間
基於快取過期測試策略的設計，需要考慮到必須要重新獲取資料的測試場景
需要針對可能存在的快取髒資料，進行有針對性的測試，測試髒資料是指資料庫中的資料已經更新，但是快取中資料還沒來得及更新的場景
需要針對可能的快取穿透進行必要的測試。快取穿透，是指訪問的資料並不存在，所以這部分資料永遠不會有快取的機會，因此這類請求會一致重複訪問資料庫
系統冷啟動後，在快取預熱階段的資料庫訪問壓力是否會超過資料庫實際可以承載的壓力
對於分布式快取集群來說，由於各集群使用的快取演算法不同，那麼如果要在快取集群中增加更多節點進行擴容的話，擴容對原本已經快取資料的影響也會不同，所以需要針對快取集群擴容的場景進行必要的測試和效能評估
集群容量擴充套件，就是說，集群中加入新的節點後，是否會對原有session產生影響
對於無狀態應用，是否可以實現靈活的失效轉移
對於基於session的有狀態應用，需要根據不同的session機制驗證繪畫是否可以正常保持，即保證同一session始終都有乙個確定的節點在處理
對於無狀態應用來說，系統吞吐量是否能夠隨著集群中節點的數量呈線性增長
負載均衡演算法的實際效果，是否符合預期
高併發場景下，集群能夠承載的最大容量
通俗叫法
量化的可用性等級
一年中允許的不可用時長
基本可用
2個999%
87.6小時
較高可用
3個999.9%
8.8小時
具備故障自動恢復能力可用
4個999.99%
53分鐘
極高可用
5個999.999%
5分鐘
對於硬體故障造成的**不可用，最直接方案就是從硬體層面加入必要的冗餘，同時充分發揮集群的牲口優勢
對於應用伺服器來說，即使沒有伸縮性要求，也會至少採用兩台同樣的伺服器，並且引入一台額外的負載均衡器，所有的外部請求會先到負載均衡器，然後由負載均衡器根據不同的分配演算法選擇其中的一台伺服器來提供服務
這樣，當其中一台伺服器硬體出現問題甚至宕機後，另一台伺服器可以繼續對外提供服務，這時在外部看起來系統整體依然是可用的
對於資料儲存伺服器，往往通過資料冗餘備份和失效轉移機制實現高可用。為了防止儲存資料的伺服器發生硬體故障而造成資料丟失，我們往往會引入多個資料儲存伺服器，並且在資料有更新操作的時候自動同步多個資料儲存伺服器上的資料
使用灰度發布的前提是，應用伺服器必須採用集群架構，假定現在有乙個包含100節點的集群需要公升級安裝新的應用版本，那麼此時更新過程是：
首先，從負載均衡器的伺服器列表中刪除其中國乙個節點
然後，將新版本的應用部署到這台刪除節點中並重啟服務
重啟完成後，將包含新版本應用的節點重新掛載到負載均衡伺服器中，讓其真正接受外部流量，並嚴格觀察新版本應用的行為
如此重複，直至集群中100個節點全部更新為新版本使用
在這個過程中，服務對外一致處於正常狀態，紅掛上並沒有出現系統不可用情況
如：應用在測試環境中經過了完整、全面的測試，並且所有發現的缺陷已經被修復並驗證通過了，可是一旦發布到了生產環境，還是立馬暴露了很多問題
這其中主要原因是，測試環境和生產環境存在差異，如：網路環境限制不一樣，以來的第三方服務不一樣等
為了避免這類由於環境差異造成的問題，往往會預發布伺服器，預發布伺服器和真實地服務所處的環境沒有任何差別，連線的第三方服務也沒有任何差別，唯一不同是預發布伺服器不會通過負載均衡伺服器對外暴露，只有知道其ip位址的內部人員才可以對其進行訪問
此時，可以借助自動化測試來對應用做快速的驗證測試，如果測試通過，新版本就會進入之前的灰度發布階段。這種做法可以盡最大可能保證上線應用的可用性
根據功能本身進行物理分離來實現伸縮過程中，還有兩種不同的實現方式
同樣，對於單一功能可以通過增加/減少硬體來實現可伸縮性，也有兩種不同的實現方式
基於集群的可伸縮性設計，適合**本身的分層架構設計相對的
需要通過壓力測試得出單一節點的負載承受能力
驗證系統整體的負載承受能力，是否能夠隨著集群中節點數量呈現線性增長
集群中節點的數量是否有上限
新加入的節點是否可以提供和原來節點無差異的服務
對於有狀態的應用，是否能夠實現依次繪畫(session)多次請求都被分配到集群中某一台固定的伺服器上
驗證負載均衡演算法的準確性
快取集群中如果有3臺機器，將內容快取到集群中
將內容kay值做hash運算，將hash值對3取餘，將快取內容寫入餘數對應的伺服器
此時在集群中新增了一台伺服器，那麼此時機器數量變成了4，此時kay的hash值應該對4取餘，這樣原先的大部分快取資料就失效了
針對快取集群中新增家電的測試，驗證其對原有快取的影響是否足夠小
驗證系統冷啟動完成後，快取中還沒有任何資料時，如果此時**負載較大，資料庫是否可以承受這樣的壓力
需要驗證各種情況下，快取資料和資料庫資料一致性
驗證是否已經對潛在的快取穿透攻擊進行了處理，因為如果被攻擊，可能拖垮資料庫
2，讀寫分離的資料庫設計
3，分布式資料庫
4，nosql設計
從測試角度觸發，無論資料庫那種架構設計，一本都會從以下幾個方面來考慮用例設計
正確讀取到剛寫入資料的延時時間
在資料庫架構發生改變胡總和同樣的架構設局庫引數發生改變時，資料庫基準效能是否會發生明顯的變化
壓力測試過程中，資料庫伺服器的各項監控指標是否符合預期
資料庫集群中，某個節點由於硬體故障對業務的影響程度
在這種模式下，訊息傳送者和接收者之間沒有任何之間的聯絡，是松耦合的。他們的協作是通過訊息佇列這個中間人進行的。訊息的傳送者將訊息傳送到訊息佇列後，就結束了對訊息的處理，而訊息的接收者只是從訊息佇列中獲取訊息進行後續處理，並不需要知道這些訊息從**來，因此可以很方便的實現高擴充套件性
所以採用這種模式，當**需要增加新功能時，只需要增加對應的新模組，再由對此感興趣的消費者進行訂閱，就可以實現對原有系統功能的擴充套件，而對原本的系統模組本身並沒有影響
引入訊息佇列後，不僅可以提高系統的可擴充套件性，還可以在一定程度上改善**架構的高效能、高可用和可伸縮性
引入訊息佇列後，測試人員需要關注的點
從構建測試資料角度看，為了以解耦方式測試系統中各個模組，需要在訊息佇列中構建測試資料。這也是很多網際網路自動化測試框架中都會整合訊息佇列寫入工具的主要原因
從測試驗證角度看，不僅需要驗證模組的行為，還要驗證模組在訊息佇列中輸出是否符合預期，為此，系動畫測試框架中也會整合訊息佇列讀取工具
從測試設計角度看，需要考慮訊息佇列隊滿、訊息佇列擴容等情況下系統功能是否符合設計預期
還要考慮，訊息佇列機器宕機情況下，丟失訊息的可恢復性以及新的訊息不會繼續發往宕機的伺服器等
模擬測試12
考試剛發下題時的我 這什麼題，連思路啟發都沒有，毒瘤出題人！不可做！考後乙個字乙個字看著題解改出來的我 我去這麼水！這不沙幣題嗎！考後看著題解改不出來的我 這什麼題，沒一點思維含量，辣雞調試題！考後看不懂題解的我 這題解怎麼寫的比題目還短，一點素質沒有！考後看題解懵比的我 這解法怎麼這麼流氓！這解法...
Go語言學習草稿 12 測試
package main import strings 待測試的字串切割函式 func split str string sep string string ret ret,str return ret func main 單元測試的檔名必須是原檔名 test package main import...
C 基礎學習之12 測試驅動開發
測試驅動開發，英文全稱 test driven development，簡稱tdd，是一種不同於傳統軟體開發流程的新型的開發方法。它要求在編寫某個功能的 之前先編寫測試 然後只編寫使測試通過的功能 通過測試來推動整個開發的進行。這有助於編寫簡潔可用和高質量的 並加速開發過程。測試驅動開發的基本過程如...