03.06 Redis緩存是針對於業務數據緩存還是對數據庫數據緩存?

德意洋洋QAQ


不應該問Redis緩存的是業務數據還是數據庫數據,可以問Redis是屬於業務層還是數據層,這樣問比較合理。


我覺得Redis屬於數據層;首先我們先看一個概念。


DAO

data access object:數據訪問對象

主要用來封裝對數據的訪問,注意,是對數據的訪問,不是對數據庫的訪問。

其實你的數據可以在數據庫,在文件中,還是在Redis中,都可以通過DAO層訪問。

所以我把Redis看成和數據庫是同一個級別的。


Mybatis的二級緩存

我們使用Redis的時候,很多時候都是通過代碼操作Redis,比如使用用Jedis,其實還有一個簡單的辦法,就是使用Redis做Mybatis的二級緩存,只需要做簡單的配置和極少量的代碼即可。


我們之前做的一個項目,會有大量的數據需要頻繁被查詢,很少(幾乎沒有)做新增修改刪除的操作,這種數據很適合使用Redis進行緩存,所以新的版本想把Redis引入進來。


  • 引入所需要的jar包:


  • 增加配置文件


  • 實現org.apache.ibatis.cache.Cache接口


  • mybatis-config.xml開啟二級緩存:

<setting>


  • mybatis的Mapper配置文件中增加配置:

<cache>

其中useCache="false"表示,這個查詢SQL不進行緩存;useCache="true",這個查詢SQL的結果進行緩存。


其餘的insert、update、delete操作,可以進行如下配置:flushCache="true/false",當設置成true的時候,執行sql會把redis中的緩存刪除(調用Cache實現類的clear()方法),設置成false,則不做操作。


所以到這裡也可以清楚的理解何時進行緩存、何時進行刪除緩存了:程序剛啟動的時候,Redis中是空的。每次執行select的時候,首先會去redis讀取,讀取不到的話,再去db中查詢,查詢結束後,將結果存入redis中(key裡面包含了SQL語句),注意,如果sql查詢無結果,也會放入redis中。執行insert、update、delete語句的時候,清除對應的redis中的值。


整理的功能實現還是很簡單的,大家有興趣可以嘗試一下。

如果大家需要demo的源碼,後續我整理一下發出來,有需要的朋友可以關注下我。


會點代碼的大叔


我們在BAT裡做平臺開發的工程師,已經越來越離不開Redis了。

我們用redis主要就是代替memcached,來做緩存。

從功能上,redis既可以做業務數據的緩存,也可以做數據庫緩存,接下來我來分別介紹。

數據庫緩存

目前大多數場景都是使用redis做數據庫緩存。舉個例子,一個任務的創建首先要寫入數據庫,從而得到一個id,然後這個任務要去執行。執行過程中可能要多次讀取修改這個任務的某些字段,比如修改狀態字段,執行者字段,用戶頻繁輪訓這個任務狀態等等,如果這個過程頻繁去讀寫數據庫無疑容易給MySQL帶來額外的負擔,那這種場景就非常適合引入redis作為緩存。在數據寫入MySQL後,把這個數據同樣寫入redis,然後在這個任務徹底完成之前,所以讀過程都在redis中實現,如果用戶輪詢這個任務的狀態,那麼直接從redis中將任務狀態讀取給他就好了,這樣就減少了MySQL的讀壓力。

但是要注意的是,redis只是作為緩存,當任務發生不一致的情況時,一切要以MySQL中的數據為準,舉例期間redis宕機了(雖然很少發生),那麼要有相應的備案,將MySQL中的數據重新load進redis。

業務數據緩存

由於redis強大的讀寫能力,我們也可以將一些業務數據緩存在redis。

舉例,我們有個場景,一個平臺多個場景需要動態的調整某些參數的閾值。每次都修改代碼裡的閾值,再重啟服務器的話這個代價實在是太大了。這種時候不妨將閾值從內存中讀取改為去redis中讀取。這樣每次要修改閾值,直接去redis中修改對應的數據就好了,即修即生效,免去了重啟服務器的代價。

redis本身作為工具,提供的是能力,而不應該被限制場景。

綜上,利用redis強大又快速的讀寫能力,我們既能實現數據庫緩存也能實現業務數據緩存。

以上是我的淺見,歡迎各位在下方點贊,評論與我交流。

我是蘇蘇思量,來自BAT的JAVA開發工程師,每日分享科技類見聞,歡迎關注我,與我共同進步。


一個存在感小透明


緩存的目的,用大白話說,其實就是充實計算機的“隨機實用性”的概率。這就如同我們買了一個東西,放在家裡,暫時排不上用場,這個東西閒置在家,說不定哪一天就可以用上了。

緩存,其實也是一個數據收集的方式。它是數據庫中的一部分。比方說,我們打字,用詞,每個人都有相似的用詞方式,也有個性化的組詞,用詞方式,計算機不可能做到實時的全方位聯想,怎麼辦呢?它就根據每個人使用詞彙的頻率,滿足個性化的組詞用詞的習慣,換言之,如果要了解個人化的用詞或組詞方式,就到它的計算機的緩存中去尋找就可以了,同時,緩存,也在不斷地充實著計算機系統的數據充實程度。更通俗的說:緩存,即:個性化的數據待用狀態。


北京得明


這種問題本身就不存在的,好嗎?

redis功能那麼強,你如果把它限定死某種數據類型或者業務類型上,你就大錯特錯了!



看下redis特性:

1,多語言支持:基本上支持所有的編程語言,包括JAVA,C,Ruby,python等等!

2,多種數據類型:跟memcache等傳統內存緩存相比,redis支持更多的數據類型!包括list,set,treemap等等這種高級的數據結構!

3,單線程:沒錯,現如今單線程大行其道的時代,redis使用了單線程模型,雖然性能比多線程略有降低,但是Redis結合了tcmalloc和jemalloc兩個內存分配器,分配效率極好,再加上單線程少了上下文切換,保證數據安全(不存在線程數據共享)的特性,可以說單線程也算是優勢了!

4,持久化:可配置磁盤持久化數據,保證和關係型數據庫一樣,數據不丟失!

5,主從複製:redis支持搭建大型高可用的集群,避免單點故障帶來的數據丟失!

6,性能逆天:秒級的存取速度達到10萬左右,應付大多數的分佈式大數據量場景了!相比較關係型數據庫,減少了IO,磁盤指針切換的時間,性能很好!

既然redis那麼好用,那麼redis一般有哪些使用場景呢?

1,緩存:內存型緩存速度極快,可用於緩存靜態數據(數據庫中的定義表,代碼中的枚舉,大量靜態配置等等),一般通過定時任務將數據緩存!

2,定期時間:redis自帶的set和get方法中可以設置過期時間,在配置諸如頁面登錄過期失效,前端操作流程失效等等,十分方便!

3,數據共享:分佈式架構存在比如session,token,某個共享變量等的數據共享的情況,會有數據不安全,可統一配置在redis中進行存儲,利用redis單線程的特性,可保證數據的一致性!

4,分佈式鎖:通過使用sernx方法,實現分佈式鎖,在消息消費,數據存取的時候實現加鎖,保證數據安全!

5,計數器:同樣使用redis單線程原理,可以自己實現計數器,也可用自帶的增加方法!


redis作為一個key-value類型的內存數據庫,在保證性能很強的情況下,實現數據的安全存取,同時支持多種類的數據類型,可以說是數據緩存的不二之選!

如果你有redis使用方面的任何問題,可以私聊我,知無不答!


此生唯一


redis就是冰箱的保鮮層。存取次數頻繁。隨取隨用。並且可以設置保鮮時間。過期就自動消亡了。而數據庫他是持久層。他是和業務直接或間接掛鉤的。任何業務或非業務的邏輯redis均可應付。只是看你自己想讓他做什麼。只是做隊列還是做數據的短暫存放都是可以的


killman


Redis 它是一種鍵-值數據庫 這些數據即可存儲到內存裡又可存儲在硬盤上 重點喔 在整個系統中有需要的地方使用 沒訪問壓力的業務模塊 關係型數據庫自己能輕鬆應付的部分就別用Redis 而是在有發現瓶頸的業務模塊處使用 以用來解決文件系統或者關係型數據庫或讀記錄或寫入記錄速度慢的問題 或數據庫服務器宕機的嚴重問題 這時此處就不要用關係型數據庫 使用Redis單獨上陣來解決這類瓶頸問題 Redis既是緩存數據庫又是持久化數據庫 我們可以隨便選個夜深人靜的時間再把Redis裡保存的所有數據全部同步到關係型數據庫中即可 同步工具自己寫個小工具 千萬別在架構裡有瓶頸的模塊處用關係型數據庫了 這麼亂用Redis跟沒用Redis一樣 沒解決任何實際問題 設計架構時按需要決定是否要在此處用Redi用s 少用系統好維護啊 又省心又省錢 最後強烈建議一定要學會Key-Value類型的數據建模 不明白? 就是關係型數據庫表之間的1:1關係1:n關係 m:n關係 你要會用鍵-值對的形式來存儲多張關係型數據表裡的數據 既要保證能高效率的讀取記錄 又能容易編輯它們 建模的知識只能去學 MongoDB數據庫了 別瞎胡亂啥地方都使用Redid 替你們老闆省點心省點錢吧 菜鳥們 nosql建模很重要!!!


鄭紫至1


數據庫裡存的不就是業務產生的數據嗎?


架構師之路


請看視頻,解決了這個問題。內容剛剛好,解說幽默風趣

http://www.365yg.com/item/6546137575579451911/


分享到:


相關文章: