Redis已经成为如今Java项目缓存方案的标准和绝大多数场景的解决方案，但本人在做一个新项目,这个项目一开始可能想以非常小的集群出现时，可能就两台应用服务器，但要做分布式缓存，至少要保存登录数据，这时候如果用Redis，那势必需要搭建一个Redis server，有点麻烦也有点浪费，搭建了就要维护监测，需要为Redis服务器提供近乎专有的内存空间，这时候还得思考，内存多大合适，单节点会不会当掉？改Redis集群？。。。干脆不用？以后项目大了再改回Redis？于是静心想想如火如荼的Redis，似乎并不是云原生应用的理想缓存方案，理想的云原生应用应该是什么样子呢？

       无服务端：服务端就意味着像Redis一样，需要搭建服务器，需要管理，需要配置所谓的集群，需要做集群的监控。而云原生应用本身就是集群，集群本身就可以通过服务发现互联互通，本身就是一个集群形式的服务端；

       去中心化：无中心结点，集群自动通过结点（node）和组（group）分布式存储缓存数据，数据可由结点存储副本，类似于hdfs分布式文件存储的思想，多结点多副本保存；

       分布式计算：Hadoop中分布式计算运用Map/reduce本地保存本地计算的优势，实现了结点数据存储于计算基本都在同一结点上进行，再将计算结果收集以实现了分布式计算。理论上我们理想的云分布式缓存方案也应具备此种能力，我们可将需要计算的数据存入缓存，然后在计算的时候由存数据的结点进行自身存储数据的计算。

       智能持久化：由集群管理的缓存更容易进行动态的数据分块持久化，而不像Redis要么全库持久化，即使分片也是固定的，无法根据集群情况只能决策持久化的数据片和持久化时机。

       在这种理想的云原生应用缓存方案下我们应用缓存的方式应该是这样的，我们搭建一个项目只需要引入对应的jar包，像用map一样去用分布式缓存，其他都交由框架自己去处理，无论我们一开始是一个还是后来是很多个结点，我们都不用去考虑。我们的应用可以结合spring cloud注册中心或者zk实现服务发现，这样由缓存框架根据应用服务器内存情况计算情况智能联合决策缓存数据的存取和调用，还能充分应用内存空间，想想都爽，各位看官意下如何？欢迎留言交流！有志同道合的朋友我们一起开发个框架搞个大新闻吧！     --史龙刚