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