1樓：魚兒塘
任何三方元件的引入都需要有其目的性，而不是盲目跟風。
以redis來說，引入它肯定是為了解決問題，那麼首先要明白redis能解決什麼問題: 快取，資料庫，分布式鎖等等。
在解決問題的同時是不是引入了其他問題，有沒有更好的解決方案，這些都是我們需要思考的。比如用redis做快取，要考慮資料一致性，快取時效性，快取擊穿，快取穿透，快取血崩等等
2樓：面試專家邁克
這位是曾經被快取不一致問題深深地傷害過吧。
一般來說上古程式設計師沒什麼壞心眼，只是單純不想以後掉進坑裡面罷了。如果有人覺得大家都用Redis我也要用，而不是專案應該用，就是對專案的不負責任。
3樓：蕭璇
先跟上古猿講redis的好處，一定要堅持，如果實在講不通，那離職！一定要離職！！果斷離職！！！
不要說什麼要用適合的不選最好的，從個人角度講，專案如果沒用過redis，那在現在的網際網路環境中你是找不到工作的！
如果以後的某一天你出去面試了，跟乙個網際網路公司的面試官說上個專案不用redis、不用快取，那麼不管理由多麼充分、無快取的設計多麼合理，面試也都到這了，回去等訊息吧
所以年輕人如果沒打算為一家公司奉獻自己的職業道路，還是要多為自己想一想的，不管公司架構多麼穩定合理，都要據理力爭，堅持用redis快取，萬萬不能拘泥在公司的傳統技術中，除非公司架構中有更高階先進的技術，能給自己水平帶來提公升的
4樓：打玻璃
如果你只有單台伺服器要訪問這個redis，那完全沒必要上redis。
快取當然要用了，只不過為什麼一定要用redis？
你要做分布式系統？登入的點不在一台伺服器上，這麼大的系統了，那得用了。
不過如果資料庫是一台，登入伺服器是一台，那就完全沒必要上redis了。
我個人覺得redis的唯一優勢就是可以多台伺服器同時訪問，就跟普通資料庫一樣。
5樓：
我也非常不明白為啥這麼多遠古程式設計師還堅持用redis。
又不是啥新東西，都10多年前的玩意了。乙個堅持單執行緒設計(好吧最新版本改了，還沒ga），沒法用滿硬體效能，不原生支援線性擴充套件，落後時代的東西。
架構應該服務於業務，不能為了時髦堆東西。因為人家不願意用乙個10多年前設計的東西，就變成上古程式設計師了？
6樓：web說
因為他沒經歷過高併發場景，他不懂資料庫成為瓶頸時很難裡面解決，他不懂公升級資料庫費用昂貴。
直接用ab或者其他效能測試工具去刷爆他的介面，讓他體驗一下高併發下不到快取的脆弱。
7樓：
開發慢慢變成運維的說兩句：對於中介軟體和各種工具，一定要考慮運維的成本。
如果你司的伺服器是在個人能操作維護的情況下，還能獨善其身。但如果像我司的系統，均是部署在各地機構的內部伺服器，每使用乙個新工具都是一種巨大的運維成本。
中介軟體是會是要占用伺服器資源的，會出現異常的，是需要調優/監控的。這些東西你除了要自己要熟悉會，還得指導各地的實施/運維同事。
對於中介軟體異常引起的業務問題，解決起來也不輕鬆，舉列子我過去協助實施同事排查老介面資料傳遞慢，逐層分析是該老介面使用mq作快取，而且mq配置記憶體低資料量大導致了mq出現了阻塞的情況，將mq調優就正常了。此處解決方法很簡單，但要考慮機構網路不通，實施同事不熟悉，排查起來是花了不少時間才能定位到問題的。
每年都會有新的技術出現，每一種新的技術都是為了解決/優化過去技術不足的。在選用任何工具時，都應先考慮該工具是否成熟，維護成本。多問自己：
為什麼要用這個？是為了解決什麼問題？該工具方便維護不，適合推廣到各地環境嗎？
等等。很多時候使用新工具會解決你眼前的問題，但若你準備不足沒考慮好，新工具的引入同樣會帶來新的問題。
8樓：架構師
你這樣說人家可不好哦
首先你說你用redis，為什麼用？你得用證據來說服別人，而不是一味的看別人用你就用，更何況你用redis做快取，如果量就那麼點，資料完全能應付。記住，多引入乙個第三方，就多乙份危險。
說實話，很多程式設計師都數不清為什麼用redis，而大部分人用redis只是看別人在用，如果解決了一致性問題，我還是喜歡用程序內快取，加上LRU淘汰策略，比redis快幾十倍，例如我現在用的actor模型的框架，加上程序內快取，無論是維護量還是效能上都比用redis強很多。
而且redis我做過測試，如果啟用了持久化的話，每秒2000寫請求就足以壓垮乙個小集群，所以不要為了用redis而用redis，只有你的業務場景適合redis的時候用才是最好的
當然，不可否認，redis是現在最熱門的nosql，中小型專案做快取伺服器足以，但是乙個專案是否引入redis還需要看業務場景，也要看你是否能解決redis引入的其他問題
9樓：朱仕傑
他們想用啥，我比較好奇。不用也能跑，那為啥要用？ 如果真的要用「快取」，來提高效能。
那我們利用redis的優勢在哪？用其他的可以替代嗎？ ，我覺得「上古」程式猿是是個偽命題。
如果你今天不知道redis只是看到了一篇原始碼，也可以立刻判斷嗎？我很好奇？3個W.
往往能命中問題的本質。搞清楚了框架理念，問題範圍，「任何時代的程式猿」都能提高，其實最早的快取，有暫存器，有「檔案」，不一定非得要拘泥於形式， 而需窺見精華。當然如果你不想懂，不想玩的6，推薦用redis 。
道理是什麼？馬桶理論，你不懂馬桶沖水的，和你家水質，水質。使用者人群的結核性。
你去買馬桶一般也會去買個「科勒」的，因為口碑在。但你要不要作乙個靈活的水管工，享受乙個專享的馬桶。取決於個人集體單位。
10樓：無名氏
臥槽…竟然這麼多人反對使用redis…理由還很充分…首先80%以上的公司使用redis持久化…沒操作好，丟失幾分鐘資料根本無所謂…資料庫就不丟失資料了？幼稚！我就不信你們是每個請求就立即讀寫資料庫…
連我這種肉雞做小專案寫入資料庫都要dump方式寫入,比如dict內累計滿100條後再寫入資料庫持久化…所以我也不能在保證dump資料期間不出問題…那既然風險和redis一樣…為什麼不用？
何況如果redis持久化掌握清楚了…效能上可是完爆資料庫io的…所以根本別猶豫…我覺得大專案怎麼樣都應該引入redis並做好冗餘容錯方案…其餘專案想啥呢？丟失資料的問題根本不是個問題…
話說…你們有更好的方案？
11樓：bluetrees
自從我的新Sql Server伺服器比那個上古的redis伺服器跑的快以後，我就用B+樹索引替換了Hash索引，還自帶排序範圍查詢呢。
有位年輕的程式設計師，把兩個挺大的表從資料庫裡面讀出來，然後自己在記憶體中用C#的linq做記憶體join，我就想把他送去非洲了。
還有位中年程式設計師，想把我亂七八糟一團的單體應用拆分成細粒度的依賴訊息的細粒度服務後，我也想把他送到非洲區去。
是不是亂七八糟是要看人的，不同的人對亂七八糟的定義是不一樣的，打掃衛生的阿姨一直以為我是在學英語呢。
同理，你為什麼要用redis？這真的是個問題。
如果我有一大堆難以維護的，效能參差不齊的應用，很可能我需要在介面層做個快取來協調不同應用的響應差異，如果我可以改那些應用，那我就直接去改了，幹嘛弄個快取去包裝下嘛。
12樓：
成本很高吧，不一定划算
我們團隊用cdsw那一套東西，從hbase hive storm spark flink kafka/mq redis全都有，每天都有運維人員全程現場看著的，即使這樣也會三天兩頭出現業務故障。。。不過沒辦法，交易量太大不用扛不住
13樓：
這個問題問的好。
首先要問為什麼要用redis，為什麼要用快取如無必要，勿增實體
其實回答無非是資料庫軟體本身吞吐效能達不到希望的那個併發要求。上古程式設計師極有可能是個保守主義者，更加強調系統的穩定性和精確性，效能有時候從需求上看根本不作為優先事項。
有時候也確實如此。
很多專案其實並不存在架構的演進，而是希望一步登天。這一點不能說錯，只能說，有點貴。因為一旦加入快取，說明你在業務層和資料持久層增加了一層複雜度，維護成本就多出了乙個維度。
有時候有的業務也許根本不需要加快取。你說，有的後台業務的開發你加redis有啥用？很多時候只是對一些可能造成併發擁堵的場景才會用上redis，比如訂閱資訊流、聊天推送等等。
上古程式設計師從他的保守的成本估計時，就有可能從最原始的架構開始做加法，如果不存在乙個業務必須用到的話，那麼該實體也無需增加。
14樓：瘋子
我覺得資料分三種
1.量不大，很少改動，常用這種我肯定加程序的堆裡。
2.量小到中等，頻繁改動，常用這種應該放記憶體資料庫比如 redis3.剩下的結構化資料都去mysql這些關係型資料庫吧反正錢夠的情況下為啥程式設計師不多考慮些效能？
15樓：
感覺一堆人為了各種理由反對。
有人為了靜態資源的更新反對cdn嗎，有人為了一致性反對負載均衡和分布式嗎。
竟然還有人奢望通過提公升硬體效能來解決。
能力不行就提高能力唄，沒啥好羞恥的。
技術發展要是交給你們，人類現在估計還停留在unix時代。
16樓：by wang
雖然各位老大說要謹慎使用快取，我還是想微微反對下。
不過你這個問題本身就有問題，redis也不算啥新技術。雖然很多企業充斥著對技術發展不看的人，但是拿redis來比方的確是不合適。
簡單點說下我的觀點，如果業務業內很普遍，那麼主流實踐應該問題不大，如果老骨頭罔顧主流實踐，那幾乎是沒跑了。
另外在架構選擇上始終也只是權衡的問題，當你引入redis有一得有一失，帶來的問題跟解決的問題值不值。
最後其實想稍微反對一下各位老大，很明顯，你這個以redis為問題的問題，並不怎麼讓人舒心，自然被懟也是正常。
17樓：
Redis常用的幾個領域，cache，分布式鎖，訊息佇列，共享「記憶體」，分布式事務。
他不讓你用在資料庫的上面，你找其他領域用就行了，乙個搞資料庫的，還管的了分布式事務的麼？他真要用資料庫做分布式一致性，你就噴他，資料庫兜底資料庫是深井冰，至少需要另外乙個中介軟體來兜底。
18樓：WJPJW
我反對用redis做關係型資料庫的快取，認為這只是一種實踐上的權宜。
Redis本身是有些特性很適合用作快取的。對比innodb buffer pool，它就有一些固有優勢：省去了sql解析的開銷，可以只存資料無需存索引。
但相應的，它的重要劣勢是：不支援事務，存在資料丟失風險，很難保證快取一致性，還引入了分布式系統的種種險惡問題。
Innodb buffer pool這種內嵌快取則沒有這些問題，還非常完善地讓非事務操作（本質上也由mini-transaction執行）也遵循了底層的ACID。
二者並非不可得兼。
更優雅的解決方案是讓儲存引擎支援in-memory store & key value protocol，比如Innodb Memcached Plugin。如下圖，Innodb儲存引擎上直接加上memcached層，省去了sql解析的開銷，又完全不用擔心快取一致性。介面同時支援memcached protocol和sql，可以配置成記憶體資料庫為主，Innodb只做少許持久化，也可以配置成Innodb為主，記憶體資料庫只做為乙個更高效的buffer pool。
程式設計師一直堅持健身是一種怎樣的體驗
小林 在公司樓下辦卡 一週三練 利用下班 10點 前的乙個小時去鍛鍊 已經練了半年 身材不咋地 但是比周邊同事吃得多 腰圍漲幅更小 就已經很爽了 周二公司包場打籃球 當有氧訓練了 胡星雨 目前大二，讀軟體工程，以後大概率是程式設計師了！一直有健身，過年都不會放縱自己。屬於蠻自律的一類人，但是沒錢吃好...
一直幹銷售一直沒有業績還要堅持嗎？
達利通訊電銷卡 每個人做銷售都會有一段迷茫期，尤其是做不出業績的時候。華迪我剛開始做銷售時也會有這個困惑。那麼做銷售很久不出業績怎麼辦呢？我說下對這個問題的看法。一 不出業績的原因 根據華迪了解，做銷售很久都不出業績的原因最有可能原因是下面2個 1 你選的行業太難了，開單周期長 有些新手，從來沒做過...
一直不吃飯可以堅持多久？
call me 誒。有飯我就是不吃，哎，我就是玩兒！這可不是玩哦！一直不吃飯你靠什麼去維持你的生理機能？靠水嗎？半天不吃飯可能還只是肚子餓而已，超過一天，你就會很難受的。長期下去就非常容易得胃病！何必要拿自己的身體健康開玩笑呢。我以前讀高中的時候，因為生活費都拿去買球鞋去了，乙個星期除了早餐，連續三...