本文內容參考網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解常見的分散式技術、以及一些較為常見的分散式系統概念，同時也需要進一步瞭解zookeeper、分散式事務、分散式鎖、負載均衡等技術，以便讓你更完整地瞭解分散式技術的具體實戰方法，為真正應用分散式技術做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

# 快取和它的那些淘汰演算法們

為什麼我們需要快取？

很久很久以前，在還沒有快取的時候……使用者經常是去請求一個物件，而這個物件是從資料庫去取，然後，這個物件變得越來越大，這個使用者每次的請求時間也越來越長了，這也把資料庫弄得很痛苦，他無時不刻不在工作。所以，這個事情就把使用者和資料庫弄得很生氣，接著就有可能發生下面兩件事情：

１.使用者很煩，在抱怨，甚至不去用這個應用了（這是大多數情況下都會發生的）

２.資料庫為打包回家，離開這個應用，然後，就出現了麻煩（沒地方去儲存資料了）（發生在極少數情況下）

上帝派來了快取

在幾年之後，IBM（60年代）的研究人員引進了一個新概念，它叫“快取”。

什麼是快取？

正如開篇所講，快取是“存貯資料（使用頻繁的資料）的臨時地方，因為取原始資料的代價太大了，所以我可以取得快一些。”

快取可以認為是資料的池，這些資料是從資料庫裡的真實資料複製出來的，並且為了能正確取回，被標上了標籤（鍵 ID）。太棒了

programmer one 已經知道這點了，但是他還不知道下面的快取術語。

![cache訪問流程](https://user-gold-cdn.xitu.io/2017/10/25/49e480c480199d7da14f7f3853858292?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)

命中：

當客戶發起一個請求（我們說他想要檢視一個產品資訊），我們的應用接受這個請求，並且如果是在第一次檢查快取的時候，需要去資料庫讀取產品資訊。

如果在快取中，一個條目透過一個標記被找到了，這個條目就會被使用、我們就叫它快取命中。所以，命中率也就不難理解了。

Cache Miss：

但是這裡需要注意兩點：

１.　如果還有快取的空間，那麼，沒有命中的物件會被儲存到快取中來。

２.　如果快取滿了，而又沒有命中快取，那麼就會按照某一種策略，把快取中的舊物件踢出，而把新的物件加入快取池。而這些策略統稱為替代策略（快取演算法），這些策略會決定到底應該提出哪些物件。

儲存成本：

當沒有命中時，我們會從資料庫取出資料，然後放入快取。而把這個資料放入快取所需要的時間和空間，就是儲存成本。

索引成本：

和儲存成本相仿。

失效：

當存在快取中的資料需要更新時，就意味著快取中的這個資料失效了。

替代策略：

當快取沒有命中時，並且快取容量已經滿了，就需要在快取中踢出一個老的條目，加入一條新的條目，而到底應該踢出什麼條目，就由替代策略決定。

最優替代策略：

最優的替代策略就是想把快取中最沒用的條目給踢出去，但是未來是不能夠被預知的，所以這種策略是不可能實現的。但是有很多策略，都是朝著這個目前去努力。

快取演算法

沒有人能說清哪種快取演算法優於其他的快取演算法

Least Frequently Used（LFU）：

大家好，我是 LFU，我會計算為每個快取物件計算他們被使用的頻率。我會把最不常用的快取物件踢走。

Least Recently User（LRU）：

我是 LRU 快取演算法，我把最近最少使用的快取物件給踢走。

我總是需要去了解在什麼時候，用了哪個快取物件。如果有人想要了解我為什麼總能把最近最少使用的物件踢掉，是非常困難的。

瀏覽器就是使用了我（LRU）作為快取演算法。新的物件會被放在快取的頂部，當快取達到了容量極限，我會把底部的物件踢走，而技巧就是：我會把最新被訪問的快取物件，放到快取池的頂部。

所以，經常被讀取的快取物件就會一直呆在快取池中。有兩種方法可以實現我，array 或者是 linked list。

我的速度很快，我也可以被資料訪問模式適配。我有一個大家庭，他們都可以完善我，甚至做的比我更好（我確實有時會嫉妒，但是沒關係）。我家庭的一些成員包括 LRU2 和 2Q，他們就是為了完善 LRU 而存在的。

First in First out（FIFO）：

我是先進先出，我是一個低負載的演算法，並且對快取物件的管理要求不高。我透過一個佇列去跟蹤所有的快取物件，最近最常用的快取物件放在後面，而更早的快取物件放在前面，當快取容量滿時，排在前面的快取物件會被踢走，然後把新的快取物件加進去。我很快，但是我並不適用。

Second Chance：

大家好，我是 second chance，我是透過 FIFO 修改而來的，被大家叫做 second chance 快取演算法，我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一樣也是在觀察佇列的前端，但是很FIFO的立刻踢出不同，我會檢查即將要被踢出的物件有沒有之前被使用過的標誌（1一個 bit 表示），沒有被使用過，我就把他踢出；否則，我會把這個標誌位清除，然後把這個快取物件當做新增快取物件加入佇列。你可以想象就這就像一個環佇列。當我再一次在隊頭碰到這個物件時，由於他已經沒有這個標誌位了，所以我立刻就把他踢開了。我在速度上比 FIFO 快。

其他的快取演算法還考慮到了下面幾點：

成本：如果快取物件有不同的成本，應該把那些難以獲得的物件儲存下來。

容量：如果快取物件有不同的大小，應該把那些大的快取物件清除，這樣就可以讓更多的小快取物件進來了。

時間：一些快取還儲存著快取的過期時間。電腦會失效他們，因為他們已經過期了。

根據快取物件的大小而不管其他的快取演算法可能是有必要的。

看看快取元素（快取實體）

public class CacheElement
     {
         private Object objectValue;
         private Object objectKey;
         private int index;
         private int hitCount;　// getters and setters
     }

這個快取實體擁有快取的key和value，這個實體的資料結構會被以下所有快取演算法用到。

快取演算法的公用程式碼

public final synchronized void addElement(Object key, Object value)
     {
         int index;
         Object obj;
         // get the entry from the table
         obj = table.get(key);
         // If we have the entry already in our table
         // then get it and replace only its value.
         obj = table.get(key);
     
         if (obj != null)
         {
             CacheElement element;
             element = (CacheElement) obj;
             element.setObjectValue(value);
             element.setObjectKey(key);
             return;
         }
     ｝

上面的程式碼會被所有的快取演算法實現用到。這段程式碼是用來檢查快取元素是否在快取中了，如果是，我們就替換它，但是如果我們找不到這個 key 對應的快取，我們會怎麼做呢？那我們就來深入的看看會發生什麼吧！

現場訪問

今天的專題很特殊，因為我們有特殊的客人，事實上他們是我們想要聽的與會者，但是首先，先介紹一下我們的客人：Random Cache，FIFO Cache。讓我們從 Random Cache開始。

看看隨機快取的實現

public final synchronized void addElement(Object key, Object value)
     {
         int index;
         Object obj;
         obj = table.get(key);
         if (obj != null)
         {
             CacheElement element;// Just replace the value.
             element = (CacheElement) obj;
             element.setObjectValue(value);
             element.setObjectKey(key);
             return;
         }// If we haven't filled the cache yet, put it at the end.
         if (!isFull())
         {
             index = numEntries;
             ++numEntries;
         }
         else { // Otherwise, replace a random entry.
             index = (int) (cache.length * random.nextFloat());
             table.remove(cache[index].getObjectKey());
         }
         cache[index].setObjectValue(value);
         cache[index].setObjectKey(key);
         table.put(key, cache[index]);
     }

看看FIFO緩演算法的實現

public final synchronized void addElement(Objectkey, Object value)
     {
         int index;
         Object obj;
         obj = table.get(key);
         if (obj != null)
         {
             CacheElement element; // Just replace the value.
             element = (CacheElement) obj;
             element.setObjectValue(value);
             element.setObjectKey(key);
             return;
         }
         // If we haven't filled the cache yet, put it at the end.
         if (!isFull())
         {
             index = numEntries;
             ++numEntries;
         }
         else { // Otherwise, replace the current pointer,
                // entry with the new one.
             index = current;
             // in order to make Circular FIFO
             if (++current >= cache.length)
                 current = 0;
             table.remove(cache[index].getObjectKey());
         }
         cache[index].setObjectValue(value);
         cache[index].setObjectKey(key);
         table.put(key, cache[index]);
     }

看看LFU快取演算法的實現

public synchronized Object getElement(Object key)
     {
         Object obj;
         obj = table.get(key);
         if (obj != null)
         {
             CacheElement element = (CacheElement) obj;
             element.setHitCount(element.getHitCount() + 1);
             return element.getObjectValue();
         }
         return null;
     }
     public final synchronized void addElement(Object key, Object value)
     {
         Object obj;
         obj = table.get(key);
         if (obj != null)
         {
             CacheElement element; // Just replace the value.
             element = (CacheElement) obj;
             element.setObjectValue(value);
             element.setObjectKey(key);
             return;
         }
         if (!isFull())
         {
             index = numEntries;
             ++numEntries;
         }
         else
         {
             CacheElement element = removeLfuElement();
             index = element.getIndex();
             table.remove(element.getObjectKey());
         }
         cache[index].setObjectValue(value);
         cache[index].setObjectKey(key);
         cache[index].setIndex(index);
         table.put(key, cache[index]);
     }
     public CacheElement removeLfuElement()
     {
         CacheElement[] elements = getElementsFromTable();
         CacheElement leastElement = leastHit(elements);
         return leastElement;
     }
     public static CacheElement leastHit(CacheElement[] elements)
     {
         CacheElement lowestElement = null;
         for (int i = 0; i < elements.length; i++)
         {
             CacheElement element = elements[i];
             if (lowestElement == null)
             {
                 lowestElement = element;
             }
             else {
                 if (element.getHitCount() < lowestElement.getHitCount())
                 {
                     lowestElement = element;
                 }
             }
         }
         return lowestElement;
     }

最重點的程式碼，就應該是 leastHit 這個方法，這段程式碼就是把hitCount 最低的元素找出來，然後刪除，給新進的快取元素留位置

看看LRU快取演算法實現

private void moveToFront(int index)
     {
         int nextIndex, prevIndex;
         if(head != index)
         {
             nextIndex = next[index];
             prevIndex = prev[index];
             // Only the head has a prev entry that is an invalid index
             // so we don't check.
             next[prevIndex] = nextIndex;
             // Make sure index is valid. If it isn't, we're at the tail
             // and don't set prev[next].
             if(nextIndex >= 0)
                 prev[nextIndex] = prevIndex;
             else
                 tail = prevIndex;
             prev[index] = -1;
             next[index] = head;
             prev[head] = index;
             head = index;
         }
     }
     public final synchronized void addElement(Object key, Object value)
     {
         int index;Object obj;
         obj = table.get(key);
         if(obj != null)
         {
             CacheElement entry;
             // Just replace the value, but move it to the front.
             entry = (CacheElement)obj;
             entry.setObjectValue(value);
             entry.setObjectKey(key);
             moveToFront(entry.getIndex());
             return;
         }
         // If we haven't filled the cache yet, place in next available
         // spot and move to front.
         if(!isFull())
         {
             if(_numEntries > 0)
             {
                 prev[_numEntries] = tail;
                 next[_numEntries] = -1;
                 moveToFront(numEntries);
             }
             ++numEntries;
         }
         else { // We replace the tail of the list.
             table.remove(cache[tail].getObjectKey());
             moveToFront(tail);
         }
         cache[head].setObjectValue(value);
         cache[head].setObjectKey(key);
         table.put(key, cache[head]);
     }

這段程式碼的邏輯如 LRU演算法 的描述一樣，把再次用到的快取提取到最前面，而每次刪除的都是最後面的元素。

# 快取技術雜談

一般而言，現在網際網路應用（網站或App）的整體流程，可以概括如圖1所示，使用者請求從介面（瀏覽器或App介面）到網路轉發、應用服務再到儲存（資料庫或檔案系統），然後返回到介面呈現內容。

隨著網際網路的普及，內容資訊越來越複雜，使用者數和訪問量越來越大，我們的應用需要支撐更多的併發量，同時我們的應用伺服器和資料庫伺服器所做的計算也越來越多。但是往往我們的應用伺服器資源是有限的，且技術變革是緩慢的，資料庫每秒能接受的請求次數也是有限的（或者檔案的讀寫也是有限的），如何能夠有效利用有限的資源來提供儘可能大的吞吐量？一個有效的辦法就是引入快取，打破標準流程，每個環節中請求可以從快取中直接獲取目標資料並返回，從而減少計算量，有效提升響應速度，讓有限的資源服務更多的使用者。

# 快取特徵

快取也是一個資料模型物件，那麼必然有它的一些特徵：

#### 命中率

命中率=返回正確結果數/請求快取次數，命中率問題是快取中的一個非常重要的問題，它是衡量快取有效性的重要指標。命中率越高，表明快取的使用率越高。

#### 最大元素（或最大空間）

快取中可以存放的最大元素的數量，一旦快取中元素數量超過這個值（或者快取資料所佔空間超過其最大支援空間），那麼將會觸發快取啟動清空策略根據不同的場景合理的設定最大元素值往往可以一定程度上提高快取的命中率，從而更有效的時候快取。

#### 清空策略

如上描述，快取的儲存空間有限制，當快取空間被用滿時，如何保證在穩定服務的同時有效提升命中率？這就由快取清空策略來處理，設計適合自身資料特徵的清空策略能有效提升命中率。常見的一般策略有：

*   FIFO(first in first out)

先進先出策略，最先進入快取的資料在快取空間不夠的情況下（超出最大元素限制）會被優先被清除掉，以騰出新的空間接受新的資料。策略演算法主要比較快取元素的建立時間。在資料實效性要求場景下可選擇該類策略，優先保障最新資料可用。

*   LFU(less frequently used)

最少使用策略，無論是否過期，根據元素的被使用次數判斷，清除使用次數較少的元素釋放空間。策略演算法主要比較元素的hitCount（命中次數）。在保證高頻資料有效性場景下，可選擇這類策略。

*   LRU(least recently used)

最近最少使用策略，無論是否過期，根據元素最後一次被使用的時間戳，清除最遠使用時間戳的元素釋放空間。策略演算法主要比較元素最近一次被get使用時間。在熱點資料場景下較適用，優先保證熱點資料的有效性。

除此之外，還有一些簡單策略比如：

*   根據過期時間判斷，清理過期時間最長的元素；
*   根據過期時間判斷，清理最近要過期的元素；
*   隨機清理；
*   根據關鍵字（或元素內容）長短清理等。

# 快取介質

雖然從硬體介質上來看，無非就是記憶體和硬碟兩種，但從技術上，可以分成記憶體、硬碟檔案、資料庫。

*   記憶體：將快取儲存於記憶體中是最快的選擇，無需額外的I/O開銷，但是記憶體的缺點是沒有持久化落地物理磁碟，一旦應用異常break down而重新啟動，資料很難或者無法復原。
*   硬碟：一般來說，很多快取框架會結合使用記憶體和硬碟，在記憶體分配空間滿了或是在異常的情況下，可以被動或主動的將記憶體空間資料持久化到硬碟中，達到釋放空間或備份資料的目的。
*   資料庫：前面有提到，增加快取的策略的目的之一就是為了減少資料庫的I/O壓力。現在使用資料庫做快取介質是不是又回到了老問題上了？其實，資料庫也有很多種型別，像那些不支援SQL，只是簡單的key-value儲存結構的特殊資料庫（如BerkeleyDB和Redis），響應速度和吞吐量都遠遠高於我們常用的關係型資料庫等。

# 快取分類和應用場景

快取有各類特徵，而且有不同介質的區別，那麼實際工程中我們怎麼去對快取分類呢？在目前的應用服務框架中，比較常見的，時根據快取雨應用的藕合度，分為local cache（本地快取）和remote cache（分散式快取）：

本地快取：指的是在應用中的快取元件，其最大的優點是應用和cache是在同一個程式內部，請求快取非常快速，沒有過多的網路開銷等，在單應用不需要叢集支援或者叢集情況下各節點無需互相通知的場景下使用本地快取較合適；同時，它的缺點也是應為快取跟應用程式耦合，多個應用程式無法直接的共享快取，各應用或叢集的各節點都需要維護自己的單獨快取，對記憶體是一種浪費。

分散式快取：指的是與應用分離的快取元件或服務，其最大的優點是自身就是一個獨立的應用，與本地應用隔離，多個應用可直接的共享快取。

目前各種型別的快取都活躍在成千上萬的應用服務中，還沒有一種快取方案可以解決一切的業務場景或資料型別，我們需要根據自身的特殊場景和背景，選擇最適合的快取方案。快取的使用是程式設計師、架構師的必備技能，好的程式設計師能根據資料型別、業務場景來準確判斷使用何種型別的快取，如何使用這種快取，以最小的成本最快的效率達到最優的目的。

## 本地快取

### 程式設計直接實現快取

個別場景下，我們只需要簡單的快取資料的功能，而無需關注更多存取、清空策略等深入的特性時，直接程式設計實現快取則是最便捷和高效的。

a. 成員變數或區域性變數實現

簡單程式碼示例如下：

public void UseLocalCache(){
         //一個本地的快取變數
         Map<string object=""> localCacheStoreMap = new HashMap<string object="">();
     
        List<object> infosList = this.getInfoList();
        for(Object item:infosList){
            if(localCacheStoreMap.containsKey(item)){ //快取命中 使用快取資料
                // todo
            } else { // 快取未命中  IO獲取資料，結果存入快取
                Object valueObject = this.getInfoFromDB();
                localCacheStoreMap.put(valueObject.toString(), valueObject);
     
            }
        }
    }
    //示例
    private List<object> getInfoList(){
        return new ArrayList<object>();
    }
    //示例資料庫IO獲取
    private Object getInfoFromDB(){
        return new Object();
    }

以區域性變數map結構快取部分業務資料，減少頻繁的重複資料庫I/O操作。缺點僅限於類的自身作用域內，類間無法共享快取。

b. 靜態變數實現

最常用的單例實現靜態資源快取，程式碼示例如下：
    
          public class CityUtils {
          private static final HttpClient httpClient = ServerHolder.createClientWithPool(); 
          private static Map<integer string=""> cityIdNameMap = new HashMap<integer string="">();
          private static Map<integer string=""> districtIdNameMap = new HashMap<integer string="">();
     
      static {
        HttpGet get = new HttpGet("http://gis-in.sankuai.com/api/location/city/all");
        BaseAuthorizationUtils.generateAuthAndDateHeader(get,
                BaseAuthorizationUtils.CLIENT_TO_REQUEST_MDC,
                BaseAuthorizationUtils.SECRET_TO_REQUEST_MDC);
        try {
            String resultStr = httpClient.execute(get, new BasicResponseHandler());
            JSONObject resultJo = new JSONObject(resultStr);
            JSONArray dataJa = resultJo.getJSONArray("data");
            for (int i = 0; i < dataJa.length(); i++) {
                JSONObject itemJo = dataJa.getJSONObject(i);
                cityIdNameMap.put(itemJo.getInt("id"), itemJo.getString("name"));
            }
        } catch (Exception e) {
            throw new RuntimeException("Init City List Error!", e);
        }
    }
        static {
        HttpGet get = new HttpGet("http://gis-in.sankuai.com/api/location/district/all");
        BaseAuthorizationUtils.generateAuthAndDateHeader(get,
                BaseAuthorizationUtils.CLIENT_TO_REQUEST_MDC,
                BaseAuthorizationUtils.SECRET_TO_REQUEST_MDC);
        try {
            String resultStr = httpClient.execute(get, new BasicResponseHandler());
            JSONObject resultJo = new JSONObject(resultStr);
            JSONArray dataJa = resultJo.getJSONArray("data");
            for (int i = 0; i < dataJa.length(); i++) {
                JSONObject itemJo = dataJa.getJSONObject(i);
                districtIdNameMap.put(itemJo.getInt("id"), itemJo.getString("name"));
            }
        } catch (Exception e) {
            throw new RuntimeException("Init District List Error!", e);
        }
    }
     
        public static String getCityName(int cityId) {
          String name = cityIdNameMap.get(cityId);
          if (name == null) {
            name = "未知";
          }
           return name;
         }
     
        public static String getDistrictName(int districtId) {
          String name = districtIdNameMap.get(districtId);
           if (name == null) {
             name = "未知";
            }
           return name;
         }
       }

O2O業務中常用的城市基礎基本資訊判斷，透過靜態變數一次獲取快取記憶體中，減少頻繁的I/O讀取，靜態變數實現類間可共享，程式內可共享，快取的實時性稍差。

> 這類快取實現，優點是能直接在heap區內讀寫，最快也最方便；缺點同樣是受heap區域影響，快取的資料量非常有限，同時快取時間受GC影響。主要滿足單機場景下的小資料量快取需求，同時對快取資料的變更無需太敏感感知，如上一般配置管理、基礎靜態資料等場景。

### Ehcache

Ehcache是現在最流行的純Java開源快取框架，配置簡單、結構清晰、功能強大，是一個非常輕量級的快取實現，我們常用的Hibernate裡面就整合了相關快取功能。

![](https://tech.meituan.com/img/cache_about/ehcach%E6%A1%86%E6%9E%B6%E5%9B%BE.png)

主要特性：

*   快速，針對大型高併發系統場景，Ehcache的多執行緒機制有相應的最佳化改善。
*   簡單，很小的jar包，簡單配置就可直接使用，單機場景下無需過多的其他服務依賴。
*   支援多種的快取策略，靈活。
*   快取資料有兩級：記憶體和磁碟，與一般的本地記憶體快取相比，有了磁碟的儲存空間，將可以支援更大量的資料快取需求。
*   具有快取和快取管理器的偵聽介面，能更簡單方便的進行快取例項的監控管理。
*   支援多快取管理器例項，以及一個例項的多個快取區域。

> 注意：Ehcache的超時設定主要是針對整個cache例項設定整體的超時策略，而沒有較好的處理針對單獨的key的個性的超時設定（有策略設定，但是比較複雜，就不描述了），因此，在使用中要注意過期失效的快取元素無法被GC回收，時間越長快取越多，記憶體佔用也就越大，記憶體洩露的機率也越大。

## 分散式快取

### memcached快取

memcached是應用較廣的開源分散式快取產品之一，它本身其實不提供分散式解決方案。在服務端，memcached叢集環境實際就是一個個memcached伺服器的堆積，環境搭建較為簡單；cache的分散式主要是在客戶端實現，透過客戶端的路由處理來達到分散式解決方案的目的。客戶端做路由的原理非常簡單，應用伺服器在每次存取某key的value時，透過某種演算法把key對映到某臺memcached伺服器nodeA上。

無特殊場景下，key-value能滿足需求的前提下，使用memcached分散式叢集是較好的選擇，搭建與操作使用都比較簡單；分散式叢集在單點故障時，隻影響小部分資料異常，目前還可以透過Magent快取代理模式，做單點備份，提升高可用；整個快取都是基於記憶體的，因此響應時間是很快，不需要額外的序列化、反序列化的程式，但同時由於基於記憶體，資料沒有持久化，叢集故障重啟資料無法恢復。高版本的memcached已經支援CAS模式的原子操作，可以低成本的解決併發控制問題。

### Redis快取

Redis是一個遠端記憶體資料庫（非關係型資料庫），效能強勁，具有複製特性以及解決問題而生的獨一無二的資料模型。它可以儲存鍵值對與5種不同型別的值之間的對映，可以將儲存在記憶體的鍵值對資料持久化到硬碟，可以使用複製特性來擴充套件讀效能，還可以使用客戶端分片來擴充套件寫效能。

個人總結了以下多種Web應用場景，在這些場景下可以充分的利用Redis的特性，大大提高效率。

*   在主頁中顯示最新的專案列表：Redis使用的是常駐記憶體的快取，速度非常快。LPUSH用來插入一個內容ID，作為關鍵字儲存在列表頭部。LTRIM用來限制列表中的專案數最多為5000。如果使用者需要的檢索的資料量超越這個快取容量，這時才需要把請求傳送到資料庫。
*   刪除和過濾：如果一篇文章被刪除，可以使用LREM從快取中徹底清除掉。
*   排行榜及相關問題：排行榜（leader board）按照得分進行排序。ZADD命令可以直接實現這個功能，而ZREVRANGE命令可以用來按照得分來獲取前100名的使用者，ZRANK可以用來獲取使用者排名，非常直接而且操作容易。
*   按照使用者投票和時間排序：排行榜，得分會隨著時間變化。LPUSH和LTRIM命令結合運用，把文章新增到一個列表中。一項後臺任務用來獲取列表，並重新計算列表的排序，ZADD命令用來按照新的順序填充生成列表。列表可以實現非常快速的檢索，即使是負載很重的站點。
*   過期專案處理：使用Unix時間作為關鍵字，用來保持列表能夠按時間排序。對current_time和time_to_live進行檢索，完成查詢過期專案的艱鉅任務。另一項後臺任務使用ZRANGE…WITHSCORES進行查詢，刪除過期的條目。
*   計數：進行各種資料統計的用途是非常廣泛的，比如想知道什麼時候封鎖一個IP地址。INCRBY命令讓這些變得很容易，透過原子遞增保持計數；GETSET用來重置計數器；過期屬性用來確認一個關鍵字什麼時候應該刪除。
*   特定時間內的特定專案：這是特定訪問者的問題，可以透過給每次頁面瀏覽使用SADD命令來解決。SADD不會將已經存在的成員新增到一個集合。
*   Pub/Sub：在更新中保持使用者對資料的對映是系統中的一個普遍任務。Redis的pub/sub功能使用了SUBSCRIBE、UNSUBSCRIBE和PUBLISH命令，讓這個變得更加容易。
*   佇列：在當前的程式設計中佇列隨處可見。除了push和pop型別的命令之外，Redis還有阻塞佇列的命令，能夠讓一個程式在執行時被另一個程式新增到佇列。

# 快取常見問題

前面一節說到了《[為什麼說Redis是單執行緒的以及Redis為什麼這麼快！](http://blog.csdn.net/u010870518/article/details/79470556)》，今天給大家整理一篇關於Redis經常被問到的問題：快取雪崩、快取穿透、快取預熱、快取更新、快取降級等概念的入門及簡單解決方案。

## 一、快取雪崩

快取雪崩我們可以簡單的理解為：由於原有快取失效，新快取未到期間(例如：我們設定快取時採用了相同的過期時間，在同一時刻出現大面積的快取過期)，所有原本應該訪問快取的請求都去查詢資料庫了，而對資料庫CPU和記憶體造成巨大壓力，嚴重的會造成資料庫當機。從而形成一系列連鎖反應，造成整個系統崩潰。

快取正常從Redis中獲取，示意圖如下：

![這裡寫圖片描述](https://img-blog.csdn.net/20180312200437182?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdTAxMDg3MDUxOA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)

快取失效瞬間示意圖如下：

![這裡寫圖片描述](https://img-blog.csdn.net/20180312200640916?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdTAxMDg3MDUxOA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)

快取失效時的雪崩效應對底層系統的衝擊非常可怕！大多數系統設計者考慮用加鎖或者佇列的方式保證來保證不會有大量的執行緒對資料庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層儲存系統上。還有一個簡單方案就時講快取失效時間分散開，比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。

以下簡單介紹兩種實現方式的虛擬碼：

（1）碰到這種情況，一般併發量不是特別多的時候，使用最多的解決方案是加鎖排隊，虛擬碼如下：

//虛擬碼
    public object GetProductListNew() {
        int cacheTime = 30;
        String cacheKey = "product_list";
        String lockKey = cacheKey;
     
        String cacheValue = CacheHelper.get(cacheKey);
        if (cacheValue != null) {
            return cacheValue;
        } else {
            synchronized(lockKey) {
                cacheValue = CacheHelper.get(cacheKey);
                if (cacheValue != null) {
                    return cacheValue;
                } else {
                    //這裡一般是sql查詢資料
                    cacheValue = GetProductListFromDB(); 
                    CacheHelper.Add(cacheKey, cacheValue, cacheTime);
                }
            }
            return cacheValue;
        }
    }

加鎖排隊只是為了減輕資料庫的壓力，並沒有提高系統吞吐量。假設在高併發下，快取重建期間key是鎖著的，這是過來1000個請求999個都在阻塞的。同樣會導致使用者等待超時，這是個治標不治本的方法！

注意：加鎖排隊的解決方式分散式環境的併發問題，有可能還要解決分散式鎖的問題；執行緒還會被阻塞，使用者體驗很差！因此，在真正的高併發場景下很少使用！

（2）還有一個解決辦法解決方案是：給每一個快取資料增加相應的快取標記，記錄快取的是否失效，如果快取標記失效，則更新資料快取，例項虛擬碼如下：

//虛擬碼
    public object GetProductListNew() {
        int cacheTime = 30;
        String cacheKey = "product_list";
        //快取標記
        String cacheSign = cacheKey + "_sign";
     
        String sign = CacheHelper.Get(cacheSign);
        //獲取快取值
        String cacheValue = CacheHelper.Get(cacheKey);
        if (sign != null) {
            return cacheValue; //未過期，直接返回
        } else {
            CacheHelper.Add(cacheSign, "1", cacheTime);
            ThreadPool.QueueUserWorkItem((arg) -> {
                //這裡一般是 sql查詢資料
                cacheValue = GetProductListFromDB(); 
                //日期設快取時間的2倍，用於髒讀
                CacheHelper.Add(cacheKey, cacheValue, cacheTime * 2);                 
            });
            return cacheValue;
        }
    }

解釋說明：

1、快取標記：記錄快取資料是否過期，如果過期會觸發通知另外的執行緒在後臺去更新實際key的快取；

2、快取資料：它的過期時間比快取標記的時間延長1倍，例：標記快取時間30分鐘，資料快取設定為60分鐘。 這樣，當快取標記key過期後，實際快取還能把舊資料返回給呼叫端，直到另外的執行緒在後臺更新完成後，才會返回新快取。

關於快取崩潰的解決方法，這裡提出了三種方案：使用鎖或佇列、設定過期標誌更新快取、為key設定不同的快取失效時間，還有一各被稱為“二級快取”的解決方法，有興趣的讀者可以自行研究。

## 二、快取穿透

快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。

有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到一個足夠大的bitmap中，一個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。

另外也有一個更為簡單粗暴的方法，如果一個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。透過這個直接設定的預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴！

//虛擬碼
    public object GetProductListNew() {
        int cacheTime = 30;
        String cacheKey = "product_list";
     
        String cacheValue = CacheHelper.Get(cacheKey);
        if (cacheValue != null) {
            return cacheValue;
        }
     
        cacheValue = CacheHelper.Get(cacheKey);
        if (cacheValue != null) {
            return cacheValue;
        } else {
            //資料庫查詢不到，為空
            cacheValue = GetProductListFromDB();
            if (cacheValue == null) {
                //如果發現為空，設定個預設值，也快取起來
                cacheValue = string.Empty;
            }
            CacheHelper.Add(cacheKey, cacheValue, cacheTime);
            return cacheValue;
        }
    }

把空結果，也給快取起來，這樣下次同樣的請求就可以直接返回空了，即可以避免當查詢的值為空時引起的快取穿透。同時也可以單獨設定個快取區域儲存空值，對要查詢的key進行預先校驗，然後再放行給後面的正常快取處理邏輯。

## 三、快取預熱

快取預熱這個應該是一個比較常見的概念，相信很多小夥伴都應該可以很容易的理解，快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！

解決思路：

1、直接寫個快取重新整理頁面，上線時手工操作下；

2、資料量不大，可以在專案啟動的時候自動進行載入；

3、定時重新整理快取；

## 四、快取更新

除了快取伺服器自帶的快取失效策略之外（Redis預設的有6中策略可供選擇），我們還可以根據具體的業務需求進行自定義的快取淘汰，常見的策略有兩種：

（1）定時去清理過期的快取；

（2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。

兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜！具體用哪種方案，大家可以根據自己的應用場景來權衡。

## 五、快取降級

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。

降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日誌級別設定預案：

（1）一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；

（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，併傳送告警；

（3）錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

（4）嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。

## 六、總結

這些都是實際專案中，可能碰到的一些問題，也是面試的時候經常會被問到的知識點，實際上還有很多很多各種各樣的問題，文中的解決方案，也不可能滿足所有的場景，相對來說只是對該問題的入門解決方法。一般正式的業務場景往往要複雜的多，應用場景不同，方法和解決方案也不同，由於上述方案，考慮的問題並不是很全面，因此並不適用於正式的專案開發，但是可以作為概念理解入門，具體解決方案要根據實際情況來確定！</integer></integer></integer></integer></object></object></object></string></string>

搞懂分散式技術13：快取的那些事

相關文章