分类
PHP后端

PHP中什么是生成器(Generator)?怎么使用?

PHP中什么是生成器(Generator)?怎么使用?下面本篇文章带大家深入讲解一下PHP 中的生成器,希望对大家有所帮助!

谈到驾驶,速度并非一切。但在网络上,速度变得与众不同。你的应用程序越快,用户体验越好。这篇文章是关于 PHP 生成器的,那么我们为什么要讨论速度呢?你很快就会发现,生成器在速度和内存的管理上发挥着巨大的作用。

PHP生成器是什么?

生成器是在 PHP 5.5 版本中添加的,它提供了一种简单的方法来遍历数据,而不需要在内存中构建数组。是不是有点疑惑?那举一个例子,展示使用生成器是一个好方式。

首先,创建一个 generator.php 文件,它将贯穿我们整个例子。创建文件之后,我们添加一段代码。

function getRange ($max = 10) {
    $array = [];
    for ($i = 1; $i < $max; $i++) {
        $array[] = $i;
    }
    return $array;
} 

foreach (getRange(15) as $range) {
    echo "Dataset {$range}";
}

我们可以在创建 generator.php 文件所在目录中快速启动一个内置的 PHP 服务器:

php -S localhost:8000

如果用浏览器打开 http://localhost:8000/generator.php ,我们应该看到这样的结果:

这段代码的自解释性并不是太好. 让我们稍微改动一下代码

foreach (getRange(PHP_INT_MAX) as $range) {
    echo "Dataset {$range}";
}

有点遗憾的是 PHP 耗尽了内存. 你能够想到的解决方法可能包括增加 php.ini 文件中 memory_limit 的上限. 不过平心而论,这个脚本既不高效又占用内存, 我们需要的是一个高效且占用内存低的脚本。

使用生成器

让我们在上面定义相同的函数,用相同的值 PHP_INT_MAX 调用它,然后再次运行。但是这一次我们将创建一个生成器函数。

function getRange ($max = 10) {
    for ($i = 1; $i < $max; $i++) {
        yield $i;
    }
}

foreach (getRange(PHP_INT_MAX) as $range) {
    echo "Dataset {$range}";
}

解析 getRange 函数,这次,我们只循环遍历值和 yield 输出。 yield 与返回值类似,因为它也是从函数返回一个值,但唯一的区别是 yield 只会在需要时返回一个值,并且不会尝试将整个数据集保留在内存中。

如果您转到浏览器,您应该会看到页面上显示的数据。给定适当的时间,浏览器最终显示数据。

注意: 生成器只能在函数中使用。

为什么要使用生成器

有时候,我们可能会遇到想要解析一个庞大的数据集(也可能是日志文件),也可能对一个大型数据库的结果集执行计算,等等情况。我们不想让这些数据全部加载到内存中。我们应该尽可能的保存相应的内存状态。数据不一定要很大——无论数据有多小,生成器都是有效的。别忘了,我们的目的是使用更少的内存来尽可能快的处理数据。

总结

生成器提供了难以忽视的显著性的能提升。大多数的时候,我们不需要高配置的服务器来运行代码。我们只需要做一点重构,生成器是非常有用的,我们应该多多使用它们

英文原文地址:

https://scotch.io/tutorials/understanding-php-generators

以上就是PHP中什么是生成器(Generator)?怎么使用?的详细内容,更多请关注php中文网其它相关文章!

分类
PHP后端

使用JWT,封号,踢人,强制用户退出到底怎么实现?

JSON Web Token(JWT)作为目前最流行的跨域认证方案大家都不陌生了吧。很多系统都在使用JWT替代session认证,这两者有啥区别呢?
简言之,JWT是将认证后的数据保存在客户端,session是保存在服务器端。
使用JWT替代session认证后,服务器不用维护session,分布式环境下不需要单点存储session。因为JWT的自解释性,只要验证JWT是否合法就OK啦。大大提升了系统的可扩展性,特别适合当下微服务大行其道的大环境。
加入一个
但是。。。
老板想要实现踢人,封号怎么办呢?
第一个想法就是颁布jwt时,把jwt存到一个中心redis中。每次访问验证jwt时看看redis里是否有这个token,没有这个token就认证失败。踢人封号只用把用户关联的jwt删除掉就ok了!就可以愉快的回家抱媳妇了(抱歉可能你没有)。
且慢,这么玩完全违背了jwt的初衷,服务器又变了有状态了,何苦脱裤子放屁呢,直接用session不就完了?
讲真的jwt的设计也不太适合这样的场景。

那如果我们非要实现强制用户登出要怎么办呢

可以采用类似oauth2.0协议中的做法,认证后颁布2个token,access token和refresh token。

  • access token访问令牌为一个JWT,设置一个较短的过期时间,比如1小时。访问令牌每次调用后端服务都需要携带,往返网络的频率非常高,暴露的可能性就越大,设置较短的过期时间也可以降低安全风险。
  • refresh token刷新令牌,可以不为JWT,设置一个较长的过期时间,比如1个月。刷新令牌主要用来换取新的access token。因为其仅在访问令牌要失效或已经失效时才会被传递给服务端,较长的过期时间并不会有太大的安全风险。颁发token的时候,仅将刷新令牌保存在redis并设置过期时间。当使用刷新令牌换取新的访问令牌时,需要判断redis里是否存在该刷新令牌,如果不存在,则刷新失败,用户就需要重新登录。

客户端要长时间维护登录态,就需要当访问令牌失效后,自动使用刷新令牌获取新的访问令牌。或者在访问令牌失效之前,提前刷新令牌。

现在我们想要踢人,只需要将用户相关的刷新令牌从redis里删除。当前的访问令牌失效后,自然也没有办法再刷新令牌了。从而达到强制用户登出的目的。

这么设计有个缺陷就是强制用户登出不是及时的。需要有一个等待访问令牌过期的时间。如果希望及时性高点,可以将访问令牌的过期时间设置短一点,但刷新token的频率就会升高。这个需要根据自己的业务进行权衡。
每次调用服务api时仍然是原汁原味的jwt无状态认证,无需访问任何中心存储。仅在刷新访问令牌的时候需要访问中心存储。也算是一种折中的方案。