區域性過濾器：
對某乙個或者某一些請求過濾處理案列 : 防止提前下單的操作
1.建乙個類防止搶卷時提前下單的區域性過濾器
/**
* 防止搶卷時提前下單的區域性過濾器
* 過濾器鏈肯定要預先級
* springcloud gateway x servlet技術（命令式程式設計） webflux(響應式程式設計技術)
*/public
class
qiangjuanfilter
implements
gatewayfilter
, ordered
/** * 當前過濾器的順序值越小，優先順序越大，可以是負數
* @return
*/@override
public
intgetorder()
}
/**
* gateway 不能新增spring-boot-starter-web這個依賴。是因為scanbasepackages = "com.qf"會掃瞄到全域性異常裡面的類，類裡面又有註解用到了spring-boot-starter-web依賴所以會報錯
*/@componentscan
(basepackages =
"com.qf"
,excludefilters = @componentscan.
filter
(type = filtertype.assignable_type,classes =))
@enableeurekaclient
/**
* 區域性過濾器的工廠
*/@component
public
class
qiangjuanfilte***ctory
extends
abstractgatewayfilte***ctory
/** * 設定區域性過濾器的名稱
* @return
*/@override
public string name()
}
- id: qiangjuan
uri: lb:
//micro-qiangjuan
predicates:
- path=
/qiangjuan/get
filters:
- myfilter
- id: qiangjuan
uri: lb:
//micro-qiangjuan
predicates:
- path=
/qiangjuan/**
1.對所有請求都進行過濾處理
2.基於過濾器的請求限流
在解決高併發的有效途徑是redis快取資料盡可能的提高的響應速度，還有乙個就是限流，可以接入第三方服務，很多服務會給乙個限制，比如你是普通使用者，每天只能調100次介面比如發簡訊，要是你充錢了就可以呼叫1000次。在高併發的情況下可以保護後端服務的作用。限流的缺陷就是，有可能會乾掉有效的請求，因為限流的原因沒辦法處理。
請求計數限流：把限流的限制條件寫到到redis裡面去。首先在getway寫乙個過濾器，redis裡寫乙個計數器number，計數初始為零，過期時間expire為1秒，最大計數maxnumber是100次，乙個請求通過getway裡面的過濾器，過濾器只做一件事對redis的number++,加完之後沒有超過maxnumber，這個請求就正常的放行如果請求次數超過了maxnumber就不放行處理了，1秒之後不管之前累加了多少次就過期了，又重新計算這樣就保證了每秒能保證有最大計數maxnumber。這裡maxnumber取決於後台1秒你承受的壓力。這種方式是有問題的，假如我們把1秒分為兩個0.5秒，前0…5秒沒有請求，後0.5秒有100次請求，第二秒的前0.5秒有100次請求，後0.5秒沒有，那麼在中間這1秒就發生了200次請求。後台就坑不住壓力了。
漏桶演算法限流：用的比較少
令牌桶演算法限流：他的核心原理是，準備乙個令牌桶，令牌桶裡面放乙個個的令牌token，令牌最大容量，按照乙個頻率固定的往令牌桶裡面放令牌。假設1秒鐘放100個令牌他不是1秒100的放，他是10毫秒放1個令牌，保證1秒放到100個令牌。令牌桶滿了就所有的令牌丟棄掉。這個時候來了乙個請求去令牌桶申請乙個乙個令牌拿到了令牌的請求就往後走，沒拿到令牌要麼等待，要麼拒絕。這樣就不會出現請求計數限流的缺陷。現在一般都是用的限流用的都是令牌桶。他的優勢就是允許小時間範圍的併發。
那該怎麼實現呢？首先開乙個執行緒，固定的往乙個桶裡面放，那這個桶是什麼呢？這個桶我們可以用hash結構，hash結構是key filed value 這個key就是桶的名字，filed就是令牌的數量 ，和桶的令牌最大的數量。
桶多了就不太合適了，具體可以這麼做：每秒鐘放多少令牌，乙個令牌要放多少時間這只是乙個概念。假如現在桶裡面有10個令牌，同時在記錄一下當時的時間，現在有乙個請求過來要去拿令牌了，比如現在有乙個請求要拿20個令牌，明顯10個令牌不夠，但是請求來的時候也有乙個時間，這個時間和記錄時間有乙個時間差，如果差了2秒，理論上會產生200個令牌，所以桶裡面的令牌應該是210個，但是不能超過最大值，這個時候令牌最終是100個，所以令牌是夠取的。所以實際上是沒有放令牌這個動作的，只要拿令牌的時候去算一下當前令牌的數量，這樣做的好處就是沒有放令牌的執行緒，但是還有乙個問題拿令牌的時候又要去算，又要去取，還要更新令牌是會有執行緒安全問題的，這個時候就用lua腳步原子性。
gateway基於redis實現令牌桶演算法限流：這個key就是你根據什麼來限流的憑證，假如我是根據介面限流的現在有乙個qinango的介面，那麼qinango的介面路徑就是key只要訪問這個介面就是同乙個桶， 這樣就會被桶裡面的令牌給限制住。假如我是使用者限流，key就是使用者id了，這樣相同的使用者id就用同乙個桶。那桶裡面field value有哪些呢？有令牌數量 tokens 100個，最大的令牌數maxtokens 100,1秒鐘會放多少令牌 tokensec 50。如果桶一多效能就會越來越差，所以一般來講令牌桶會在桶裡面多加乙個字段，叫下乙個可以取令牌的時間，nextime 這個時間是微妙值。我們獲取令牌的時候花點時間去計算一下令牌，這個微妙值就是計算的時間，這樣做的好處就是沒有執行緒放令牌減少服務的壓力。令牌桶支援預支令牌的操作，在高併發的情況下，可能往往很難找到令牌桶裡面滿足你當前令牌的時刻，那麼這個請求就沒有辦法執行
Spring Boot 使用 AOP 防止重複提交
在傳統的web專案中，防止重複提交，通常做法是 後端生成乙個唯一的提交令牌 uuid 並儲存在服務端。頁面提交請求攜帶這個提交令牌，後端驗證並在第一次驗證後刪除該令牌，保證提交請求的唯一性。上述的思路其實沒有問題的，但是需要前後端都稍加改動，如果在業務開發完在加這個的話，改動量未免有些大了，本節的實...
防止指令碼sudo提權，如何修改
sudo提權就是普通使用者可以攻擊系統，以root許可權執行自己想執行的指令碼 sudo執行的指令碼在 etc sudoers裡面可以查到 這些指令碼一般沒有寫的許可權為400，但是該指令碼所在的目錄存在寫的許可權為700，而且歸屬普通使用者 攻擊者可以以普通使用者，mv掉這個目錄，寫乙個同名的目錄...
linux安全加固 鎖定關鍵系統檔案，防止提權篡改
要鎖定關鍵系統檔案，必須對賬號密碼檔案及啟動檔案加鎖，防止被篡改。chattr與lsattr chattr命令可以鎖定檔案。通過chattr命令修改屬性能夠提高系統的安全性，但是它並不適合所有的目錄。chattr命令不能保護 dev tmp var目錄。lsattr命令是顯示chattr命令設定的檔...