我是個很懶的人，喜歡自己偷著練“葵花寶典”岁疼，唯一可以看到我之前網(wǎng)上寫的安全方面的文章阔涉，還是好幾年前的事情了缆娃。公司最近來了一群美女，可是熱鬧了瑰排，寫稿獎勵美女贯要，我老興奮了。
說起緩存相關技術椭住，老多了崇渗， memcache、redis京郑、squid宅广、varnish、web cache些举、 CDN等等跟狱。緩存技術五花八門，但這些技術間有什么共性的地方户魏，又有什么不同的地方呢兽肤？答案肯定是有的，這次為大家分享及整理一下緩存方面的技術绪抛，主要分為三個系列展開：
- 緩存隨談系列之一：數(shù)據(jù)庫緩存
- 緩存隨談系列之二：靜態(tài)緩存
- 緩存隨談系列之三：動態(tài)緩存
本文主要介紹數(shù)據(jù)庫緩存技術為開頭，不足之處歡迎大家拍磚电禀，使勁拍幢码。
一、什么是數(shù)據(jù)庫緩存
我們知道常見的數(shù)據(jù)庫尖飞，比如oracle症副、mysql等，數(shù)據(jù)都是存放在磁盤中政基。雖然在數(shù)據(jù)庫層也做了對應的緩存贞铣，但這種數(shù)據(jù)庫層次的緩存一般針對的是查詢內容，而且粒度也太小沮明，一般只有表中數(shù)據(jù)沒有變更的時候辕坝，數(shù)據(jù)庫對應的cache才發(fā)揮了作用。但這并不能減少業(yè)務系統(tǒng)對數(shù)據(jù)庫產(chǎn)生的增荐健、刪酱畅、查、改的龐大IO壓力江场。所以數(shù)據(jù)庫緩存技術在此誕生纺酸，實現(xiàn)熱點數(shù)據(jù)的高速緩存，提高應用的響應速度址否，極大緩解后端數(shù)據(jù)庫的壓力餐蔬。
以下為memcache數(shù)據(jù)庫緩存為例，以圖說明一下什么是數(shù)據(jù)庫緩存：
二、數(shù)據(jù)庫緩存的技術特點
性能優(yōu)越
數(shù)據(jù)庫緩存的第一個技術特點就是提高性能樊诺，所以數(shù)據(jù)庫緩存的數(shù)據(jù)基本上都是存儲在內存中仗考，相比io讀寫的速度啄骇，數(shù)據(jù)訪問快速返回痴鳄。而且在mysql 5.6的版本開始，已經(jīng)把memcache這種跟數(shù)據(jù)庫緩存直接掛鉤的中間件直接集成進去了痪寻，已經(jīng)等不及我們自己去單獨部署對應數(shù)據(jù)庫緩存的中間件了橡类。
應用場景
針對數(shù)據(jù)庫的增顾画、刪研侣、查庶诡、改，數(shù)據(jù)庫緩存技術應用場景絕大部分針對的是“查”的場景咆课。比如末誓，一篇經(jīng)常訪問的帖子/文章/新聞、熱門商品的描述信息书蚪、好友評論/留言 等喇澡。因為在常見的應用中，數(shù)據(jù)庫層次的壓力有80%的是查詢殊校，20%的才是數(shù)據(jù)的變更操作晴玖。所以絕大部分的應用場景的還是“查”緩存。當然为流，“增窜醉、刪、改”的場景也是有的艺谆。比如榨惰，一篇文章訪問的次數(shù)，不可能每訪問一次静汤，我們就去數(shù)據(jù)庫里面加一次吧琅催？這種時候居凶，我們一般“增”場景的緩存就必不可少。否則藤抡，一篇文章被訪問了十萬次侠碧，代碼層次不會還去做十萬次的數(shù)據(jù)庫操作吧。
數(shù)據(jù)一致性
在很多應用場景中缠黍，當一個數(shù)據(jù)發(fā)生變更的時候弄兜，很多人在考慮怎么樣確保緩存數(shù)據(jù)和數(shù)據(jù)庫中數(shù)據(jù)保存一致性，確保從緩存讀取的數(shù)據(jù)是最新的瓷式。甚至替饿，有人在對應數(shù)據(jù)變更的時候，先更新數(shù)據(jù)庫贸典，然后再去更新緩存视卢。我覺得這個考慮不太現(xiàn)實，一方面這會導致代碼層次邏輯變得復雜廊驼，另外一方面也真想不明白還要緩存干什么了据过。在絕大多數(shù)的應用中，緩存中的數(shù)據(jù)和數(shù)據(jù)庫中的數(shù)據(jù)是不一致的妒挎。即绳锅，我們犧牲了實時性換回了訪問速度。比如酝掩，一篇經(jīng)常訪問的帖子鳞芙，可能這篇帖子已經(jīng)在數(shù)據(jù)庫層次進行了變更。而我們每次訪問的時候庸队，讀取的都是緩存中的數(shù)據(jù)（帖子）。既然是緩存闯割，那么必然是對實時性可以有一定的容忍度的數(shù)據(jù)彻消，容忍度的時間可以是5分鐘，也可以是5小時宙拉，取決于業(yè)務場景的要求宾尚。相反，一定要求是實時性的數(shù)據(jù)庫谢澈，就不應該從緩存里讀取煌贴，比如庫存，再比如價格锥忿。
高可用
自從有了緩存牛郑，代碼每天快樂的去緩存中愉快的玩耍。為什么說高可用呢敬鬓，我們知道緩存為數(shù)據(jù)庫抵擋了很多壓力淹朋，同時也為應用提供了良好的訪問速度笙各。但同時有沒有想過緩存的感受，如果當數(shù)據(jù)庫緩存“罷工”了础芍，這會出現(xiàn)什么后果杈抢？特別在一些高并發(fā)的應用中，數(shù)據(jù)庫層肯定是“消化不良“仑性，最終導致應用全面崩潰惶楼。所以緩存的高可用顯得非常重要。
三诊杆、數(shù)據(jù)庫緩存常見開源技術
要說用于數(shù)據(jù)庫緩存場景的開源技術歼捐，那必然是memcache和redis這兩個中間件。
| 數(shù)據(jù)類型 | 持久性 | 分布式
----|------|---- | -----
memcache | 支持簡單數(shù)據(jù)類型 | 不支持數(shù)據(jù)持久化存儲 | 不支持主從刽辙、不支持sharing（代碼層次通過hash可以實現(xiàn)）
redis | 數(shù)據(jù)類型豐富窥岩，支持set、list等類型| 支持數(shù)據(jù)磁盤持久化存儲|支持主從宰缤，支持sharding(redis 3.0開始支持)
因為都是專注于內存緩存領域颂翼，memcache和redis向來都有爭議。比如性能慨灭，到底是memcache性能好朦乏，還是redis性能更好等。同樣都是內存緩存技術氧骤，它們都有自己的技術特性呻疹。沒有更好的技術，只有更合適的技術筹陵。個人總結一下刽锤，有持久化需求或者對數(shù)據(jù)結構和處理有高級要求的應用，選擇redis朦佩。其他簡單的key/value存儲并思，選擇memcache。所以根據(jù)自身業(yè)務特性语稠，數(shù)據(jù)庫緩存來選擇適合自己的技術宋彼。
暫不說用不用數(shù)據(jù)庫緩存，見過有人把session存儲在數(shù)據(jù)庫中的仙畦，也見過把視頻/文件轉化成二進制存儲在數(shù)據(jù)庫的输涕，這種行為無疑是逆天的。合理應用數(shù)據(jù)庫緩存技術慨畸，且行且珍惜莱坎，切勿走向誤區(qū)。
我為自己帶鹽寸士，原創(chuàng)作者：喬銳杰
