Redis已經成爲如今Java項目緩存方案的標準和絕大多數場景的解決方案，但本人在做一個新項目,這個項目一開始可能想以非常小的集羣出現時，可能就兩臺應用服務器，但要做分佈式緩存，至少要保存登錄數據，這時候如果用Redis，那勢必需要搭建一個Redis server，有點麻煩也有點浪費，搭建了就要維護監測，需要爲Redis服務器提供近乎專有的內存空間，這時候還得思考，內存多大合適，單節點會不會當掉？改Redis集羣？。。。乾脆不用？以後項目大了再改回Redis？於是靜心想想如火如荼的Redis，似乎並不是雲原生應用的理想緩存方案，理想的雲原生應用應該是什麼樣子呢？
無服務端：服務端就意味着像Redis一樣，需要搭建服務器，需要管理，需要配置所謂的集羣，需要做集羣的監控。而云原生應用本身就是集羣，集羣本身就可以通過服務發現互聯互通，本身就是一個集羣形式的服務端；
去中心化：無中心結點，集羣自動通過結點（node）和組（group）分佈式存儲緩存數據，數據可由結點存儲副本，類似於hdfs分佈式文件存儲的思想，多結點多副本保存；
分佈式計算：Hadoop中分佈式計算運用Map/reduce本地保存本地計算的優勢，實現了結點數據存儲於計算基本都在同一結點上進行，再將計算結果收集以實現了分佈式計算。理論上我們理想的雲分佈式緩存方案也應具備此種能力，我們可將需要計算的數據存入緩存，然後在計算的時候由存數據的結點進行自身存儲數據的計算。
智能持久化：由集羣管理的緩存更容易進行動態的數據分塊持久化，而不像Redis要麼全庫持久化，即使分片也是固定的，無法根據集羣情況只能決策持久化的數據片和持久化時機。
在這種理想的雲原生應用緩存方案下我們應用緩存的方式應該是這樣的，我們搭建一個項目只需要引入對應的jar包，像用map一樣去用分佈式緩存，其他都交由框架自己去處理，無論我們一開始是一個還是後來是很多個結點，我們都不用去考慮。我們的應用可以結合spring cloud註冊中心或者zk實現服務發現，這樣由緩存框架根據應用服務器內存情況計算情況智能聯合決策緩存數據的存取和調用，還能充分應用內存空間，想想都爽，各位看官意下如何？歡迎留言交流！有志同道合的朋友我們一起開發個框架搞個大新聞吧！ --史龍剛