分布式緩存系統(tǒng)可用的方案有很多種，幫助APP直播源碼應(yīng)對各種場景下的難題，在選擇方案時，平臺也需要考慮到自己實際的應(yīng)用情況，不僅是方案是否能滿足平臺需求，還有后續(xù)使用時，能否穩(wěn)定流暢。

?

一、Memcached

嚴(yán)格來說，它并不能算是分布式緩存系統(tǒng)的一種，更傾向于將其看成一個單機的緩存系統(tǒng)，所以從各個方面來說，其容量是有上限的。好處在于其是開源的，訪問協(xié)議也是公開的，所以目前很多三方客戶端或擴展，在一定程度上為集群擴展做了支持。

另外，由于memcached內(nèi)部通過固定大小的鏈去管理內(nèi)存數(shù)據(jù)，分配和回收效率很高，所以讀寫性能都很高。

壞處在于，memcached集群的不同機器之間是獨立的，沒有數(shù)據(jù)方面的通信，當(dāng)APP直播源碼發(fā)生數(shù)據(jù)傾斜時，無法自動調(diào)整。

?

二、Redis

屬于APP直播源碼很常用的緩存系統(tǒng)，Redis除了可以像mamcached那樣支持普通類型的存儲外，還支持list、map、set等集群類型的存儲，這種特性在業(yè)務(wù)開發(fā)中很方便。

Redis源生支持持久化存儲，但APP直播源碼并不能太依靠這個集群，一旦使用持久化后，性能就會快速下降。

Redis支持集群，當(dāng)主機宕機時，可以快速切換到備機，和MySQL主備模式差不多，但不能算是分布式系統(tǒng)。另外在擴展上，目前Redis沒法給APP直播源碼提供成熟的方案，只能通過主備同步的模式進(jìn)行擴展數(shù)據(jù)遷移。

?

三、內(nèi)存數(shù)據(jù)庫

主要指的是關(guān)系型內(nèi)存數(shù)據(jù)庫，一般APP直播源碼使用時可以分為兩個情況：

1、對數(shù)據(jù)計算實時性要求高時，是基于APP直播源碼磁盤的數(shù)據(jù)庫很難處理，同時又要依賴關(guān)系型數(shù)據(jù)庫的一些特性，這種數(shù)據(jù)一般是臨時的數(shù)據(jù)，使用周期較短，計算完成或者進(jìn)程結(jié)束就可丟棄。

2、數(shù)據(jù)的訪問量較大，但數(shù)據(jù)量不大，這樣即便是丟失也可以很快從持久化存儲中把數(shù)據(jù)加載到內(nèi)存里。

但不管是哪個場景，存在于內(nèi)存數(shù)據(jù)庫中的數(shù)據(jù)都必須是相對獨立或者只服務(wù)于讀請求的，這樣APP直播源碼可以跳過復(fù)雜的數(shù)據(jù)同步處理。

聲明：以上內(nèi)容為云豹科技作者本人原創(chuàng)，未經(jīng)作者本人同意，禁止轉(zhuǎn)載，否則將追究相關(guān)法律責(zé)任