phalapi-进阶篇7(使用缓存以及用redis拓展解决实际问题)

前言

先在这里感谢phalapi框架创始人@dogstar,为我们提供了这样一个优秀的开源框架.

当我们在开发一个项目时,我们可能会遇到很多问题,比如消息推送,发送邮件,发送短信,以及并发跟不上,这个时候就该轮到常用的缓存出手解救我们了,我们接下来来讲讲缓存Redis在实际中的使用,解决实际问题.在这里是基于redis的基本知识,和简单看一下PhalApi的redis拓展文档在前来阅读此小节.

附上:

喵了个咪的博客:w-blog.cn

官网地址: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 欢迎大家的加入!