【課程20】jmeter.xmind81.5KBreact
【課程20】秒殺項目雜談.xmind0.2MBredis
代碼片斷：算法
RedisTool.java3.2KBspring
MiaoshaInterface.java4.7KB數據庫
測試過程當中，發現了一個bug。apache
wang.moshu.cache.MiaoshaSuccessTokenCache#validateTokenByKey（）方法。緩存
截取商品的goodsRandomName的開始這裏應該加一。服務器
goodsRedisStoreCache.incrStore(key.substring(key.lastIndexOf(":")+1, key.lastIndexOf("_")));
高併發測試，學會使用jmeter
jmeter下載地址：http://jmeter.apache.org/download_jmeter.cgi網絡
漢化步驟：
打開bin/jmeter.properties。搜索language=en。替換成language=zh_CN。去掉註釋。
百度百科
Apache jmeter 能夠用於對靜態的和動態的資源（文件，Servlet，Perl腳本，java 對象，數據庫和查詢， FTP服務器 等等）的性能進行測試。它能夠用於對服務器、網絡或對象模擬繁重的負載來測試它們的強度或分析不一樣壓力類型下的總體性能。你可使用它作性能的圖形分析或在大併發 負載測試 你的服務器/腳本/對象。
(1)壓力測試及性能測試；
(2)數據庫測試；
(3)Java程序的測試；
(4)HTTP及FTP測試；
(5)Web Service測試；
線程組：全部的任務都是基於線程組，開通多少個線程就表明有多少個併發用戶；
Ramp-Up Period：在這麼多時間內完成所有測試，好比開了2個線程，而Ramp-Up Period爲3，則每一個線程的間隔爲1.5秒；
Sampler(取樣器)：全部的測試任務都是Sampler，即任何測試任務的類別都是Sampler，好比HTTP請求、JDBC請求、FTP請求；
斷言：對Sampler的測試進行判斷是否正確；
監聽器：對Sampler的請求結果進行統計、顯示；
簡單入門
Test Plan (測試計劃)：用來描述一個性能測試，包含與本次性能測試全部相關的功能。也就說本的性能測試的全部內容是於基於一個計劃的。
添加一個線程組（用戶數）
- 用戶數
- 過渡期 (用戶組發出請求的間隔時間)
- 循環次數 (這個線程的運行次數)
增長一個例程(HTTP 請求)到這個組中
- 服務器名(Server Name) 或 IP
- 路徑(Path)
定義完這個後，測試就準備好了，但咱們一般須要一些測試報告。在 JMeter 中，咱們稱這種組件爲監聽器。所以，在這個測試計劃中，加上一個監聽器：
你的所有的請求響應結果都將會顯示在這裏。按：Ctrl + R 開始運行這個測試。若是打開結果視圖窗口(View Results Tree)，你能夠看到實時的運行狀態。運行完後，你能夠再按： Ctrl + E 來清除舊的結果，並從新按 Ctrl + R 來從新啓動一次新的測試。
分析結果
一、查看結果樹
如圖所示：成功的爲綠色，失敗則顯示爲紅色。若是測試的結果太多，你只須要看到錯誤的頁面，則勾選【僅日誌錯誤】
二、聚合報告(Aggregate Report)
其中：
Label：標籤，即咱們上面的請求名稱
#Samples：本次場景中一共發出了多少個請求
Average：平均響應時間
Median：中位數，也就是50%的用戶的響應時間
90%Line：表示90%的用戶的響應時間，若是最小值和最大值相差很大的話，咱們通常選擇這個做爲最終測試結果
Min：最小響應時間
Max：最大響應時間
Error%：出錯率，本次測試中出現錯誤的請求的數量/請求的總數
Throughput：吞吐量
KB/sec：每秒從服務器端接受到的數據量
三、圖形結果：能夠圖形顯示吞吐量、響應時間等
分佈式鎖
（java內存模型抽象結構）
併發處理手段
1.加synchronized鎖單線程處理、缺點： （對象鎖和類鎖）
2.redis分佈式鎖：
- 3.能夠更細粒的控制代碼（多臺機器上多個線程對一個數據進行操做的互斥）
synchronized的用法
class Foo{
static synchronized void bar();
synchronized void bar();
void bar(){
synchronized(Foo.class){};
}
void bar(){
synchronized(this){}
}
}
分佈式事務
原子性(Atomicity )、一致性( Consistency )、隔離性或獨立性( Isolation)和持久性(Durabilily)，簡稱就是ACID
CAP原則
實現一致性：
BASE理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。
BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。
緩存問題
做者：我必定會有貓的
連接：https://juejin.im/post/5b604b9ef265da0f62639001
緩存穿透
緩存穿透是指查詢一個必定不存在的數據，由於緩存中也無該數據的信息，則會直接去數據庫層進行查詢，從系統層面來看像是穿透了緩存層直接達到db，從而稱爲緩存穿透。
相似於哈希表的一種算法，用全部可能的查詢條件生成一個bitmap，在進行數據庫查詢以前會使用這個bitmap進行過濾，若是不在其中則直接過濾，從而減輕數據庫層面的壓力。
一種比較簡單的解決辦法，在第一次查詢完不存在的數據後，將該key與對應的空值也放入緩存中，只不過設定爲較短的失效時間，例如幾分鐘，這樣則能夠應對短期的大量的該key攻擊，設置爲較短的失效時間是由於該值可能業務無關，存在乎義不大，且該次的查詢也未必是攻擊者發起，無太久存儲的必要，故能夠早點失效。
緩存雪崩
在普通的緩存系統中通常例如redis、memcache等中，咱們會給緩存設置一個失效時間，可是若是全部的緩存的失效時間相同，那麼在同一時間失效時，全部系統的請求都會發送到數據庫層，db可能沒法承受如此大的壓力致使系統崩潰。
只讓一個線程構建緩存，其餘線程等待構建緩存的線程執行完，從新從緩存獲取數據才能夠，每一個時刻只有一個線程在執行請求，減輕了db的壓力，但缺點也很明顯，下降了系統的qps。
這種方法時間比較簡單粗暴，既然在同一時間失效會形成請求過多雪崩，那咱們錯開不一樣的失效時間便可從必定長度上避免這種問題，在緩存進行失效時間設置的時候，從某個適當的值域中隨機一個時間做爲失效時間便可。
緩存擊穿
緩存擊穿其實是緩存雪崩的一個特例，你們使用過微博的應該都知道，微博有一個熱門話題的功能，用戶對於熱門話題的搜索量每每在一些時刻會大大的高於其餘話題，這種咱們成爲系統的「熱點「，因爲系統中對這些熱點的數據緩存也存在失效時間，在熱點的緩存到達失效時間時，此時可能依然會有大量的請求到達系統，沒有了緩存層的保護，這些請求一樣的會到達db從而可能引發故障。擊穿與雪崩的區別即在於擊穿是對於特定的熱點數據來講，而雪崩是所有數據。
對於熱點數據進行二級緩存，並對於不一樣級別的緩存設定不一樣的失效時間，則請求不會直接擊穿緩存層到達數據庫。
應用限流
計數器法
- 例如數據庫鏈接池大小，線程池大小，秒殺併發數限制。全局請求數量達到必定閾值進行限流。
滑動窗口
- 在上圖中，整個紅色的矩形框表示一個時間窗口，在咱們的例子中，一個時間窗口就是一分鐘。而後咱們將時間窗口進行劃分，好比圖中，咱們就將滑動窗口 劃成了6格，因此每格表明的是10秒鐘。每過10秒鐘，咱們的時間窗口就會往右滑動一格。每個格子都有本身獨立的計數器counter，好比當一個請求 在0:35秒的時候到達，那麼0:30~0:39對應的counter就會加1。
漏桶算法
令牌桶算法
- 1）存放固定令牌的桶100，生產令牌的速率固定 10/s
- 3）n個請求過來，拿n個令牌，若令牌不足，則請求被決絕或等待
對比：令牌桶算法可一次拿n個令牌，說明容許突發請求。漏桶算法流出速率固定，說明會平滑處理突發請求
