最近，在知乎上看到這樣一個問題：
有些上古程序猿一直堅持反對使用redis怎么辦？
究竟用不用Redis？為什么用？怎么用？讓我們看看網友怎么說……
@靈劍
你不要告訴我們用不用redis，你得告訴我們你為什么想要用redis，不用redis業務會有什么問題？
天下沒有免費的午餐，不動腦子直接上緩存/NOSQL可能會帶來更多更嚴重的問題。
單一數據庫最大的好處在于事務性實現簡單，由數據庫自己保證。舉個簡單的例子，下訂單需要扣除一個庫存，然后插入一條訂單條目，如果庫存和訂單都是數據庫表項的話這個事務是無懈可擊的。
如果庫存在redis里，訂單條目是MySQL，通常就需要先寫redis，成功之后再寫數據庫，如果寫數據庫失敗了還需要回滾redis，如果最后這個回滾因為網絡之類的原因失敗了，就會多扣一個庫存。
不要以為這些事情很好解決，事務性處理的復雜性遠遠超過你的想象，比如說還有寫MySQL在提交的一瞬間連接斷了這種情況，你都沒法判斷提交到底成功了還是失敗了，那你的redis是回滾還是不回滾？
所以引入新的層一定要說清楚，你為了什么目的一定要用緩存/NOSQL，能接受什么樣的一致性模型，否則就是在胡鬧。
@Ivony
謹慎使用緩存是對的。
因為很多時候緩存會掩蓋掉一些問題，甚至放大問題。
從安全角度來說，緩存也是最容易被攻擊的薄弱點（緩存溢出攻擊，不是緩存區溢出攻擊，用大量無效的數據占滿緩存空間使得系統性能斷崖式下跌）。
所以通常做壓力測試的時候都是要求必須關閉緩存測試。
不單單是緩存，所有的中間件在解決一部分問題的同時也會帶來新的挑戰。譬如消息隊列對于削峰填谷的功效非常明顯，但是如果峰值持續的時間遠遠的超出了估計呢？而如果這時候消息阻塞的監控還在計劃中的話……
比如說分布式計算帶來了無限擴容的可能，而一致性問題很多時候會帶來非常多的麻煩。
權衡是永遠不會過時的。
@Coldwind
我大約從95年開始學習編程，我想我應該算是一個“上古程序員”。
首先說一下你的問題，這個問題中的“上古”明顯是帶著點歧視的（當然你可以把它解釋為調侃）。這個問題其實并不是個技術問題，問的其實并不是“是否該用Redis”，而是已經非常自信的認為應該用，只是該怎么解決掉“上古程序員堅持不用”這個問題。
因為做的不是這一塊，所以我個人并不了解Redis，但是可以說一下面對技術方向的分歧，我有什么解決方法：用或者不用某個系統/語言/技術/模塊/組件/架構，或者用A還是用B，無非牽扯到幾個方面的影響：工作量、可擴展性、穩定性、性能、安全性、維護難度/可讀性、費用等等。而在不同的選擇中通常都不太可能做到選擇A在所有方面都強過選擇B的，這時候要做的，其實是一個對各個方面的評估，乘以這個項目對哪些方面更看重的權重，然后得出結論。
如果你能拿出你要用Redis的證據，也就是在哪些方面比不用Redis強，強了多少，有必要的話需寫一些測試的程序來驗證你的結論。然后用這些量化的數據去說服對方，這才是一個嚴謹的程序員應該做的，而不是跑到知乎上來嘲諷一個跟你同樣想把事情做好，而只是理念不同的同事。
最后說一下，多年的工作中，我發現有些程序員（很多）選擇某個技術的原因，并不是基于上面所說的這些方面，而是：
- 我會這個，所以我用它
- 我感覺這個更好，所以我用它
- 這個是最新的技術，所以我用它
- 大家都用這個，所以我用它
而這幾個，其實都不是真正的理由（第一個還好點，因為會所以工作量更少）。不知道答主是不是也有這種情況，建議有則改之，無則加勉。
大家對于"該不該使用Redis？"這一問題，有怎樣的思考和想法呢？歡迎在留言區交流~
來源丨zhihu.com/question/383926405
