介面效能優化的11個小技巧，sql優化

阿新 • • 發佈：2022-12-05

前言

介面效能優化對於從事後端開發的同學來說，肯定再熟悉不過了，因為它是一個跟開發語言無關的公共問題。

該問題說簡單也簡單，說複雜也複雜。

有時候，只需加個索引就能解決問題。

有時候，需要做程式碼重構。

有時候，需要增加快取。

有時候，需要引入一些中介軟體，比如mq。

有時候，需要需要分庫分表。

有時候，需要拆分服務。

等等。。。

導致介面效能問題的原因千奇百怪，不同的專案不同的介面，原因可能也不一樣。

本文我總結了一些行之有效的，優化介面效能的辦法，給有需要的朋友一個參考。

1.索引

介面效能優化大家第一個想到的可能是：優化索引。

沒錯，優化索引的成本是最小的。

你通過檢視線上日誌或者監控報告，查到某個介面用到的某條sql語句耗時比較長。

這時你可能會有下面這些疑問：

該sql語句加索引了沒？
加的索引生效了沒？
mysql選錯索引了沒？

1.1 沒加索引

sql語句中where條件的關鍵欄位，或者order by後面的排序欄位，忘了加索引，這個問題在專案中很常見。

專案剛開始的時候，由於表中的資料量小，加不加索引sql查詢效能差別不大。

後來，隨著業務的發展，表中資料量越來越多，就不得不加索引了。

可以通過命令：

show index from `order`;

能單獨檢視某張表的索引情況。

也可以通過命令：

show create table `order`;

檢視整張表的建表語句，裡面同樣會顯示索引情況。

通過ALTER TABLE

命令可以新增索引：

ALTER TABLE `order` ADD INDEX idx_name (name);

也可以通過CREATE INDEX命令新增索引：

CREATE INDEX idx_name ON `order` (name);

不過這裡有一個需要注意的地方是：想通過命令修改索引，是不行的。

目前在mysql中如果想要修改索引，只能先刪除索引，再重新新增新的。

刪除索引可以用DROP INDEX命令：

ALTER TABLE `order` DROP INDEX idx_name;

用DROP INDEX命令也行：

DROP INDEX idx_name ON `order`;

1.2 索引沒生效

通過上面的命令我們已經能夠確認索引是有的，但它生效了沒？此時你內心或許會冒出這樣一個疑問。

那麼，如何檢視索引有沒有生效呢？

答：可以使用explain命令，檢視mysql的執行計劃，它會顯示索引的使用情況。

例如：

explain select * from `order` where code='002';

結果：通過這幾列可以判斷索引使用情況，執行計劃包含列的含義如下圖所示：如果你想進一步瞭解explain的詳細用法，可以看看我的另一篇文章《explain | 索引優化的這把絕世好劍，你真的會用嗎？》

說實話，sql語句沒有走索引，排除沒有建索引之外，最大的可能性是索引失效了。

下面說說索引失效的常見原因：如果不是上面的這些原因，則需要再進一步排查一下其他原因。

1.3 選錯索引

此外，你有沒有遇到過這樣一種情況：明明是同一條sql，只有入參不同而已。有的時候走的索引a，有的時候卻走的索引b？

沒錯，有時候mysql會選錯索引。

必要時可以使用force index來強制查詢sql走某個索引。

至於為什麼mysql會選錯索引，後面有專門的文章介紹的，這裡先留點懸念。

2. sql優化

如果優化了索引之後，也沒啥效果。

接下來試著優化一下sql語句，因為它的改造成本相對於java程式碼來說也要小得多。

下面給大家列舉了sql優化的15個小技巧：由於這些技巧在我之前的文章中已經詳細介紹過了，在這裡我就不深入了。

更詳細的內容，可以看我的另一篇文章《聊聊sql優化的15個小技巧》，相信看完你會有很多收穫。

3. 遠端呼叫

很多時候，我們需要在某個介面中，呼叫其他服務的介面。

比如有這樣的業務場景：

在使用者資訊查詢介面中需要返回：使用者名稱稱、性別、等級、頭像、積分、成長值等資訊。

而使用者名稱稱、性別、等級、頭像在使用者服務中，積分在積分服務中，成長值在成長值服務中。為了彙總這些資料統一返回，需要另外提供一個對外介面服務。

於是，使用者資訊查詢介面需要呼叫使用者查詢介面、積分查詢介面和成長值查詢介面，然後彙總資料統一返回。

呼叫過程如下圖所示：呼叫遠端介面總耗時 530ms = 200ms + 150ms + 180ms

顯然這種序列呼叫遠端介面效能是非常不好的，呼叫遠端介面總的耗時為所有的遠端介面耗時之和。

那麼如何優化遠端介面效能呢？

3.1 並行呼叫

上面說到，既然序列呼叫多個遠端介面效能很差，為什麼不改成並行呢？

如下圖所示：呼叫遠端介面總耗時 200ms = 200ms（即耗時最長的那次遠端介面呼叫）

在java8之前可以通過實現Callable介面，獲取執行緒返回結果。

java8以後通過CompleteFuture類實現該功能。我們這裡以CompleteFuture為例：

public UserInfo getUserInfo(Long id) throws InterruptedException, ExecutionException {
    final UserInfo userInfo = new UserInfo();
    CompletableFuture userFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteUserAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);

    CompletableFuture bonusFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteBonusAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);

    CompletableFuture growthFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteGrowthAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);
    CompletableFuture.allOf(userFuture, bonusFuture, growthFuture).join();

    userFuture.get();
    bonusFuture.get();
    growthFuture.get();

    return userInfo;
}

溫馨提醒一下，這兩種方式別忘了使用執行緒池。示例中我用到了executor，表示自定義的執行緒池，為了防止高併發場景下，出現執行緒過多的問題。

3.2 資料異構

上面說到的使用者資訊查詢介面需要呼叫使用者查詢介面、積分查詢介面和成長值查詢介面，然後彙總資料統一返回。

那麼，我們能不能把資料冗餘一下，把使用者資訊、積分和成長值的資料統一儲存到一個地方，比如：redis，存的資料結構就是使用者資訊查詢介面所需要的內容。然後通過使用者id，直接從redis中查詢資料出來，不就OK了？

如果在高併發的場景下，為了提升介面效能，遠端介面呼叫大概率會被去掉，而改成儲存冗餘資料的資料異構方案。

但需要注意的是，如果使用了資料異構方案，就可能會出現資料一致性問題。

使用者資訊、積分和成長值有更新的話，大部分情況下，會先更新到資料庫，然後同步到redis。但這種跨庫的操作，可能會導致兩邊資料不一致的情況產生。

4. 重複呼叫

重複呼叫在我們的日常工作程式碼中可以說隨處可見，但如果沒有控制好，會非常影響介面的效能。

不信，我們一起看看。

4.1 迴圈查資料庫

有時候，我們需要從指定的使用者集合中，查詢出有哪些是在資料庫中已經存在的。

實現程式碼可以這樣寫：

public List<User> queryUser(List<User> searchList) {
    if (CollectionUtils.isEmpty(searchList)) {
        return Collections.emptyList();
    }

    List<User> result = Lists.newArrayList();
    searchList.forEach(user -> result.add(userMapper.getUserById(user.getId())));
    return result;
}

這裡如果有50個使用者，則需要迴圈50次，去查詢資料庫。我們都知道，每查詢一次資料庫，就是一次遠端呼叫。

如果查詢50次資料庫，就有50次遠端呼叫，這是非常耗時的操作。

那麼，我們如何優化呢？

具體程式碼如下：

public List<User> queryUser(List<User> searchList) {
    if (CollectionUtils.isEmpty(searchList)) {
        return Collections.emptyList();
    }
    List<Long> ids = searchList.stream().map(User::getId).collect(Collectors.toList());
    return userMapper.getUserByIds(ids);
}

提供一個根據使用者id集合批量查詢使用者的介面，只遠端呼叫一次，就能查詢出所有的資料。

這裡有個需要注意的地方是：id集合的大小要做限制，最好一次不要請求太多的資料。要根據實際情況而定，建議控制每次請求的記錄條數在500以內。

4.2 死迴圈

有些小夥伴看到這個標題，可能會感到有點意外，死迴圈也算？

程式碼中不是應該避免死迴圈嗎？為啥還是會產生死迴圈？

有時候死迴圈是我們自己寫的，例如下面這段程式碼：

while(true) {
    if(condition) {
        break;
    }
    System.out.println("do samething");
}

這裡使用了while(true)的迴圈呼叫，這種寫法在CAS自旋鎖中使用比較多。

當滿足 condition (條件) 等於true的時候，則自動退出該迴圈。

如果 condition (條件) 條件非常複雜，一旦出現判斷不正確，或者少寫了一些邏輯判斷，就可能在某些場景下出現死迴圈的問題。

出現死迴圈，大概率是開發人員人為的 bug (臭蟲) 導致的，不過這種情況很容易被測出來。

還有一種隱藏的比較深的死迴圈，是由於程式碼寫的不太嚴謹導致的。如果用正常資料，可能測不出問題，但一旦出現異常資料，就會立即出現死迴圈。

4.3 無限遞迴

如果想要列印某個分類的所有父分類，可以用類似這樣的遞迴方法實現：

public void printCategory(Category category) {
  if(category == null 
      || category.getParentId() == null) {
     return;
  } 
  System.out.println("父分類名稱："+ category.getName());
  Category parent = categoryMapper.getCategoryById(category.getParentId());
  printCategory(parent);
}

正常情況下，這段程式碼是沒有問題的。

但如果某次有人誤操作，把某個分類的parentId指向了它自己，這樣就會出現無限遞迴的情況。導致介面一直不能返回資料，最終會發生堆疊溢位。

建議寫遞迴方法時，設定一個遞迴的深度，比如：分類最大等級有4級，則深度可以設定為4。然後在遞迴方法中做判斷，如果深度大於4時，則自動返回，這樣就能避免無限迴圈的情況。

5. 非同步處理

有時候，我們介面效能優化，需要重新梳理一下業務邏輯，看看是否有設計上不太合理的地方。

比如有個使用者請求介面中，需要做業務操作，發站內通知，和記錄操作日誌。為了實現起來比較方便，通常我們會將這些邏輯放在介面中同步執行，勢必會對介面效能造成一定的影響。

介面內部流程圖如下：這個介面表面上看起來沒有問題，但如果你仔細梳理一下業務邏輯，會發現只有業務操作才是核心邏輯，其他的功能都是非核心邏輯。

在這裡有個原則就是：核心邏輯可以同步執行，同步寫庫。非核心邏輯，可以非同步執行，非同步寫庫。

上面這個例子中，發站內通知和使用者操作日誌功能，對實時性要求不高，即使晚點寫庫，使用者無非是晚點收到站內通知，或者運營晚點看到使用者操作日誌，對業務影響不大，所以完全可以非同步處理。

通常非同步主要有兩種：多執行緒 和 mq。

5.1 執行緒池

使用執行緒池改造之後，介面邏輯如下：發站內通知和使用者操作日誌功能，被提交到了兩個單獨的執行緒池中。

這樣介面中重點關注的是業務操作，把其他的邏輯交給執行緒非同步執行，這樣改造之後，讓介面效能瞬間提升了。

但使用執行緒池有個小問題就是：如果伺服器重啟了，或者是需要被執行的功能出現異常了，無法重試，會丟資料。

那麼這個問題該怎麼辦呢？

5.2 mq

使用mq改造之後，介面邏輯如下：對於發站內通知和使用者操作日誌功能，在介面中並沒真正實現，它只發送了mq訊息到mq伺服器。然後由mq消費者消費訊息時，才真正的執行這兩個功能。

這樣改造之後，介面效能同樣提升了，因為傳送mq訊息速度是很快的，我們只需關注業務操作的程式碼即可。

6. 避免大事務

很多小夥伴在使用spring框架開發專案時，為了方便，喜歡使用@Transactional註解提供事務功能。

沒錯，使用@Transactional註解這種宣告式事務的方式提供事務功能，確實能少寫很多程式碼，提升開發效率。

但也容易造成大事務，引發其他的問題。

下面用一張圖看看大事務引發的問題。從圖中能夠看出，大事務問題可能會造成介面超時，對介面的效能有直接的影響。

我們該如何優化大事務呢？

少用@Transactional註解
將查詢( select (選擇) )方法放到事務外
事務中避免遠端呼叫
事務中避免一次性處理太多資料
有些功能可以非事務執行
有些功能可以非同步處理

關於大事務問題我的另一篇文章《讓人頭痛的大事務問題到底要如何解決？》，它裡面做了非常詳細的介紹，如果大家感興趣可以看看。

7. 鎖粒度

在某些業務場景中，為了防止多個執行緒併發修改某個共享資料，造成資料異常。

為了解決併發場景下，多個執行緒同時修改資料，造成資料不一致的情況。通常情況下，我們會：加鎖。

但如果鎖加得不好，導致鎖的粒度太粗，也會非常影響介面效能。

7.1 synchronized

在java中提供了synchronized關鍵字給我們的程式碼加鎖。

通常有兩種寫法：在方法上加鎖 和 在程式碼塊上加鎖。

先看看如何在方法上加鎖：

public synchronized doSave(String fileUrl) {
    mkdir();
    uploadFile(fileUrl);
    sendMessage(fileUrl);
}

這裡加鎖的目的是為了防止併發的情況下，建立了相同的目錄，第二次會建立失敗，影響業務功能。

但這種直接在方法上加鎖，鎖的粒度有點粗。因為doSave方法中的上傳檔案和發訊息方法，是不需要加鎖的。只有建立目錄方法，才需要加鎖。

我們都知道檔案上傳操作是非常耗時的，如果將整個方法加鎖，那麼需要等到整個方法執行完之後才能釋放鎖。顯然，這會導致該方法的效能很差，變得得不償失。

這時，我們可以改成在程式碼塊上加鎖了，具體程式碼如下：

public void doSave(String path,String fileUrl) {
    synchronized(this) {
      if(!exists(path)) {
          mkdir(path);
       }
    }
    uploadFile(fileUrl);
    sendMessage(fileUrl);
}

這樣改造之後，鎖的粒度一下子變小了，只有併發建立目錄功能才加了鎖。而建立目錄是一個非常快的操作，即使加鎖對介面的效能影響也不大。

最重要的是，其他的上傳檔案和傳送訊息功能，任然可以併發執行。

當然，這種做在單機版的服務中，是沒有問題的。但現在部署的生產環境，為了保證服務的穩定性，一般情況下，同一個服務會被部署在多個節點中。如果哪天掛了一個節點，其他的節點服務任然可用。

多節點部署避免了因為某個節點掛了，導致服務不可用的情況。同時也能分攤整個系統的流量，避免系統壓力過大。

同時它也帶來了新的問題：synchronized只能保證一個節點加鎖是有效的，但如果有多個節點如何加鎖呢?

答：這就需要使用：分散式鎖了。目前主流的分散式鎖包括：redis分散式鎖、zookeeper分散式鎖和資料庫分散式鎖。

由於zookeeper分散式鎖的效能不太好，真實業務場景用的不多，這裡先不講。

下面聊一下redis分散式鎖。

7.2 redis分散式鎖

在分散式系統中，由於redis分散式鎖相對於更簡單和高效，成為了分散式鎖的首先，被我們用到了很多實際業務場景當中。

使用redis分散式鎖的虛擬碼如下：

public void doSave(String path,String fileUrl) {
  try {
    String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
    if ("OK".equals(result)) {
      if(!exists(path)) {
         mkdir(path);
         uploadFile(fileUrl);
         sendMessage(fileUrl);
      }
      return true;
    }
  } finally{
      unlock(lockKey,requestId);
  }  
  return false;
}

跟之前使用synchronized關鍵字加鎖時一樣，這裡鎖的範圍也太大了，換句話說就是鎖的粒度太粗，這樣會導致整個方法的執行效率很低。

其實只有建立目錄的時候，才需要加分散式鎖，其餘程式碼根本不用加鎖。

於是，我們需要優化一下程式碼：

public void doSave(String path,String fileUrl) {
   if(this.tryLock()) {
      mkdir(path);
   }
   uploadFile(fileUrl);
   sendMessage(fileUrl);
}

private boolean tryLock() {
    try {
    String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
    if ("OK".equals(result)) {
      return true;
    }
  } finally{
      unlock(lockKey,requestId);
  }  
  return false;
}

上面程式碼將加鎖的範圍縮小了，只有建立目錄時才加了鎖。這樣看似簡單的優化之後，介面效能能提升很多。說不定，會有意外的驚喜喔。哈哈哈。

redis分散式鎖雖說好用，但它在使用時，有很多注意的細節，隱藏了很多坑，如果稍不注意很容易踩中。詳細內容可以看看我的另一篇文章《聊聊redis分散式鎖的8大坑》

7.3 資料庫分散式鎖

mysql資料庫中主要有三種鎖：

表鎖：加鎖快，不會出現死鎖。但鎖定粒度大，發生鎖衝突的概率最高，併發度最低。
行鎖：加鎖慢，會出現死鎖。但鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。
間隙鎖：開銷和加鎖時間界於表鎖和行鎖之間。它會出現死鎖，鎖定粒度界於表鎖和行鎖之間，併發度一般。

併發度越高，意味著介面效能越好。

所以資料庫鎖的優化方向是：

優先使用行鎖，其次使用間隙鎖，再其次使用表鎖。

趕緊看看，你用對了沒？

8.分頁處理

有時候我會呼叫某個介面批量查詢資料，比如：通過使用者id批量查詢出使用者資訊，然後給這些使用者送積分。

但如果你一次性查詢的使用者數量太多了，比如一次查詢2000個使用者的資料。引數中傳入了2000個使用者的id，遠端呼叫介面，會發現該使用者查詢介面經常超時。

呼叫程式碼如下：

List<User> users = remoteCallUser(ids);

眾所周知，呼叫介面從資料庫獲取資料，是需要經過網路傳輸的。如果資料量太大，無論是獲取資料的速度，還是網路傳輸受限於頻寬，都會導致耗時時間比較長。

那麼，這種情況要如何優化呢？

答：分頁處理。

將一次獲取所有的資料的請求，改成分多次獲取，每次只獲取一部分使用者的資料，最後進行合併和彙總。

其實，處理這個問題，要分為兩種場景：同步呼叫 和 非同步呼叫。

8.1 同步呼叫

如果在job中需要獲取2000個使用者的資訊，它要求只要能正確獲取到資料就好，對獲取資料的總耗時要求不太高。

但對每一次遠端介面呼叫的耗時有要求，不能大於500ms，不然會有郵件預警。

這時，我們可以同步分頁呼叫批量查詢使用者資訊介面。

具體示例程式碼如下：

List<List<Long>> allIds = Lists.partition(ids,200);

for(List<Long> batchIds:allIds) {
   List<User> users = remoteCallUser(batchIds);
}

程式碼中我用的google的guava工具中的Lists.partition方法，用它來做分頁簡直太好用了，不然要巴拉巴拉寫一大堆分頁的程式碼。

8.2 非同步呼叫

如果是在某個介面中需要獲取2000個使用者的資訊，它考慮的就需要更多一些。

除了需要考慮遠端呼叫介面的耗時之外，還需要考慮該介面本身的總耗時，也不能超時500ms。

這時候用上面的同步分頁請求遠端介面，肯定是行不通的。

那麼，只能使用非同步呼叫了。

程式碼如下：

List<List<Long>> allIds = Lists.partition(ids,200);

final List<User> result = Lists.newArrayList();
allIds.stream().forEach((batchIds) -> {
   CompletableFuture.supplyAsync(() -> {
        result.addAll(remoteCallUser(batchIds));
        return Boolean.TRUE;
    }, executor);
})

使用CompletableFuture類，多個執行緒非同步呼叫遠端介面，最後彙總結果統一返回。

9.加快取

解決介面效能問題，加快取是一個非常高效的方法。

但不能為了快取而快取，還是要看具體的業務場景。畢竟加了快取，會導致介面的複雜度增加，它會帶來資料不一致問題。

在有些併發量比較低的場景中，比如使用者下單，可以不用加快取。

還有些場景，比如在商城首頁顯示商品分類的地方，假設這裡的分類是呼叫介面獲取到的資料，但頁面暫時沒有做靜態化。

如果查詢分類樹的介面沒有使用快取，而直接從資料庫查詢資料，效能會非常差。

那麼如何使用快取呢？

9.1 redis快取

通常情況下，我們使用最多的快取可能是：redis和memcached。

但對於java應用來說，絕大多數都是使用的redis，所以接下來我們以redis為例。

由於在關係型資料庫，比如：mysql中，選單是有上下級關係的。某個四級分類是某個三級分類的子分類，這個三級分類，又是某個二級分類的子分類，而這個二級分類，又是某個一級分類的子分類。

這種儲存結構決定了，想一次性查出這個分類樹，並非是一件非常容易的事情。這就需要使用程式遞迴查詢了，如果分類多的話，這個遞迴是比較耗時的。

所以，如果每次都直接從資料庫中查詢分類樹的資料，是一個非常耗時的操作。

這時我們可以使用快取，大部分情況，介面都直接從快取中獲取資料。操作redis可以使用成熟的框架，比如：jedis和redisson等。

用jedis虛擬碼如下：

String json = jedis.get(key);
if(StringUtils.isNotEmpty(json)) {
   CategoryTree categoryTree = JsonUtil.toObject(json);
   return categoryTree;
}
return queryCategoryTreeFromDb();

先從redis中根據某個key查詢是否有選單資料，如果有則轉換成物件，直接返回。如果redis中沒有查到選單資料，則再從資料庫中查詢選單資料，有則返回。

此外，我們還需要有個job每隔一段時間，從資料庫中查詢選單資料，更新到redis當中，這樣以後每次都能直接從redis中獲取選單的資料，而無需訪問資料庫了。這樣改造之後，能快速的提升效能。

但這樣做效能提升不是最佳的，還有其他的方案，我們一起看看下面的內容。

9.2 二級快取

上面的方案是基於redis快取的，雖說redis訪問速度很快。但畢竟是一個遠端呼叫，而且選單樹的資料很多，在網路傳輸的過程中，是有些耗時的。

有沒有辦法，不經過請求遠端，就能直接獲取到資料呢？

答：使用二級快取，即基於記憶體的快取。

除了自己手寫的記憶體快取之後，目前使用比較多的記憶體快取框架有：guava、Ehcache、caffine等。

我們在這裡以caffeine為例，它是spring官方推薦的。

第一步，引入caffeine的相關 jar (罐子) 包

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>2.6.0</version>
</dependency>

第二步，配置CacheManager，開啟EnableCaching

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public CacheManager cacheManager(){
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        //Caffeine配置
        Caffeine<Object, Object> caffeine = Caffeine.newBuilder()
                //最後一次寫入後經過固定時間過期
                .expireAfterWrite(10, TimeUnit.SECONDS)
                //快取的最大條數
                .maximumSize(1000);
        cacheManager.setCaffeine(caffeine);
        return cacheManager;
    }
}

第三步，使用Cacheable註解獲取資料

@Service
public class CategoryService {
   
   @Cacheable(value = "category", key = "#categoryKey")
   public CategoryModel getCategory(String categoryKey) {
      String json = jedis.get(categoryKey);
      if(StringUtils.isNotEmpty(json)) {
         CategoryTree categoryTree = JsonUtil.toObject(json);
         return categoryTree;
      }
      return queryCategoryTreeFromDb();
   }
}

呼叫categoryService.getCategory()方法時，先從caffine快取中獲取資料，如果能夠獲取到資料，則直接返回該資料，不進入方法體。

如果不能獲取到資料，則再從redis中查一次資料。如果查詢到了，則返回資料，並且放入caffine中。

如果還是沒有查到資料，則直接從資料庫中獲取到資料，然後放到caffine快取中。

具體流程圖如下：該方案的效能更好，但有個缺點就是，如果資料更新了，不能及時重新整理快取。此外，如果有多臺伺服器節點，可能存在各個節點上資料不一樣的情況。

由此可見，二級快取給我們帶來效能提升的同時，也帶來了資料不一致的問題。使用二級快取一定要結合實際的業務場景，並非所有的業務場景都適用。

但上面我列舉的分類場景，是適合使用二級快取的。因為它屬於使用者不敏感資料，即使出現了稍微有點資料不一致也沒有關係，使用者有可能都沒有察覺出來。

10. 分庫分表

有時候，介面效能受限的不是別的，而是資料庫。

當系統發展到一定的階段，使用者併發量大，會有大量的資料庫請求，需要佔用大量的資料庫連線，同時會帶來磁碟IO的效能瓶頸問題。

此外，隨著使用者數量越來越多，產生的資料也越來越多，一張表有可能存不下。由於資料量太大，sql語句查詢資料時，即使走了索引也會非常耗時。

這時該怎麼辦呢？

答：需要做分庫分表。

如下圖所示：圖中將使用者庫拆分成了三個庫，每個庫都包含了四張使用者表。

如果有使用者請求過來的時候，先根據使用者id路由到其中一個使用者庫，然後再定位到某張表。

路由的演算法挺多的：

根據id取模，比如：id=7，有4張表，則7%4=3，模為3，路由到使用者表3。
給id指定一個區間範圍，比如：id的值是0-10萬，則資料存在使用者表0，id的值是10-20萬，則資料存在使用者表1。
一致性hash演算法

分庫分表主要有兩個方向：垂直和水平。

說實話垂直方向（即業務方向）更簡單。

在水平方向（即資料方向）上，分庫和分表的作用，其實是有區別的，不能混為一談。

分庫：是為了解決資料庫連線資源不足問題，和磁碟IO的效能瓶頸問題。
分表：是為了解決單表資料量太大，sql語句查詢資料時，即使走了索引也非常耗時問題。此外還可以解決消耗cpu資源問題。
分庫分表：可以解決資料庫連線資源不足、磁碟IO的效能瓶頸、檢索資料耗時和消耗cpu資源等問題。

如果在有些業務場景中，使用者併發量很大，但是需要儲存的資料量很少，這時可以只分庫，不分表。

如果在有些業務場景中，使用者併發量不大，但是需要儲存的數量很多，這時可以只分表，不分庫。

如果在有些業務場景中，使用者併發量大，並且需要儲存的數量也很多時，可以分庫分表。

關於分庫分表更詳細的內容，可以看看我另一篇文章，裡面講的更深入《阿里二面：為什麼分庫分表？》

11. 輔助功能

優化介面效能問題，除了上面提到的這些常用方法之外，還需要配合使用一些輔助功能，因為它們真的可以幫我們提升查詢問題的效率。

11.1 開啟慢查詢日誌

通常情況下，為了定位sql的效能瓶頸，我們需要開啟mysql的慢查詢日誌。把超過指定時間的sql語句，單獨記錄下來，方面以後分析和定位問題。

開啟慢查詢日誌需要重點關注三個引數：

slow_query_log 慢查詢開關
slow_query_log_file 慢查詢日誌存放的路徑
long_query_time 超過多少秒才會記錄日誌

通過mysql的set命令可以設定：

set global slow_query_log='ON'; 
set global slow_query_log_file='/usr/local/mysql/data/slow.log';
set global long_query_time=2;

設定完之後，如果某條sql的執行時間超過了2秒，會被自動記錄到slow. log (日誌) 檔案中。

當然也可以直接修改配置檔案my.cnf

[mysqld]
slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log
long_query_time = 2

但這種方式需要重啟mysql服務。

很多公司每天早上都會發一封慢查詢日誌的郵件，開發人員根據這些資訊優化sql。

11.2 加監控

為了出現sql問題時，能夠讓我們及時發現，我們需要對系統做監控。

目前業界使用比較多的開源監控系統是：Prometheus。

它提供了 監控 和 預警 的功能。

架構圖如下：

我們可以用它監控如下資訊：

介面響應時間
呼叫第三方服務耗時
慢查詢sql耗時
cpu使用情況
記憶體使用情況
磁碟使用情況
資料庫使用情況

等等。。。

它的介面大概長這樣子：可以看到mysql當前qps，活躍執行緒數，連線數，快取池的大小等資訊。

如果發現數據量連線池佔用太多，對介面的效能肯定會有影響。

這時可能是程式碼中開啟了連線忘了關，或者併發量太大了導致的，需要做進一步排查和系統優化。

截圖中只是它一小部分功能，如果你想了解更多功能，可以訪問Prometheus的官網：https://prometheus.io/

11.3 鏈路跟蹤

有時候某個介面涉及的邏輯很多，比如：查資料庫、查redis、遠端呼叫介面，發mq訊息，執行業務程式碼等等。

該介面一次請求的鏈路很長，如果逐一排查，需要花費大量的時間，這時候，我們已經沒法用傳統的辦法定位問題了。

有沒有辦法解決這問題呢？

用分散式鏈路跟蹤系統：skywalking。

架構圖如下：通過skywalking定位效能問題：在skywalking中可以通過traceId（全域性唯一的id），串聯一個介面請求的完整鏈路。可以看到整個介面的耗時，呼叫的遠端服務的耗時，訪問資料庫或者redis的耗時等等，功能非常強大。

之前沒有這個功能的時候，為了定位線上介面效能問題，我們還需要在程式碼中加日誌，手動打印出鏈路中各個環節的耗時情況，然後再逐一排查。

如果你用過skywalking排查介面效能問題，不自覺的會愛上它的。如果你想了解更多功能，可以訪問skywalking的官網：https://skywalking.apache.org/

此文章是以為微信作者寫的，我只是覺得文章乾貨多自己儲存一下，如果想了解更多的，關注一下這個大佬吧原文連結

注：【蘇三說技術】

關注公眾號：【蘇三說技術】，在公眾號中回覆：面試、程式碼神器、開發手冊、時間管理有超讚的粉絲福利，另外回覆：加群，可以跟很多BAT大廠的前輩交流和學習。