自己写个缓存中心可否替代redis?

对于java而言，分布式是现在的趋势。见过订单中心，用户中心等等，但是缓存一般用redis来实现。
为什么现在大多用redis做缓存，而只有老系统用hashMap做缓存呢？
用hashMap写到内存中来存储常用数据，会比redis慢吗？
写一个缓存中心，定义多个HashMap来存储不同种类的公共数据，和使用redis比起来哪个好？

redis相当于一个数据库缓存，独立的数据库服务
数据在hashMap内存中，一旦所在的服务挂了，缓存就没了，还得重新生成，但是redis不会

还有一部分原因是，当你多个子系统用到同一个缓存，难道每一个子系统都在自己的内存生成缓存么，
除非是为了空间换时间，

我的意思是单独创建一个缓存中心，一个单独的项目，部署到一个单独的服务器的，和redis一样。
单起一台服务器来专门做缓存，在做一些缓存持久化机制

采用dubbo协议或者rest方式，对缓存进行操作

用HashMap一定比Redis快的，因为Redis会有额外的网络IO的开销，那为什么用Redis而不用HashMap?
首先目前大部分的系统是分布式的，这种情况下使用HashMap的话，缓存利用率不高，每台机器上都会有相同的缓存副本，浪费内存。
当A存在某个Key的缓存 B没有，而请求访问到了B，这个时候A的缓存是无效的，请求会访问到DB同时在B上产生一个和A一样的缓存副本。
可以看到，这不仅是有重复的缓存浪费空间，而且缓存的命中率也会有所下降。
其次HashMap做缓存如果控制不好的话会引发FullGC,严重时导致系统宕机。所以，即便是要用本地缓存也会选择类似ehcache这种成熟的实现方案。
再者，系统宕机会导致缓存丢失，而redis支持主备，支持数据持久化，支持集群。可以提供成熟的高可用、高性能的支持。

为什么要重复早轮子

HashMap只能在一个进程中使用。线上系统要保证高可用，通常会部署多个进程，多台服务器。进程A无法访问进程B的HashMap，这会导致不同进程 缓存的数据不一致。如果自己开发一套系统，如:资源下载.让各个进程中的HashMap组成分布式缓存，需要的工作量、周期、成本和风险，远远大于使用Redis。

使用hashmap效率低，因为hashmap底层是哈希表，哈希表其实就是个数组，数组的每一个元素是一个单向链表，单向链表添加删除元素快，查询的效率很低的

你这样做，不就是在实现redis的功能吗？明明有现成的，更好的，为什么要费时费力的自己搞呢？除非你能确定，你自己搞得这个中心比redis更高效，更安全等等。否则还有什么意义呢？