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

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介:

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. 总结

看了本小节之后相信大家都对缓存在时间开发中起到了什么样的作用有了个了解,这一小节的完成,我们的进阶篇也步入尾声了,下一篇是对于进阶篇的总结了,也多谢大家一路的陪伴!

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2月前
|
存储 缓存 NoSQL
Redis缓存设计典型问题
缓存穿透 缓存穿透是指查询一个根本不存在的数据, 缓存层和存储层都不会命中, 通常出于容错的考虑, 如果从存储层查不到数据则不写入缓存层。缓存穿透将导致不存在的数据每次请求都要到存储层去查询, 失去了缓存保护后端存储的意义。
|
2月前
|
缓存 NoSQL Java
微服务框架(十二)Spring Boot Redis 缓存
  此系列文章将会描述Java框架Spring Boot、服务治理框架Dubbo、应用容器引擎Docker,及使用Spring Boot集成Dubbo、Mybatis等开源框架,其中穿插着Spring Boot中日志切面等技术的实现。 本文为Spring Boot集成Redis。 在这篇文章中,我们将配置一个Spring Boot应用程序示例,并将其与Redis Cache 集成。虽然Redis是一个开源是一个开源内存数据结构存储,用作数据库,缓存和消息代理,但本文仅演示缓存集成。
|
3天前
|
缓存 NoSQL Redis
如何在Python中使用Redis或Memcached进行缓存?
如何在Python中使用Redis或Memcached进行缓存?
9 2
|
25天前
|
存储 缓存 NoSQL
Redis--缓存设计与性能优化
Redis--缓存设计与性能优化
|
25天前
|
缓存 监控 NoSQL
Redis缓存保卫战:拒绝缓存击穿的进攻【redis问题 三】
Redis缓存保卫战:拒绝缓存击穿的进攻【redis问题 三】
15 0
|
25天前
|
缓存 监控 NoSQL
Redis缓存雪崩:预防、应对和解决方案【redis问题 二】
Redis缓存雪崩:预防、应对和解决方案【redis问题 二】
44 0
|
25天前
|
缓存 监控 NoSQL
防弹防线:彻底击败Redis缓存穿透问题【redis问题 一】
防弹防线:彻底击败Redis缓存穿透问题【redis问题 一】
32 0
|
25天前
|
存储 监控 NoSQL
Redis 大键问题解析:如何管理和优化巨型数据【redis拓展】
Redis 大键问题解析:如何管理和优化巨型数据【redis拓展】
30 0
|
2月前
|
存储 缓存 NoSQL
Redis 缓存击穿(失效)、缓存穿透、缓存雪崩怎么解决?
Redis 缓存击穿(失效)、缓存穿透、缓存雪崩怎么解决?
35 0
|
2月前
|
canal 缓存 关系型数据库
Springcloud Alibaba使用Canal将Mysql数据实时同步到Redis保证缓存的一致性
canal [kə'næl] ,译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。其诞生的背景是早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。