phalapi-進階篇7(使用緩存以及用redis拓展解決實際問題)

#phalapi-進階篇7(使用緩存以及用redis拓展解決實際問題)

##前言## 先在這裏感謝phalapi框架創始人@dogstar,爲咱們提供了這樣一個優秀的開源框架.

當咱們在開發一個項目時,咱們可能會遇到不少問題,好比消息推送,發送郵件,發送短信,以及併發跟不上,這個時候就該輪到經常使用的緩存出手解救咱們了,咱們接下來來說講緩存Redis在實際中的使用,解決實際問題.在這裏是基於redis的基本知識,和簡單看一下PhalApi的redis拓展文檔在前來閱讀此小節.

附上:

官網地址:http://www.phalapi.net/

開源中國Git地址:http://git.oschina.net/dogstar/PhalApi/tree/release

開源中國擴展Git地址:http://git.oschina.net/dogstar/PhalApi-Library

##1. 能解決什麼問題##

當咱們使用一門技術的時候,咱們固然是爲了解決問題纔去使用它的,那麼咱們使用緩存技術Redis能解決什麼具體的問題呢?

##1.1 緩存結果集##

這裏給一個例子你們看一下就會明白緩存結果集是什麼意思

//從緩存redis的clubcache庫中查詢club表where條件是city,city值是$city
$cache = DI()->redis->get_Time('club'.'city'.$city,'clubcache');
//若是查詢到了就直接返回緩存的結果
if($cache){
	return $cache;
}
//若是不存在從數據庫裏面獲取結果真後存入redis緩存key的條件和取值時同樣,最後一個參數爲過時時間
$rs = $this->getORM()->select('*')->where('city',$city)->fetchAll();
DI()->redis->set_Time('club'.'city'.$city,$rs,'clubcache',600);

上面作的事情就是把結果保存600秒,600秒內的再次查詢會獲取同樣的結果

##1.2 隊列處理##

Redis運用到時間中有一個比較關鍵的做用就是他的隊列

咱們先過一下幾個特殊的redis函數

//寫入隊列左邊
set_lPush
//寫入隊列左邊 若是value已經存在，則不添加 
set_lPushx
//寫入隊列右邊
set_rPush
//寫入隊列右邊 若是value已經存在，則不添加
set_rPushx

//讀取隊列左邊
get_lPop
//讀取隊列右邊
get_rPop
//讀取隊列左邊 若是沒有讀取到阻塞必定時間
get_blPop
//讀取隊列右邊 若是沒有讀取到阻塞必定時間
get_brPop

好比咱們在作消息推送,發送郵件,發送短信這類業務的時候,咱們須要請求第三方接口,請求的速度是第三方來決定的,好比微信一個推送接口就是200ms,若是放到咱們的API業務裏面就會出現一個巨大的問題,用戶訪問速度極度降低,解決這類問題的方案就是隊列流程以下

當咱們接收到用戶的推送請求時
			↓
把推送請求加入到隊列API裏面不作任何操做(好比加入到左邊)
			↓
在後臺有一個PHP腳本運行一直在讀取隊列(讀取右邊就是後進後出,若是讀取左邊就是先進先出)
			↓
而後執行響應的推送邏輯

通常咱們的腳本是一個死循環,或者shell定時請求,咱們會採用讀取不到數據是阻塞來解決去不到值循環過快的問題

##1.3 臨時數據存儲##

臨時數據就不須要太多的說明了,舉個例子就夠了

好比咱們獲取驗證碼,咱們須要把驗證碼存到庫中嗎,我以爲是沒有必要的,並且數據庫並很差作過時的操做只能咱們本身判斷

那麼咱們使用redis把驗證碼存入redis 而後給一個過時時間就很好的解決這個問題了

##1.4 數據庫##

把redis做爲數據庫用算是比較深刻的使用了,這裏聊下思想

你們以後service能夠分佈式,可是對於大部分數據庫的分佈式並不容易,因此致使了不少系統到後面拼接堆積在數據庫,固然可使用緩存存儲結果集,可是這種解決方便治標不治本,在和童鞋們探討的時候得出了一個解決方便,就是把redis做爲第一數據庫mysql做爲元數據庫

作了這種操做以後服務器會自動把熱數據同步到redis,把冷數據存放到mysql,當使用到冷數據了在存放到redis,用戶大部分的操做基本是基於redis進行的操做

看成這樣實現的成本比較高要實現redis 數據同步 封裝使用 where查詢 等等須要很大的精力去作,在後期筆者有打算作一個通用的拓展

##2. 規範化使用##

其實以上的類容已經講的差很少了,爲何還有單獨拿出一段來說一講規範呢,由於緩存不像是數據庫當你須要去查看緩存的時候,若是全部的數據都堆積在redis的一個庫,你會很是痛苦

可是redis支持多庫因此須要一套規範來劃分,這裏分享一下我這邊是如何使用的

0~10庫 做爲正常業務庫,也就是推送隊列,臨時數據,每個庫都只存儲一種業務的數據,好比微信推送就存在5庫,而郵件推送的數據就存在6庫,發送驗證碼的臨時數據存儲在3庫,一次類推,若是以爲10個庫還不夠用能夠根據業務增長

10庫以上做爲cache庫用來存儲每張表的結果集數據,或者是其他的數據

全部的key的命名規範必須帶有類型+表名+條件

##3. 總結##

看了本小節以後相信你們都對緩存在時間開發中起到了什麼樣的做用有了個瞭解,這一小節的完成,咱們的進階篇也步入尾聲了,下一篇是對於進階篇的總結了,也多謝你們一路的陪伴!

注:筆者能力有限有說的不對的地方但願你們可以指出,也但願多多交流!

官網QQ交流羣:421032344 歡迎你們的加入!