phalapi-進階篇7(使用快取以及用redis拓展解決實際問題)
#phalapi-進階篇7(使用快取以及用redis拓展解決實際問題)
##前言## 先在這裡感謝phalapi框架創始人@dogstar,為我們提供了這樣一個優秀的開源框架.
當我們在開發一個專案時,我們可能會遇到很多問題,比如訊息推送,傳送郵件,傳送簡訊,以及併發跟不上,這個時候就該輪到常用的快取出手解救我們了,我們接下來來講講快取Redis在實際中的使用,解決實際問題.在這裡是基於redis的基本知識,和簡單看一下PhalApi的redis拓展文件在前來閱讀此小節.
附上:
開源中國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 歡迎大家的加入!