我了解的差别有：
自带的数据结构：不用和缓存服务器建立通信，效率可能会更高？
NoSQL：集群环境下，业务服务器的缓存数据不能共享，存在资源浪费。而NoSQL的数据可以共享给业务服务器。
不知道还有没有其他差别，主要是发现现在的项目中部署了多台服务器，但是每台服务器的缓存数据都是一样的，而且请求是不走数据库的，有个定时任务会去同步数据库中的数据到缓存中。如果仅仅为了提高系统的QPS，是否应该使用NoSQL去做缓存?
认证0级讲师
問「哪一種好」一般得到的答案都是「不一定」。這不是一個非黑即白的世界，大部分時候還要「看情況」。 輕量級應用自帶資料結構做快取可以是一個不錯的選擇，不透過網路的通訊方式肯定相對高效，而且對程式來說也簡單易用。但是大部分自帶資料結構並不是線程安全的，這意味著在適當的時候你需要自己加鎖進行線程同步。線程同步的話題不在本題的討論範圍內，但是想玩轉線程同步也並不是件輕鬆的事情，很多人不是鎖不住就是使用過重的鎖導致性能低下。在真正高並發環境中即使一小段時間的效能下降，也可能導致伺服器上累積大量請求無法處理而使應用程式崩潰。 所以當你的應用程式到達一定規模，就該考慮使用分散式快取了，除了鎖的問題已經在服務端解決之外，還可以解決你提到的快取無法共享的問題，以及水平擴展的問題（快取太多無法在一台伺服器容納怎麼辦？同樣的條件下從內部快取遷移到分散式快取可能無法縮短回應時間提高QPS，大部分時候可能還會在一定程度上延長回應時間（網路傳輸及序列化、反序列化過程）。但作為交換，更重要的是帶來了水平擴展能力，說直白些，讓你可以透過堆伺服器就可以處理更多請求。 水平擴展才是大部分分散式資料庫要解決的重點問題。 當然在引入NoSQL的同時也不可避免地引入了複雜性，為你的開發增加額外的工作量。但NoSQL資料庫又會帶來一些額外的好處，例如高可用，快取資料的一致性。 說了這麼些恐怕已經繞暈了，我想表達的意思是，引入NoSQL來做緩存可能並不像你想像的那麼美妙，它既會帶來問題，也會帶來優勢。你要做的事情是，對你自己的應用場景評估它帶來的優勢是不是你想要的，享受這些優勢的同時，你是否可以容忍它帶來的不良影響，然後決定要不要用。
這要看資料量的大小，在小數量的條件下，使用自帶資料結構是成本最小、效率最高的選擇。 在大數據量的條件下，必定使用現成的noSql服務，自已編寫的組件或許會有致命的BUG也不一定，久經考驗的軟體才是我們的好選擇。而這些軟體都具備了大數據量下必須要有的功能。
都不好，最好用快取框架，例如：ehcache
資料量很小的才會用資料結構緩存，畢竟是放在記憶體的，資料量大的肯定只能用nosql了
可以參考下HBase的設計。 HBase實體儲存是基於HDFS的MapFile格式（新版本自己實作了HFile，但原理基本上一樣）。 MapFile是唯讀的鍵值對文件，一次寫入後就不可以修改。而且MapFile要求該檔案下所有的Key在寫入的時候是已排序的。在這種情況下，HBase先將資料存放在MemStore中，等MeMStore存到一定量的資料後， 再持久化寫入到HDFS（MapFile or HFile）。 因此你的快取可以以記憶體資料結構+NoSQL持久化的機制去實現。兩種方式互相彌補
我就不說好不好實現，如果你把大量的物件直接放jvm裡，你啟動程式的時候，頭髮都會等白了的。每次啟動一次初始化載入一次！苦不堪言
問「哪一種好」一般得到的答案都是「不一定」。這不是一個非黑即白的世界，大部分時候還要「看情況」。
輕量級應用自帶資料結構做快取可以是一個不錯的選擇，不透過網路的通訊方式肯定相對高效，而且對程式來說也簡單易用。但是大部分自帶資料結構並不是線程安全的，這意味著在適當的時候你需要自己加鎖進行線程同步。線程同步的話題不在本題的討論範圍內，但是想玩轉線程同步也並不是件輕鬆的事情，很多人不是鎖不住就是使用過重的鎖導致性能低下。在真正高並發環境中即使一小段時間的效能下降，也可能導致伺服器上累積大量請求無法處理而使應用程式崩潰。
所以當你的應用程式到達一定規模，就該考慮使用分散式快取了，除了鎖的問題已經在服務端解決之外，還可以解決你提到的快取無法共享的問題，以及水平擴展的問題（快取太多無法在一台伺服器容納怎麼辦？同樣的條件下從內部快取遷移到分散式快取可能無法縮短回應時間提高QPS，大部分時候可能還會在一定程度上延長回應時間（網路傳輸及序列化、反序列化過程）。但作為交換，更重要的是帶來了水平擴展能力，說直白些，讓你可以透過堆伺服器就可以處理更多請求。 水平擴展才是大部分分散式資料庫要解決的重點問題。
當然在引入NoSQL的同時也不可避免地引入了複雜性，為你的開發增加額外的工作量。但NoSQL資料庫又會帶來一些額外的好處，例如高可用，快取資料的一致性。
說了這麼些恐怕已經繞暈了，我想表達的意思是，引入NoSQL來做緩存可能並不像你想像的那麼美妙，它既會帶來問題，也會帶來優勢。你要做的事情是，對你自己的應用場景評估它帶來的優勢是不是你想要的，享受這些優勢的同時，你是否可以容忍它帶來的不良影響，然後決定要不要用。
這要看資料量的大小，在小數量的條件下，使用自帶資料結構是成本最小、效率最高的選擇。
在大數據量的條件下，必定使用現成的noSql服務，自已編寫的組件或許會有致命的BUG也不一定，久經考驗的軟體才是我們的好選擇。而這些軟體都具備了大數據量下必須要有的功能。
都不好，最好用快取框架，例如：ehcache
資料量很小的才會用資料結構緩存，畢竟是放在記憶體的，資料量大的肯定只能用nosql了
可以參考下HBase的設計。
HBase實體儲存是基於HDFS的MapFile格式（新版本自己實作了HFile，但原理基本上一樣）。 MapFile是唯讀的鍵值對文件，一次寫入後就不可以修改。而且MapFile要求該檔案下所有的Key在寫入的時候是已排序的。在這種情況下，HBase先將資料存放在MemStore中，等MeMStore存到一定量的資料後， 再持久化寫入到HDFS（MapFile or HFile）。
因此你的快取可以以記憶體資料結構+NoSQL持久化的機制去實現。兩種方式互相彌補
我就不說好不好實現，如果你把大量的物件直接放jvm裡，你啟動程式的時候，頭髮都會等白了的。每次啟動一次初始化載入一次！苦不堪言