老板讓你抗住千萬(wàn)級(jí)流量，如何做架構(gòu)設(shè)計(jì)?首先，要在我們架構(gòu)設(shè)計(jì)的時(shí)候建立一些原則。

[[284533]]

1實(shí)現(xiàn)高并發(fā)

服務(wù)拆分： 將整個(gè)項(xiàng)目拆分成多個(gè)子項(xiàng)目或者模塊，分而治之，將項(xiàng)目進(jìn)行水平擴(kuò)展。

服務(wù)化： 解決服務(wù)調(diào)用復(fù)雜之后的服務(wù)的注冊(cè)發(fā)現(xiàn)問(wèn)題。消息隊(duì)列： 解耦，異步處理緩存： 各種緩存帶來(lái)的并發(fā)

2實(shí)現(xiàn)高可用

集群、限流、降級(jí)

3業(yè)務(wù)設(shè)計(jì)

冪等： 就是用戶對(duì)于同一操作發(fā)起的一次請(qǐng)求或者多次請(qǐng)求的結(jié)果是一致的，不會(huì)因?yàn)槎啻吸c(diǎn)擊而產(chǎn)生了副作用，就像數(shù)學(xué)里的數(shù)字1，多少次冪的結(jié)果都是1。舉個(gè)最簡(jiǎn)單的例子，那就是支付，用戶購(gòu)買商品后支付，支付扣款成功，但是返回結(jié)果的時(shí)候網(wǎng)絡(luò)異常，此時(shí)錢已經(jīng)扣了，用戶再次點(diǎn)擊按鈕，此時(shí)會(huì)進(jìn)行第二次扣款，返回結(jié)果成功，用戶查詢余額發(fā)現(xiàn)多扣錢了，流水記錄也變成了兩條。

防重： 防止同樣的數(shù)據(jù)同時(shí)提交

除了在業(yè)務(wù)方向判斷和按鈕點(diǎn)擊之后不能繼續(xù)點(diǎn)擊的限制以外，在服務(wù)器端也可以做到防重：

在服務(wù)器端生成一個(gè)唯一的隨機(jī)標(biāo)識(shí)號(hào)(Token<令牌>)同事在當(dāng)前用戶的Session域中保存這個(gè)令牌，然后將令牌發(fā)送到客戶端的form表單中，在form表單中使用隱藏域來(lái)存儲(chǔ)這個(gè)Token，表單提交的時(shí)候聯(lián)通這個(gè)Token一起提交到服務(wù)器，然后在服務(wù)器端判斷客戶提交上來(lái)的Token與服務(wù)器端生成的Token是否一致，如果不一致，那就重復(fù)提交了，此時(shí)服務(wù)器端就可以不處理重復(fù)提交的表單，如果相同則處理表單，處理完后清楚當(dāng)前用戶的Session域中存儲(chǔ)的標(biāo)識(shí)號(hào)。高可用高并發(fā)架構(gòu)參考：高可用高并發(fā)的 9 種技術(shù)架構(gòu)。

在下列情況中，服務(wù)器程序?qū)⒕芙^處理用戶提交的表單請(qǐng)求： 1)存儲(chǔ)Session域中的Token與表單提交的Token不一致 2)當(dāng)前用戶的Session中不存在Token 3)用戶提交的表單數(shù)據(jù)中沒(méi)有Token。

狀態(tài)機(jī)

軟件設(shè)計(jì)中的狀態(tài)機(jī)概念，一般是指有限狀態(tài)機(jī)(英語(yǔ)：finite-state machine，縮寫：FSM)又稱有限狀態(tài)自動(dòng)機(jī)，簡(jiǎn)稱狀態(tài)機(jī)，是表示有限個(gè)狀態(tài)以及在這些狀態(tài)之間的轉(zhuǎn)移和動(dòng)作等行為的數(shù)學(xué)模型。

這里著重講一下限流的概念和例子

限流的目的限流的目的是通過(guò)對(duì)并發(fā)訪問(wèn)/請(qǐng)求進(jìn)行限速或者一個(gè)時(shí)間窗口內(nèi)的請(qǐng)求進(jìn)行限速來(lái)保護(hù)系統(tǒng)的可用性，一旦達(dá)到限制速率就可以拒絕服務(wù)。就像手機(jī)預(yù)售一樣，假如要賣出3萬(wàn)臺(tái)，只需要接收3萬(wàn)用戶的請(qǐng)求就可以，其他的用戶請(qǐng)求可以選擇過(guò)濾，可以提示"當(dāng)前服務(wù)器過(guò)忙，請(qǐng)稍后再試"的提示。推薦大家看這篇文章：接口限流算法：漏桶算法&令牌桶算法。

限流方式：

1. 限制瞬時(shí)并發(fā)數(shù) ：比如在入口層(nginx添加nginxhttplimitconnmodule)來(lái)限制同一個(gè)ip來(lái)源的連接數(shù)，防止惡意攻擊訪問(wèn)的情況。

2. 限制總并發(fā)數(shù)：通過(guò)配置數(shù)據(jù)庫(kù)連接池、線程池大小來(lái)約束總并發(fā)數(shù)

3. 限制時(shí)間窗口內(nèi)的平均速率：在接口層面，通過(guò)限制訪問(wèn)速率來(lái)控制接口的并發(fā)請(qǐng)求。

4. 其他方式：限制遠(yuǎn)程接口的調(diào)用速率、限制MQ的消費(fèi)速率。

常用限流算法

1. 滑動(dòng)窗口協(xié)議：一種常見(jiàn)的流量控制技術(shù)，用來(lái)改善吞吐量的技術(shù)。

滑動(dòng)窗口協(xié)議的由來(lái)：

滑動(dòng)窗口(sliding window)是一種流量控制技術(shù)。早期的網(wǎng)絡(luò)通訊中，通信雙方不會(huì)考慮網(wǎng)絡(luò)的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡(luò)擁塞狀況，同時(shí)發(fā)送數(shù)據(jù)，導(dǎo)致中間節(jié)點(diǎn)阻塞掉包，誰(shuí)也發(fā)送不了數(shù)據(jù)，所以就有了滑動(dòng)窗口機(jī)制來(lái)解決此問(wèn)題。 發(fā)送和接收方都會(huì)維護(hù)一個(gè)數(shù)據(jù)幀的序列，這個(gè)序列被稱為窗口。

定義：滑動(dòng)窗口協(xié)議(Sliding Window Protocol)，屬于TCP協(xié)議的一種應(yīng)用，用于網(wǎng)絡(luò)數(shù)據(jù)傳輸時(shí)的流量控制，以避免擁塞的發(fā)生。該協(xié)議允許發(fā)送方在停止并等待確認(rèn)前發(fā)送多個(gè)數(shù)據(jù)分組。由于發(fā)送方不必每發(fā)一個(gè)分組就停下來(lái)等待確認(rèn)，因此該協(xié)議可以加速數(shù)據(jù)的傳輸，提高網(wǎng)絡(luò)吞吐量。

發(fā)送窗口：就是發(fā)送端允許連續(xù)發(fā)送的幀的序號(hào)表。發(fā)送端可以不等待應(yīng)答而連續(xù)發(fā)送數(shù)據(jù)(可以通過(guò)設(shè)置窗口的尺寸來(lái)控制)

接收窗口：接收方允許接收的幀的序列表，凡是落在接收窗口內(nèi)的幀，接收方都必須處理，落在接收窗口外的幀將被丟棄。接收方每次允許接收的幀數(shù)稱為接收窗口的尺寸　　

演示地址：https://media.pearsoncmg.com/aw/ecskurosecompnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html

2. 漏桶：漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。

漏桶算法思路很簡(jiǎn)單，請(qǐng)求先進(jìn)入到漏桶里，漏桶以一定的速度出水。當(dāng)水請(qǐng)求過(guò)大會(huì)直接溢出，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。進(jìn)入端無(wú)需考慮出水端的速率，就像mq消息隊(duì)列一樣，provider只需要將消息傳入隊(duì)列中，而不需要關(guān)心Consumer是否接收到了消息。

對(duì)于溢出的水，就是被過(guò)濾的數(shù)據(jù)，可以直接被丟棄，也可以通過(guò)某種方式暫時(shí)保存，如加入隊(duì)列之中，像線程池里對(duì)溢出數(shù)據(jù)的4種處理機(jī)制一樣

3. 令牌桶：屬于控制速率類型的限流算法。

對(duì)于很多應(yīng)用場(chǎng)景來(lái)說(shuō)，除了要求能夠限制數(shù)據(jù)的平均傳輸速率外，還要求允許某種程度的突發(fā)傳輸。這時(shí)候漏桶算法可能就不合適了，令牌桶算法更為適合。令牌桶算法的原理是系統(tǒng)會(huì)以一個(gè)恒定的速度往桶里放入令牌，而如果請(qǐng)求需要被處理，則需要先從桶里獲取一個(gè)令牌，當(dāng)桶里沒(méi)有令牌可取時(shí)，則拒絕服務(wù)。

設(shè)置 Rate = 2 ：每秒放入令牌的個(gè)數(shù)

桶的大?。?00

這里用一個(gè)小demo來(lái)實(shí)現(xiàn)一下令牌桶

public class TokenDemo { 
  //qps:每秒鐘處理完請(qǐng)求的次數(shù)；tps:每秒鐘處理完的事務(wù)次數(shù) 
  //代表qps是10； 
  RateLimiter rateLimiter = RateLimiter.create(10); 
  public void doSomething(){ 
      if (rateLimiter.tryAcquire()){ 
          //嘗試獲得令牌.為true則獲取令牌成功 
          System.out.println("正常處理"); 
      }else{ 
          System.out.println("處理失敗"); 
      } 
  } 
  public static void main(String args[]) throwsIOException{ 
      /* 
      * CountDownLatch是通過(guò)一個(gè)計(jì)數(shù)器來(lái)實(shí)現(xiàn)的，計(jì)數(shù)器的初始值為線程的數(shù)量，此值是線程將要等待的操作數(shù)（線程的數(shù)量）。 
      * 當(dāng)某個(gè)線程為了想要執(zhí)行這些操作而等待時(shí)， 它要使用 await()方法。 
      * 此方法讓線程進(jìn)入休眠直到操作完成。 
      * 當(dāng)某個(gè)操作結(jié)束，它使用countDown() 方法來(lái)減少CountDownLatch類的內(nèi)部計(jì)數(shù)器，計(jì)數(shù)器的值就會(huì)減1。 
      * 當(dāng)計(jì)數(shù)器到達(dá)0時(shí)，它表示所有的線程已經(jīng)完成了任務(wù)，這個(gè)類會(huì)喚醒全部使用await() 方法休眠的線程們恢復(fù)執(zhí)行任務(wù)。 
      * 
      * */ 
      CountDownLatch latch = new CountDownLatch(1); 
      Random random = new Random(10); 
      TokenDemo tokenDemo = new TokenDemo(); 
      for (int i=0;i<20;i++){ 
          new Thread(()->{ 
              try { 
                  latch.await(); 
                  Thread.sleep(random.nextInt(1000)); 
                  tokenDemo.doSomething(); 
              }catch (InterruptedException e){ 
                  e.printStackTrace(); 
              } 
          }).start(); 
      } 
      latch.countDown(); 
      System.in.read(); 
  } 
} 

執(zhí)行結(jié)果：

正常處理 
正常處理 
正常處理 
正常處理 
正常處理 
處理失敗 
正常處理 
處理失敗 
處理失敗 
處理失敗 
正常處理 
處理失敗 
正常處理 
處理失敗 
正常處理 
正常處理 
正常處理 
正常處理 
處理失敗 
處理失敗 

由此可見(jiàn)，當(dāng)令牌不足時(shí)，會(huì)獲取令牌失敗，達(dá)到限流的效果。