我了解的差别有：
自带的数据结构：不用和缓存服务器建立通信，效率可能会更高？
NoSQL：集群环境下，业务服务器的缓存数据不能共享，存在资源浪费。而NoSQL的数据可以共享给业务服务器。
不知道还有没有其他差别，主要是发现现在的项目中部署了多台服务器，但是每台服务器的缓存数据都是一样的，而且请求是不走数据库的，有个定时任务会去同步数据库中的数据到缓存中。如果仅仅为了提高系统的QPS，是否应该使用NoSQL去做缓存?
数据量很小的才会用数据结构缓存，毕竟是放在内存的，数据量大的肯定只能用nosql了
可以参考下HBase的设计。
HBase物理存储是基于HDFS的MapFile格式（新版本自己实现了HFile，但是原理基本一样）。MapFile是只读的键值对文件，一次写入后就不可以修改。而且MapFile要求该文件下所有的Key在写入的时候是已排序的。在这种情况下，HBase首先先将数据存放在MemStore中，等MeMStore存到一定量的数据后， 再持久化写入到HDFS（MapFile or HFile）。
因此你的缓存可以以内存数据结构+NoSQL持久化的机制去实现。两种方式互相弥补
我就不说好不好实现，如果你把大量的对象直接放jvm里，你启动程序的时候，头发都会等白了的。每次启动一次初始化加载一次！苦不堪言
都不好，最好用缓存框架，比如：ehcache
问“哪种好”一般得到的答案都是“不一定”。这不是一个非黑即白的世界，大部分时候还得要“看情况”。
轻量级应用自带数据结构做缓存可以是一个不错的选择，不通过网络的通讯方式肯定相对高效，并且对程序来说也简单易用。但是大部分自带数据结构并不是线程安全的，意味着在适当的时候你需要自己加锁进行线程同步。线程同步的话题不在本题的讨论范围内，但是想玩转线程同步也并不是件轻松的事情，很多人不是锁不住就是使用过重的锁导致性能低下。在真正高并发环境中哪怕一小段时间的性能下降，也可能导致服务器上累积大量请求无法处理而使应用崩溃。
所以当你的应用到达一定规模，就该考虑使用分布式缓存了，除了锁的问题已经在服务端解决之外，还可以解决你提到的缓存无法共享的问题，以及水平扩展的问题（缓存太多无法在一台服务器容纳怎么办？）。同样的条件下从内部缓存迁移到分布式缓存可能并不能缩短响应时间提高QPS，大部分时候可能还会在一定程度上延长响应时间（网络传输及序列化、反序列化过程）。但是作为交换，更重要的是带来了水平扩展能力，说直白些，让你可以通过堆服务器就可以处理更多请求。水平扩展才是大部分分布式数据库要解决的重点问题。
当然在引入NoSQL的同时也不可避免地引入了复杂性，为你的开发增加额外的工作量。但是NoSQL数据库又会带来一些额外的好处，比如高可用，缓存数据的一致性。
说了这么些恐怕已经绕晕了，我想表达的意思是，引入NoSQL来做缓存可能并不像你想象的那么美妙，它既会带来问题，也会带来优势。你要做的事情是，对你自己的应用场景评估它带来的优势是不是你想要的，享受这些优势的同时，你是否可以容忍它带来的不良影响，然后决定要不要用。
这要看数据量的大小，在小数量的条件下，使用自带数据结构是成本最小、效率最高的选择。
在大数据量的条件下，必定使用现成的noSql服务，自已编写的组件或许会有致命的BUG也不一定，久经考验的软件才是我们的好选择。而且这些软件都具备了大数据量下必须要有的功能。