JIDIJI
分享大佬的回答，似乎很有道理。
不要告訴我們用不用redis，你得告訴我們你為什麼想要用redis，不用redis業務會有什麼問題？天下沒有免費的午餐，不動腦子直接上緩存/NOSQL可能會帶來更多更嚴重的問題。
單一數據庫最大的好處在於事務性實現簡單，由數據庫自己保證。舉個簡單的例子，下訂單需要扣除一個庫存，然後插入一條訂單條目，如果庫存和訂單都是數據庫表項的話這個事務是無懈可擊的，如果庫存在redis裡，訂單條目是MySQL，通常就需要先寫redis，成功之後再寫數據庫，如果寫數據庫失敗了還需要回滾redis，如果最後這個回滾因為網絡之類的原因失敗了，就會多扣一個庫存。不要以為這些事情很好解決，事務性處理的複雜性遠遠超過你的想象，比如說還有寫MySQL在提交的一瞬間連接斷了這種情況，你都沒法判斷提交到底成功了還是失敗了，那你的redis是回滾還是不回滾？
所以引入新的層一定要說清楚，你為了什麼目的一定要用緩存/NOSQL，能接受什麼樣的一致性模型，否則就是在胡鬧。
Java實戰技術
大家好，我是阿邁達，有趣的互聯網軟件工程師。專業角度分析技術原理，幽默的態度解讀科技互聯網資訊。
為什麼有些程序員不喜歡用Redis或者拒絕使用Redis？我覺得有以下兩個原因：
項目本身不需要使用緩存
緩存是為了將熱點數據存放到內存中，減少應用系統與數據庫交互的次數以及傳輸，從而提高系統的響應時間。在高併發系統中，緩存技術是應用非常普遍的技術，因為系統最終的瓶頸都會落到數據庫層面。通過緩存熱點數據或者變化非常小的數據，前端請求可以直接查詢內存獲取到數據，而不用查詢數據庫，這樣可以有效提高系統的併發性能。但是在一些小型應用系統或者後臺系統，其併發數和數據量本省就非常小，所以完全沒有必要使用Redis之類的緩存技術。因為使用了Redis，必然就要去搭建Redis的服務，並且維護它，這無形中又是成本的增加。所以，這可能是有些程序員不喜歡使用Redis的原因，系統特性所決定的。不是說任何一個系統都要上緩存技術。
有可替代的其它緩存技術
緩存技術非常多，例如Memcached、Ehcache、Aerospike等技術。尤其是Ehcache，可以與Java無縫集成，無需像Redis一樣搭建Redis Server，數據直接緩存在應用所在的主機上，這對於單機應用或者不需要共享數據的集群應用很適用。同時，Java中我們使用靜態Map、集合都可以作為緩存解決方案。而Memcached和Aerospike等緩存技術，他們的設計和使用都比Redis要簡單的多，如果我們只是簡單使用緩存，那Memcached是最佳選擇。Redis的功能更為強大，性能更好，它補償了memcached這類key/value存儲的不足，在部分場合可以對關係數據庫起到很好的補充作用。
結論
所以，要不要用Redis需要看項目本身的特性，如果系統併發小、數據量小，緩存技術沒有必要使用，一個Mysql就完全可以搞定。其次，需要考慮成本，可以用Ehcache解決的，就不用Memcached，可以用Memcached解決的，就不用Redis。至於Aerospike，阿邁達在用，感覺非常強悍，TPS可以到10萬左右，誰用誰知道。
阿邁達聊技術
技術無對錯，選擇對項目開發最合適的，自己最熟悉的技術是永恆的真理。一些上古程序員堅持反對Redis，該怎麼辦？下面談談自己的看法。
什麼是Redis
Redis是一個開源的、基於內存的數據結構存儲器，可以用作數據庫、緩存和消息中間件，使用ANSI C語言編寫、遵守BSD協議、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。
上古程序員一直堅持反對使用redis怎麼辦？
其實，上古程序猿數據庫用的比較好，SQL寫的質量比較高，知道什麼情況下能用到索引，什麼情況下SQL數據會被緩存。用好了SQL不用Redis是完全可以的。
對於緩存保持謹慎態度是完全沒有問題的。因為很多時候緩存會掩蓋掉一些問題。比如緩存溢出攻擊（不是緩存區溢出攻擊），用大量無效的數據佔滿緩存空間使得系統性能急劇下降，比如經常會遇到的由於系統緩衝區空間不足或隊列已滿，不能執行套接字上的操作等錯誤提示。
其實，不僅僅是緩存，所有的中間件在解決一部分問題的時候必然會帶來其他的問題。比如說分佈式計算帶來了無限擴容的好處，但是如何保證數據一致性又是帶來的一大問題！
所以，對於堅持反對使用redis的上古程序員，沒有必要去爭執，對於緩存，謹慎的態度是不會有錯的！技術無對錯，合適的、自己熟悉的永遠是最好的。
本文為作者“一個程序員的奮鬥史”悟空問答原創文章，未經允許轉載、抄襲必究！
