最近,在知乎上看到這樣一個問題:
有些上古程序猿一直堅持反對使用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