分布式緩存更新

❶ 數據共享屬於分布式緩存嗎

企業分布式緩存可以解決這些問題。 這種內存中存儲可跨越多個伺服器，將伺服器的內存集中在一塊，因而內存存儲容量是可擴展的。 事務容量也變得可擴展，添加的伺服器越多，能夠處理的事務負載越大。

企業分布式緩存還提供了事件通知機制，應用程序在更新數據後可以相互通知。 由此，您可以擁有非同步事件通知機制，其中一個應用程序生成數據，其他應用程序可以使用該數據，從而創建了生產者/使用者模型或發布/訂閱模型。 多個應用程序可訂閱某些數據類型，當該數據發布時這些應用程序將收到通知。

❷ 分布式緩存是什麼

分布式緩存使用CARP（Caching Array Routing Protocol）技術，可以產生一種高效率無接縫式的緩存，使用上讓多台緩存伺服器形同一台，並且不會造成數據重復存放的情況。
同時還有層次式緩存、動態緩存和計劃緩存三種。

❸ Redis分布式緩存搭建

花了兩天時間整理了之前記錄的Redis單體與哨兵模式的搭建與使用，又補齊了集群模式的使用和搭建經驗，並對集群的一些個原理做了理解。

筆者安裝中遇到的一些問題：

如果make報錯，可能是沒裝gcc或者gcc++編輯器，安裝之 yum -y install gcc gcc-c++ kernel-devel ，有可能還是提示一些個c文件編譯不過，gcc -v查看下版本，如果不到5.3那麼升級一下gcc：

在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable

scl enable devtoolset-9 bash

重新make clean, make

這回編譯通過了，提示讓你最好make test一下/

執行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test

那就升級tcl， yum install tcl

重新make test，如果還有error就刪了目錄，重新tar包解壓重新make , make test

o/ All tests passed without errors! ，表示編譯成功。

然後make install即可。

直接運行命令： ./redis-server /usr/redis-6.0.3/redis.conf &

redis.conf 配置文件里 bind 0.0.0.0 設置外部訪問， requirepass xxxx 設置密碼。

redis高可用方案有兩種：

常用搭建方案為1主1從或1主2從+3哨兵監控主節點， 以及3主3從6節點集群。

（1）sentinel哨兵

/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &

sentinel2.conf配置：

坑1：master節點也會在故障轉移後成為從節點，也需要配置masterauth

當kill master進程之後，經過sentinel選舉，slave成為了新的master，再次啟動原master，提示如下錯誤：

原因是此時的master再次啟動已經是slave了，需要向現在的新master輸入密碼，所以需要在master.conf
中配置：

坑2：哨兵配置文件要暴露客戶端可以訪問到的master地址

在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置該哨兵對應的master名字、master地址和埠，以及達到多少個哨兵選舉通過認為master掛掉。其中master地址要站在redis訪問者（也就是客戶端）的角度、配置訪問者能訪問的地址，例如sentinel與master在一台伺服器（122.xx.xxx.xxx）上，那麼相對sentinel其master在本機也就是127.0.0.1上，這樣 sentinel monitor mymaster 127.0.0.1 6379 2 邏輯上沒有問題，但是如果另外伺服器上的springboot通過lettuce訪問這個redis哨兵，則得到的master地址為127.0.0.1，也就是springboot所在伺服器本機，這顯然就有問題了。

附springboot2.1 redis哨兵配置：

坑3：要注意配置文件.conf會被哨兵修改

redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。

曾經遇到過這樣一個問題，大致的信息如下

slaves莫名其妙多了一個，master的地址也明明改了真實對外的地址，這里又變成127.0.0.1 !
最後，把5個redis進程都停掉，逐個檢查配置文件，發現redis的配置文件在主從哨兵模式會被修改，master的配置文件最後邊莫名其妙多了一行replicaof 127.0.0.1 7001， 懷疑應該是之前配置錯誤的時候（見坑2）被哨兵動態加上去的！ 總之，實踐中一定要多注意配置文件的變化。

（2）集群

當數據量大到一定程度，比如幾十上百G，哨兵模式不夠用了需要做水平拆分，早些年是使用codis，twemproxy這些第三方中間件來做分片的，即 客戶端 -> 中間件 -> Redis server 這樣的模式，中間件使用一致性Hash演算法來確定key在哪個分片上。後來Redis官方提供了方案，大家就都採用官方的Redis Cluster方案了。

Redis Cluster從邏輯上分16384個hash slot，分片演算法是 CRC16(key) mod 16384 得到key應該對應哪個slot，據此判斷這個slot屬於哪個節點。

每個節點可以設置1或多個從節點，常用的是3主節點3從節點的方案。

reshard，重新分片，可以指定從哪幾個節點移動一些hash槽到另一個節點去。重新分片的過程對客戶端透明，不影響線上業務。

搭建Redis cluster

redis.conf文件關鍵的幾個配置：

啟動6個集群節點

[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]

這時候這6個節點還是獨立的，要把他們配置成集群：

說明： -a xxxx 是因為筆者在redis.conf中配置了requirepass xxxx密碼，然後 --cluster-replicas 1 中的1表示每個master節點有1個從節點。

上述命令執行完以後會有一個詢問： Can I set the above configuration? yes同意自動做好的分片即可。

最後 All 16384 slots covered. 表示集群中16384個slot中的每一個都有至少有1個master節點在處理，集群啟動成功。

查看集群狀態：

坑1：暴露給客戶端的節點地址不對

使用lettuce連接發現連不上，查看日誌 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里邊配置master地址犯的錯誤一樣，集群啟動的時候帶的地址應該是提供給客戶端訪問的地址。

我們要重建集群：先把6個redis進程停掉，然後刪除 nodes-7001.conf 這些節點配置文件，刪除持久化文件 mp.rdb 、 appendonly.aof ，重新啟動6個進程，在重新建立集群：

然後，還是連不上，這次報錯 connection timed out: /172.xx.0.xx:7004 ，發現連到企鵝雲伺服器的內網地址上了！

解決辦法，修改每個節點的redis.conf配置文件，找到如下說明：

所以增加配置：

然後再重新構建集群，停進程、改配置、刪除節點文件和持久化文件、啟動進程、配置集群。。。再來一套（累死了）

重新使用Lettuce測試，這次終於連上了！

坑2：Lettuce客戶端在master節點故障時沒有自動切換到從節點

name這個key在7002上，kill這個進程模擬master下線，然後Lettuce一直重連。我們期望的是應該能自動切換到其slave 7006上去，如下圖：

重新啟動7002進程，

7006已成為新master，7002成為它的slave，然後Lettuce也能連接上了。
解決辦法，修改Lettuce的配置：

筆者用的是springboot 2.1 spring-boot-starter-data-redis 默認的Lettuce客戶端，當使用Redis cluster集群模式時，需要配置一下 RedisConnectionFactory 開啟自適應刷新來做故障轉移時的自動切換從節點進行連接。

重新測試：停掉master 7006，這次Lettuce可以正常切換連到7002slave上去了。（仍然會不斷的在日誌里報連接錯誤，因為需要一直嘗試重連7006，但因為有7002從節點頂上了、所以應用是可以正常使用的）

Redis不保證數據的強一致性

Redis並不保證數據的強一致性，也就是取CAP定理中的AP

關於一致性Hash演算法，可以參考 一致性Hash演算法 - (jianshu.com)

Redis cluster使用的是hash slot演算法，跟一致性Hash演算法不太一樣，固定16384個hash槽，然後計算key落在哪個slot里邊（計算key的CRC16值再對16384取模），key找的是slot而不是節點，而slot與節點的對應關系可以通過reshard改變並通過gossip協議擴散到集群中的每一個節點、進而可以為客戶端獲知，這樣key的節點定址就跟具體的節點個數沒關系了。也同樣解決了普通hash取模演算法當節點個數發生變化時，大量key對應的定址都發生改動導致緩存失效的問題。

比如集群增加了1個節點，這時候如果不做任何操作，那麼新增加的這個節點上是沒有slot的，所有slot都在原來的節點上且對應關系不變、所以沒有因為節點個數變動而緩存失效，當reshard一部分slot到新節點後，客戶端獲取到新遷移的這部分slot與新節點的對應關系、定址到新節點，而沒遷移的slot仍然定址到原來的節點。

關於熱遷移，猜想，內部應該是先做復制遷移，等遷移完了，再切換slot與節點的對應關系，復制沒有完成之前仍按照原來的slot與節點對應關系去原節點訪問。復制結束之後，再刪除原節點上已經遷移的slot所對應的key。

與哨兵模式比較類似，當1個節點發現某個master節點故障了、會對這個故障節點進行pfail主觀宕機，然後會通過gossip協議通知到集群中的其他節點、其他節點也執行判斷pfail並gossip擴散廣播這一過程，當超過半數節點pfail時那麼故障節點就是fail客觀宕機。接下來所有的master節點會在故障節點的從節點中選出一個新的主節點，此時所有的master節點中超過半數的都投票選舉了故障節點的某個從節點，那麼這個從節點當選新的master節點。

所有節點都持有元數據，節點之間通過gossip這種二進制協議進行通信、發送自己的元數據信息給其他節點、故障檢測、集群配置更新、故障轉移授權等等。

這種去中心化的分布式節點之間內部協調，包括故障識別、故障轉移、選主等等，核心在於gossip擴散協議，能夠支撐這樣的廣播協議在於所有的節點都持有一份完整的集群元數據，即所有的節點都知悉當前集群全局的情況。

Redis高可用方案 - (jianshu.com)

面試題:Redis 集群模式的工作原理能說一下么 - 雲+社區 - 騰訊雲 (tencent.com)

深度圖解Redis Cluster原理 - detectiveHLH - 博客園 (cnblogs.com)

Redis學習筆記之集群重啟和遇到的坑-阿里雲開發者社區 (aliyun.com)

雲伺服器Redis集群部署及客戶端通過公網IP連接問題

❹ Tair 分布式緩存簡介

Tair是由阿里巴巴自主研發的高性能高可用的分布式Key/Value結構數據存儲系統，在阿里內部有著大規模的應用。

作為一個分布式系統，Tair由一個中心控制節點（config server）和一系列的服務節點（data server）組成，

Tair主要有下面三種存儲引擎：

根據CAP理論，在分布式存儲系統中，最多隻能實現一致性、可靠性和分區容錯性三點中的兩點。而由於網路硬體肯定會出現延遲丟包等問題，所以分區容錯性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡。

Tair 選擇了一致性，同時採用復制技術來提高可靠性，並且為了提高效率做了一些優化。事實上在沒有錯誤發生的時候，tair 提供的是一種強一致性，但是在有data server發生故障的時候，客戶有可能在一定時間窗口內讀不到最新的數據，甚至發生最新數據丟失的情況。

Tair中的每個數據都包含版本號，版本號在每次更新後都會遞增。這個特性可以幫助防止數據的並發更新導致的問題。version 機制是樂觀鎖常用的實現方式。

tair 的存儲引擎可以是 MDB、LDB 或 RDB。它們使用緩存、內存或 SSD 硬碟（LDB） 來提升性能。

configserver 不是傳統的中心節點，掛了對集群的服務無影響

Tair 使用一致性哈希作為負載均衡策略。

當有某台data server故障不可用的時候， config server會發現這個情況， config server負責重新計算一張新的桶在data server上的分布表， 將原來由故障機器服務的桶的訪問重新指派到其它的data server中。這個時候， 可能會發生數據的遷移。比如原來由data server A負責的桶，在新表中需要由 B負責。而B上並沒有該桶的數據， 那麼就將數據遷移到B上來。同時config server會發現哪些桶的備份數目減少了， 然後根據負載情況在負載較低的data server上增加這些桶的備份。當系統增加data server的時候， config server根據負載，協調data server將他們控制的部分桶遷移到新的data server上。遷移完成後調整路由。當然系統中可能出現減少了某些data server 同時增加另外的一些data server。處理原理同上。 每次路由的變更，config server都會將新的配置信息推給data server。在客戶端訪問data server的時候， 會發送客戶端緩存的路由表的版本號。如果data server發現客戶端的版本號過舊，則會通知客戶端去config server取一次新的路由表。如果客戶端訪問某台data server 發生了不可達的情況(該 data server可能宕機了)，客戶端會主動去config server取新的路由表。

當遷移發生的時候， 我們舉個例子， 假設data server A 要把桶 3，4，5 遷移給data server B。因為遷移完成前，客戶端的路由表沒有變化，客戶端對 3， 4， 5 的訪問請求都會路由到A。現在假設 3還沒遷移， 4 正在遷移中， 5已經遷移完成。那麼如果是對3的訪問， 則沒什麼特別， 跟以前一樣。如果是對5的訪問， 則A會把該請求轉發給B，並且將B的返回結果返回給客戶，如果是對4的訪問，在A處理，同時如果是對4的修改操作會記錄修改log。當桶4遷移完成的時候，還要把log發送到B，在B上應用這些log。最終A B上對於桶4來說， 數據完全一致才是真正的遷移完成。當然如果是因為某data server宕機而引發的遷移， 客戶端會收到一張中間臨時狀態的分配表。這張表中，把宕機的data server所負責的桶臨時指派給有其備份data server來處理。 這個時候服務是可用的，但是負載可能不均衡。當遷移完成之後，才能重新達到一個新的負載均衡的狀態。

https://yq.aliyun.com/articles/52059

https://www.cnblogs.com/jiangxiulian/p/8027739.html

❺ 北大青鳥設計培訓：php應用中常用的9大緩存技術

一、全頁面靜態化緩存也就是將頁面全部生成html靜態頁面，用戶訪問時直接訪問的靜態頁面，而不會去走php伺服器解析的流程。
此種方式，在CMS系統中比較常見，比如dedecms；一種比較常用的實現方式是用輸出緩存：Ob_start()******要運行的代碼*******$content=Ob_get_contents();****將緩存內容寫入html文件*****Ob_end_clean();二、數據緩存顧名思義，就是緩存數據的一種方式；比如，商城中的某個商品信息，當用商品id去請求時，就會得出包括店鋪信息、商品信息等數據，此時就可以將這些數據緩存到一個php文件中，文件名包含商品id來建一個唯一標示；下一次有人想查看這個商品時，首先就直接調這個文件裡面的信息，而不用再去資料庫查詢；其實緩存文件中緩存的就是一個php數組之類；Ecmall商城系統裡面就用了這種方式；三、查詢緩存其實這跟數據緩存是一個思路，就是根據查詢語句來緩存；將查詢得到的數據緩存在一個文件中，下次遇到相同的查詢時，就直接先從這個文件裡面調數據，不會再去查資料庫；但此處的緩存文件名可能就需要以查詢語句為基點來建立唯一標示；按時間變更進行緩存就是對於緩存文件您需要設一個有效時間，在這個有效時間內，相同的訪問才會先取緩存文件的內容，但是超過設定的緩存時間，就需要重新從資料庫中獲取數據，並生產最新的緩存文件；比如，我將我們商城的首頁就是設置2個小時更新一次。
四、頁面部分緩存該種方式，是將一個頁面中不經常變的部分進行靜態緩存，而經常變化的塊不緩存，最後組裝在一起顯示；可以使用類似於ob_get_contents的方式實現，也可以利用類似ESI之類的頁面片段緩存策略，使其用來做動態頁面中相對靜態的片段部分的緩存。
該種方式可以用於如商城中的商品頁；五、Opcode緩存首先php代碼被解析為Tokens，然後再編譯為Opcode碼，最後執行Opcode碼，返回結果；所以，對於相同的php文件，第一次運行時可以緩存其Opcode碼，下次再執行這個頁面時，直接會去找到緩存下的opcode碼，直接執行最後一步，而不再需要中間的步驟了。
比較知名的是XCache、TurckMMCache、PHPAccelerator等。
六、按內容變更進行緩存這個也並非獨立的緩存技術，需結合著用；就是當資料庫內容被修改時，即刻更新緩存文件；比如，一個人流量很大的商城，商品很多，商品表必然比較大，這表的壓力也比較重；我們就可以對商品顯示頁進行頁面緩存；當商家在後台修改這個商品的信息時，點擊保存，我們同時就更新緩存文件；那麼，買家訪問這個商品信息時，實際問的是一個靜態頁面，而不需要再去訪問資料庫；試想，如果對商品頁不緩存，那麼每次訪問一個商品就要去資料庫查一次，如果有10萬人在線瀏覽商品，那伺服器壓力就大了；七、內存式緩存提到這個，可能大家想到的首先就是Memcached；memcached是高性能的分布式內存緩存伺服器。
一般的使用目的是，通過緩存資料庫查詢結果，減少資料庫訪問次數，以提高動態Web應用的速度、提高可擴展性。
它就是將需要緩存的信息，緩存到系統內存中，需要獲取信息時，直接到內存中取；比較常用的方式就是key_>value方式；connect($memcachehost,$memcacheport)ordie("Couldnotconnect");$memcache->set('key','緩存的內容');$get=$memcache->get($key);//獲取信息?>八、apache緩存模塊apache安裝完以後，是不允許被cache的。
廣州IT培訓http://www.kmbdqn.cn/認為如果外接了cache或squid伺服器要求進行web加速的話，就需要在htttpd.conf里進行設置，當然前提是在安裝apache的時候要激活mod_cache的模塊。

❻ 華為技術架構師分享：高並發場景下緩存處理的一些思路

在實際的開發當中，我們經常需要進行磁碟數據的讀取和搜索，因此經常會有出現從資料庫讀取數據的場景出現。但是當數據訪問量次數增大的時候，過多的磁碟讀取可能會最終成為整個系統的性能瓶頸，甚至是壓垮整個資料庫，導致系統卡死等嚴重問題。

常規的應用系統中，我們通常會在需要的時候對資料庫進行查找，因此系統的大致結構如下所示：

1.緩存和資料庫之間數據一致性問題

常用於緩存處理的機制我總結為了以下幾種：

首先來簡單說說Cache aside的這種方式：

Cache Aside模式

這種模式處理緩存通常都是先從資料庫緩存查詢，如果緩存沒有命中則從資料庫中進行查找。

這裡面會發生的三種情況如下：

緩存命中：

當查詢的時候發現緩存存在，那麼直接從緩存中提取。

緩存失效：

當緩存沒有數據的時候，則從database裡面讀取源數據，再加入到cache裡面去。

緩存更新：

當有新的寫操作去修改database裡面的數據時，需要在寫操作完成之後，讓cache裡面對應的數據失效。

關於這種模式下依然會存在缺陷。比如，一個是讀操作，但是沒有命中緩存，然後就到資料庫中取數據，此時來了一個寫操作，寫完資料庫後，讓緩存失效，然後，之前的那個讀操作再把老的數據放進去，所以，會造成臟數據。

Facebook的大牛們也曾經就緩存處理這個問題發表過相關的論文，鏈接如下:

分布式環境中要想完全的保證數據一致性是一件極為困難的事情，我們只能夠盡可能的減低這種數據不一致性問題產生的情況。

Read Through模式

Read Through模式是指應用程序始終從緩存中請求數據。 如果緩存沒有數據，則它負責使用底層提供程序插件從資料庫中檢索數據。 檢索數據後，緩存會自行更新並將數據返回給調用應用程序。使用Read Through 有一個好處。

我們總是使用key從緩存中檢索數據, 調用的應用程序不知道資料庫， 由存儲方來負責自己的緩存處理，這使代碼更具可讀性， 代碼更清晰。但是這也有相應的缺陷，開發人員需要給編寫相關的程序插件，增加了開發的難度性。

Write Through模式

Write Through模式和Read Through模式類似，當數據發生更新的時候，先去Cache裡面進行更新，如果命中了，則先更新緩存再由Cache方來更新database。如果沒有命中的話，就直接更新Cache裡面的數據。

2.緩存穿透問題

在高並發的場景中，緩存穿透是一個經常都會遇到的問題。

什麼是緩存穿透？

大量的請求在緩存中沒有查詢到指定的數據，因此需要從資料庫中進行查詢，造成緩存穿透。

會造成什麼後果？

大量的請求短時間內湧入到database中進行查詢會增加database的壓力，最終導致database無法承載客戶單請求的壓力，出現宕機卡死等現象。

常用的解決方案通常有以下幾類：

1.空值緩存

在某些特定的業務場景中，對於數據的查詢可能會是空的，沒有實際的存在，並且這類數據信息在短時間進行多次的反復查詢也不會有變化，那麼整個過程中，多次的請求資料庫操作會顯得有些多餘。

不妨可以將這些空值（沒有查詢結果的數據）對應的key存儲在緩存中，那麼第二次查找的時候就不需要再次請求到database那麼麻煩，只需要通過內存查詢即可。這樣的做法能夠大大減少對於database的訪問壓力。

2.布隆過濾器

通常對於database裡面的數據的key值可以預先存儲在布隆過濾器裡面去，然後先在布隆過濾器裡面進行過濾，如果發現布隆過濾器中沒有的話，就再去redis裡面進行查詢，如果redis中也沒有數據的話，再去database查詢。這樣可以避免不存在的數據信息也去往存儲庫中進行查詢情況。

什麼是緩存雪崩？

當緩存伺服器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給後端系統(比如DB)帶來很大壓力。

如何避免緩存雪崩問題？

1.使用加鎖隊列來應付這種問題。當有多個請求湧入的時候，當緩存失效的時候加入一把分布式鎖，只允許搶鎖成功的請求去庫裡面讀取數據然後將其存入緩存中，再釋放鎖，讓後續的讀請求從緩存中取數據。但是這種做法有一定的弊端，過多的讀請求線程堵塞，將機器內存占滿，依然沒有能夠從根本上解決問題。

2.在並發場景發生前，先手動觸發請求，將緩存都存儲起來，以減少後期請求對database的第一次查詢的壓力。數據過期時間設置盡量分散開來，不要讓數據出現同一時間段出現緩存過期的情況。

3.從緩存可用性的角度來思考，避免緩存出現單點故障的問題，可以結合使用 主從+哨兵的模式來搭建緩存架構，但是這種模式搭建的緩存架構有個弊端，就是無法進行緩存分片，存儲緩存的數據量有限制，因此可以升級為Redis Cluster架構來進行優化處理。（需要結合企業實際的經濟實力，畢竟Redis Cluster的搭建需要更多的機器）

4.Ehcache本地緩存 + Hystrix限流&降級,避免MySQL被打死。

使用 Ehcache本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時候，Ehcache本地緩存還能夠支撐一陣。

使用 Hystrix進行限流 & 降級 ，比如一秒來了5000個請求，我們可以設置假設只能有一秒 2000個請求能通過這個組件，那麼其他剩餘的 3000 請求就會走限流邏輯。

然後去調用我們自己開發的降級組件（降級），比如設置的一些默認值呀之類的。以此來保護最後的 MySQL 不會被大量的請求給打死。

❼ 「分布式緩存」 是什麼概念，怎麼理解

我的理解，分布式緩存系統是為了解決資料庫伺服器和web伺服器之間的瓶頸。
如果一個網站的流量很大，這個瓶頸將會非常明顯，每次資料庫查詢耗費的時間將會非常可觀。
對於更新速度不是很快的網站，我們可以用靜態化來避免過多的資料庫查詢。
對於更新速度以秒計的網站，靜態化也不會太理想，可以用緩存系統來構建。
如果只是單台伺服器用作緩存，問題不會太復雜，如果有多台伺服器用作緩存，就要考慮緩存伺服器的負載均衡。