高并發(fā)技巧之Redis和本地緩存使用技巧分享
眾所周知,緩存最主要的目的就是加速訪問,緩解數(shù)據(jù)庫壓力。最常用的緩存就是分布式緩存,比如redis,在面對大部分并發(fā)場景或者一些中小型公司流量沒有那么高的情況,使用redis基本都能解決了。但是在流量較高的情況下可能得使用到本地緩存了,比如guava的LoadingCache和快手開源的ReloadableCache。
三種緩存的使用場景
這部分會介紹redis,比如guava的LoadingCache和快手開源的ReloadableCache的使用場景和局限,通過這一部分的介紹就能知道在怎樣的業(yè)務場景下應該使用哪種緩存,以及為什么。
Redis的使用場景和局限性
如果寬泛的說redis何時使用,那么自然就是用戶訪問量過高的地方使用,從而加速訪問,并且緩解數(shù)據(jù)庫壓力。如果細分的話,還得分為單節(jié)點問題和非單節(jié)點問題。
如果一個頁面用戶訪問量比較高,但是訪問的不是同一個資源。比如用戶詳情頁,訪問量比較高,但是每個用戶的數(shù)據(jù)都是不一樣的,這種情況顯然只能用分布式緩存了,如果使用redis,key為用戶唯一鍵,value則是用戶信息。
redis導致的緩存擊穿。
但是需要注意一點,一定要設置過期時間,而且不能設置到同一時間點過期。舉個例子,比如用戶又個活動頁,活動頁能看到用戶活動期間獲獎數(shù)據(jù),粗心的人可能會設置用戶數(shù)據(jù)的過期時間點為活動結(jié)束,這樣會
單(熱)點問題
單節(jié)點問題說的是redis的單個節(jié)點的并發(fā)問題,因為對于相同的key會落到redis集群的同一個節(jié)點上,那么如果對這個key的訪問量過高,那么這個redis節(jié)點就存在并發(fā)隱患,這個key就稱為熱key。
如果所有用戶訪問的都是同一個資源,比如小愛同學app首頁對所有用戶展示的內(nèi)容都一樣(初期),服務端給h5返回的是同一個大json,顯然得使用到緩存。首先我們考慮下用redis是否可行,由于redis存在單點問題,如果流量過大的話,那么所有用戶的請求到達redis的同一個節(jié)點,需要評估該節(jié)點能否抗住這么大流量。我們的規(guī)則是,如果單節(jié)點qps達到了千級別就要解決單點問題了(即使redis號稱能抗住十萬級別的qps),最常見的做法就是使用本地緩存。顯然小愛app首頁流量不過百,使用redis是沒問題的。
LoadingCache的使用場景和局限性
對于這上面說的熱key問題,我們最直接的做法就是使用本地緩存,比如你最熟悉的guava的LoadingCache,但是使用本地緩存要求能夠接受一定的臟數(shù)據(jù),因為如果你更新了首頁,本地緩存是不會更新的,它只會根據(jù)一定的過期策略來重新加載緩存,不過在我們這個場景是完全沒問題的,因為一旦在后臺推送了首頁后就不會再去改變了。即使改變了也沒問題,可以設置寫過期為半小時,超過半小時重新加載緩存,這種短時間內(nèi)的臟數(shù)據(jù)我們是可以接受的。
LoadingCache導致的緩存擊穿
雖然說本地緩存和機器上強相關(guān)的,雖然代碼層面寫的是半小時過期,但由于每臺機器的啟動時間不同,導致緩存的加載時間不同,過期時間也就不同,也就不會所有機器上的請求在同一時間緩存失效后都去請求數(shù)據(jù)庫。但是對于單一一臺機器也是會導致緩存穿透的,假如有10臺機器,每臺1000的qps,只要有一臺緩存過期就可能導致這1000個請求同時打到了數(shù)據(jù)庫。這種問題其實比較好解決,但是容易被忽略,也就是在設置LoadingCache的時候使用LoadingCache的load-miss方法,而不是直接判斷cache.getIfPresent()== null然后去請求db;前者會加虛擬機層面的鎖,保證只有一個請求打到數(shù)據(jù)庫去,從而完美的解決了這個問題。
但是,如果對于實時性要求較高的情況,比如有段時間要經(jīng)常做活動,我要保證活動頁面能近實時更新,也就是運營在后臺配置好了活動信息后,需要在C端近實時展示這次配置的活動信息,此時使用LoadingCache肯定就不能滿足了。
ReloadableCache的使用場景和局限性
對于上面說的LoadingCache不能解決的實時問題,可以考慮使用ReloadableCache,這是快手開源的一個本地緩存框架,最大的特點是支持多機器同時更新緩存,假設我們修改了首頁信息,然后請求打到的是A機器,這個時候重新加載ReloadableCache,然后它會發(fā)出通知,監(jiān)聽了同一zk節(jié)點的其他機器收到通知后重新更新緩存。使用這個緩存一般的要求是將全量數(shù)據(jù)加載到本地緩存,所以如果數(shù)據(jù)量過大肯定會對gc造成壓力,這種情況就不能使用了。由于小愛同學首頁這個首頁是帶有狀態(tài)的,一般online狀態(tài)的就那么兩個,所以完全可以使用ReloadableCache來只裝載online狀態(tài)的首頁。
小結(jié)
到這里三種緩存基本都介紹完了,做個小結(jié):
- 對于非熱點的數(shù)據(jù)訪問,比如用戶維度的數(shù)據(jù),直接使用redis即可;
- 對于熱點數(shù)據(jù)的訪問,如果流量不是很高,無腦使用redis即可;
- 對于熱點數(shù)據(jù),如果允許一定時間內(nèi)的臟數(shù)據(jù),使用LoadingCache即可;
- 對于熱點數(shù)據(jù),如果一致性要求較高,同時數(shù)據(jù)量不大的情況,使用ReloadableCache即可;
小技巧
不管哪種本地緩存雖然都帶有虛擬機層面的加鎖來解決擊穿問題,但是意外總有可能以你意想不到的方式發(fā)生,保險起見你可以使用兩級緩存的方式即本地緩存+redis+db。
緩存使用的簡單介紹
這里redis的使用就不再多說了,相信很多人對api的使用比我還熟悉
LoadingCache的使用
這個是guava提供的網(wǎng)上一抓一大把,但是給兩點注意事項
- 要使用load-miss的話, 要么使用
V get(K key, Callable<? extends V> loader);要么使用build的時候使用的是build(CacheLoader<? super K1, V1> loader)這個時候可以直接使用get()了。此外建議使用load-miss,而不是getIfPresent==null的時候再去查數(shù)據(jù)庫,這可能導致緩存擊穿; - 使用load-miss是因為這是線程安全的,如果緩存失效的話,多個線程調(diào)用get的時候只會有一個線程去db查詢,其他線程需要等待,也就是說這是線程安全的。
LoadingCache<String, String> cache = CacheBuilder.newBuilder()
.maximumSize(1000L)
.expireAfterAccess(Duration.ofHours(1L)) // 多久不訪問就過期
.expireAfterWrite(Duration.ofHours(1L)) // 多久這個key沒修改就過期
.build(new CacheLoader<String, String>() {
@Override
public String load(String key) throws Exception {
// 數(shù)據(jù)裝載方式,一般就是loadDB
return key + " world";
}
});
String value = cache.get("hello"); // 返回hello world
reloadableCache的使用
導入三方依賴
<dependency> <groupId>com.github.phantomthief</groupId> <artifactId>zknotify-cache</artifactId> <version>0.1.22</version> </dependency>
需要看文檔,不然無法使用,有興趣自己寫一個也行的。
public interface ReloadableCache<T> extends Supplier<T> {
/**
* 獲取緩存數(shù)據(jù)
*/
@Override
T get();
/**
* 通知全局緩存更新
* 注意:如果本地緩存沒有初始化,本方法并不會初始化本地緩存并重新加載
*
* 如果需要初始化本地緩存,請先調(diào)用 {@link ReloadableCache#get()}
*/
void reload();
/**
* 更新本地緩存的本地副本
* 注意:如果本地緩存沒有初始化,本方法并不會初始化并刷新本地的緩存
*
* 如果需要初始化本地緩存,請先調(diào)用 {@link ReloadableCache#get()}
*/
void reloadLocal();
}老生常談的緩存擊穿/穿透/雪崩問題
這三個真的是亙古不變的問題,如果流量大確實需要考慮。
緩存擊穿
簡單說就是緩存失效,導致大量請求同一時間打到了數(shù)據(jù)庫。對于緩存擊穿問題上面已經(jīng)給出了很多解決方案了。
- 比如使用本地緩存
- 本地緩存使用load-miss方法
- 使用第三方服務來加載緩存
1.2和都說過,主要來看3。假如業(yè)務愿意只能使用redis而無法使用本地緩存,比如數(shù)據(jù)量過大,實時性要求比較高。那么當緩存失效的時候就得想辦法保證只有少量的請求打到數(shù)據(jù)庫。很自然的就想到了使用分布式鎖,理論上說是可行的,但實際上存在隱患。我們的分布式鎖相信很多人都是使用redis+lua的方式實現(xiàn)的,并且在while中進行了輪訓,這樣請求量大,數(shù)據(jù)多的話會導致無形中讓redis成了隱患,并且占了太多業(yè)務線程,其實僅僅是引入了分布式鎖就加大了復雜度,我們的原則就是能不用就不用。
那么我們是不是可以設計一個類似分布式鎖,但是更可靠的rpc服務呢?當調(diào)用get方法的時候這個rpc服務保證相同的key打到同一個節(jié)點,并且使用synchronized來進行加鎖,之后完成數(shù)據(jù)的加載。在快手提供了一個叫cacheSetter的框架。下面提供一個簡易版,自己寫也很容易實現(xiàn)。
import com.google.common.collect.Lists;
import org.apache.commons.collections4.CollectionUtils;
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.CountDownLatch;
/**
* @Description 分布式加載緩存的rpc服務,如果部署了多臺機器那么調(diào)用端最好使用id做一致性hash保證相同id的請求打到同一臺機器。
**/
public abstract class AbstractCacheSetterService implements CacheSetterService {
private final ConcurrentMap<String, CountDownLatch> loadCache = new ConcurrentHashMap<>();
private final Object lock = new Object();
@Override
public void load(Collection<String> needLoadIds) {
if (CollectionUtils.isEmpty(needLoadIds)) {
return;
}
CountDownLatch latch;
Collection<CountDownLatch> loadingLatchList;
synchronized (lock) {
loadingLatchList = excludeLoadingIds(needLoadIds);
needLoadIds = Collections.unmodifiableCollection(needLoadIds);
latch = saveLatch(needLoadIds);
}
System.out.println("needLoadIds:" + needLoadIds);
try {
if (CollectionUtils.isNotEmpty(needLoadIds)) {
loadCache(needLoadIds);
}
} finally {
release(needLoadIds, latch);
block(loadingLatchList);
}
}
/**
* 加鎖
* @param loadingLatchList 需要加鎖的id對應的CountDownLatch
*/
protected void block(Collection<CountDownLatch> loadingLatchList) {
if (CollectionUtils.isEmpty(loadingLatchList)) {
return;
}
System.out.println("block:" + loadingLatchList);
loadingLatchList.forEach(l -> {
try {
l.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
/**
* 釋放鎖
* @param needLoadIds 需要釋放鎖的id集合
* @param latch 通過該CountDownLatch來釋放鎖
*/
private void release(Collection<String> needLoadIds, CountDownLatch latch) {
if (CollectionUtils.isEmpty(needLoadIds)) {
return;
}
synchronized (lock) {
needLoadIds.forEach(id -> loadCache.remove(id));
}
if (latch != null) {
latch.countDown();
}
}
/**
* 加載緩存,比如根據(jù)id從db查詢數(shù)據(jù),然后設置到redis中
* @param needLoadIds 加載緩存的id集合
*/
protected abstract void loadCache(Collection<String> needLoadIds);
/**
* 對需要加載緩存的id綁定CountDownLatch,后續(xù)相同的id請求來了從map中找到CountDownLatch,并且await,直到該線程加載完了緩存
* @param needLoadIds 能夠正在去加載緩存的id集合
* @return 公用的CountDownLatch
*/
protected CountDownLatch saveLatch(Collection<String> needLoadIds) {
if (CollectionUtils.isEmpty(needLoadIds)) {
return null;
}
CountDownLatch latch = new CountDownLatch(1);
needLoadIds.forEach(loadId -> loadCache.put(loadId, latch));
System.out.println("loadCache:" + loadCache);
return latch;
}
/**
* 哪些id正在加載數(shù)據(jù),此時持有相同id的線程需要等待
* @param ids 需要加載緩存的id集合
* @return 正在加載的id所對應的CountDownLatch集合
*/
private Collection<CountDownLatch> excludeLoadingIds(Collection<String> ids) {
List<CountDownLatch> loadingLatchList = Lists.newArrayList();
Iterator<String> iterator = ids.iterator();
while (iterator.hasNext()) {
String id = iterator.next();
CountDownLatch latch = loadCache.get(id);
if (latch != null) {
loadingLatchList.add(latch);
iterator.remove();
}
}
System.out.println("loadingLatchList:" + loadingLatchList);
return loadingLatchList;
}
}業(yè)務實現(xiàn)
import java.util.Collection;
public class BizCacheSetterRpcService extends AbstractCacheSetterService {
@Override
protected void loadCache(Collection<String> needLoadIds) {
// 讀取db進行處理
// 設置緩存
}
}
緩存穿透
簡單來說就是請求的數(shù)據(jù)在數(shù)據(jù)庫不存在,導致無效請求打穿數(shù)據(jù)庫。
解法也很簡單,從db獲取數(shù)據(jù)的方法(getByKey(K key))一定要給個默認值。
比如我有個獎池,金額上限是1W,用戶完成任務的時候給他發(fā)筆錢,并且使用redis記錄下來,并且落表,用戶在任務頁面能實時看到獎池剩余金額,在任務開始的時候顯然獎池金額是不變的,redis和db里面都沒有發(fā)放金額的記錄,這就導致每次必然都去查db,對于這種情況,從db沒查出來數(shù)據(jù)應該緩存?zhèn)€值0到緩存。
緩存雪崩
就是大量緩存集中失效打到了db,當然肯定都是一類的業(yè)務緩存,歸根到底是代碼寫的有問題??梢詫⒕彺媸У倪^期時間打散,別讓其集中失效就可以了。
以上就是高并發(fā)技巧之Redis和本地緩存使用技巧分享的詳細內(nèi)容,更多關(guān)于Redis本地緩存的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
基于Redis緩存數(shù)據(jù)常見的三種問題及解決
這篇文章主要介紹了基于Redis緩存數(shù)據(jù)常見的三種問題及解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-06-06
Redis實現(xiàn)每日簽到功能(大數(shù)據(jù)量)
在面對百萬級用戶簽到情況下,傳統(tǒng)數(shù)據(jù)庫存儲和判斷會遇到瓶頸,使用Redis的二進制數(shù)據(jù)類型可實現(xiàn)高效的簽到功能,示例代碼展示了如何調(diào)用這些功能,包括當天簽到、補簽以及查詢簽到記錄,PHP結(jié)合Redis二進制數(shù)據(jù)類型可有效處理大數(shù)據(jù)量下的簽到問題2024-10-10

