这篇文章也可以在我的博客中查看
关于本文
专业的流量统计系统能够相对真实地反应网站的访问情况。
这些数据可以在后台很好地进行分析统计，但有时我们希望在网站前端展示一些数据
最常见的情景就是：展示页面的浏览量
这简单的操作当然也可以通过简单的计数器实现，但可能会造成重复统计（比如同一个用户点击10次）
目标
流量分析工具所提供的准确性是不可比拟的
因此这篇文章我们就来实现如何将流量分析数据搬到网站展示，做到：
- 同步流量分析工具数据到网站前端
- 显示页面的阅读量
- 不影响页面加载
- 用户不会感知到同步任务进行
- 不频繁访问分析工具API
- 减少网络资源、API次数消耗
准备
为完成这些目标，需要一些前提准备：
- 配置好带有数据访问API的流量分析工具
- 如
Google Analytics、Umami（本文将以Umami为例） - 这是我们的真实数据来源
- 如
- 配置好WordPress后台进程（Background Process）支持
- 如Action-Scheduler（本文将以此为例）
- 这是我们非阻塞运行的基础
Analytics类
分析问题
API访问频率
阅读量实时性并不强，我们无须（也不可能）每次页面访问都从远程分析工具获取数据
频繁访问很有可能会被禁止访问API，（自建的相当于DDoS攻击自己😅）
在获取数据后，应该在短时间内缓存起来
WordPress中的跨请求缓存API是
transient
处理缓存未命中
但如果缓存未命中怎么办？是立刻访问远程分析工具吗？
不可能，这样同步执行会使页面加载阻塞
特别是：如果你一次展示多篇文章，你需要等待它们全部完成才能加载出页面！
因此我们必须在本地数据库也持久化存储阅读量
这个冗余数据是缓存未命中时的唯一可行数据来源
在WordPress中，我们可以使用
post_meta存储它
与此同时，这也可作为数据过时的标志：
我们应该触发更新阅读量的后台进程
非阻塞地将第三方分析工具的数据同步到本地上
小结
Analytics.php的是用于页面获取数据的接口。它的数据来源是：
- 内存缓存
- 减少短期重复访问，减少服务器压力
- 本地数据库
- 缓存未命中时的保底数据
- 远程分析工具
- 数据更新的途径
它的职责是：
- 读写本地数据
- 发出更新请求
实现
注意组织文件结构，本文将
/App文件夹作为根目录
在/App/Services/Analytics/创建Analytics.php文件
编写Analytics类，它主要包含一些静态函数
namespace App\Services\Analytics {
class Analytics
{
public static function getPageViews(WP_Post|int $post)
{
}
public static function setPageViews(WP_Post|int $postId, $newViews)
{
}
}
}
getPageViews
本文实现需要依赖$post->ID作为唯一标识符
如果你希望实现任何页面的阅读量展示，你需要：
- 使用
url[path]的md5 hash作为唯一标识符- 使用自定义数据库表存储阅读量：
(url_md5, page_view)
需要做什么？
当访客来访时，需要展示阅读量，此时：
- 我们需要获取目标地址的
WP_Post实例- 以获取url等信息
- 有缓存读缓存
- 无缓存读数据库
- （不阻塞执行）请求第三方流量分析API，更新记录
- 马上使用旧数据刷新缓存
前面提到了缓存过期是发出数据同步请求的标志，但我们不希望重复发起请求，
因此缓存未命中时需要马上再次写入缓存。
虽然数据是旧的，但不急。我们可以在数据同步时强制刷新它
大部分都好处理，异步请求比较麻烦，先卖个关子
同时我们还为阅读量定义了缓存键值和在数据库的meta键值：
protected static string $pageViewMetaKey = 'page_views';
protected static int $pageViewCacheTime = HOUR_IN_SECONDS;
protected static function pageViewsCacheKey(int $postId)
{
return static::$pageViewMetaKey . '_' . $postId;
}
public static function getPageViews(WP_Post|int $post)
{
if (!($post instanceof WP_Post))
$post = get_post($post);
if (empty($post)) return 0;
// 尝试获取缓存
$pageViews = get_transient(Analytics::pageViewsCacheKey($post->ID));
if ($pageViews !== false) return $pageViews;
// 读取数据库记录，这将是最后能够返回的值
$pageViews = get_post_meta($post->ID, Analytics::$pageViewMetaKey, true) ?: 0;
if (is_singular()) {
// 记录更新请求
// <-- ?? async call to update ?? -->
// 重写缓存
set_transient(Analytics::pageViewsCacheKey($post->ID), $pageViews, static::$pageViewCacheTime);
}
return $pageViews;
}
为了减少不必要的请求数，我们使用is_singular()确保当前访问的是文章页面
否则文章大概率是被输出为概要、列表，并不存在真的访问，没必要更新
setPageViews
这个函数用于写入本地的数据存储，包括缓存和数据库
注意，它并不包含异步更新的过程，只是异步更新的结果需要借助它写入：
public static function setPageViews(WP_Post|int $postId, $newViews)
{
if ($postId instanceof WP_Post)
$postId = $postId->ID;
// 更新缓存
set_transient(Analytics::pageViewsCacheKey($postId), $newViews, static::$pageViewCacheTime);
// 写到数据库
update_post_meta($postId, Analytics::$pageViewMetaKey, $newViews);
}
Provider
好了，该想想怎么访问远程API了
Analytics因为大多为固定操作，我们实现为静态
但是更新数据来源的逻辑呢？
不同的流量分析工具会提供不同的API，因此我们也需要为它们编写各自的处理逻辑
我们需要根据设置为Analytics注入一个恰当的数据来源实例，这里称为Provider
先关注Analytics类中需要如何支持注入Provider
没使用任何框架，我只能纯手工注入
以下代码是额外增加内容，需要与上文合并
class Analytics
{
private static Closure|AnalyticsProvider $_provider;
public static function setProvider(callable|AnalyticsProvider $provider)
{
if (is_callable($provider))
static::$_provider = Closure::fromCallable($provider);
else
static::$_provider = $provider;
}
protected static function getProvider(): AnalyticsProvider
{
if (static::$_provider instanceof Closure)
static::$_provider = (static::$_provider)();
return static::$_provider;
}
}
我们需要先setProvider设置使用的数据源，后续使用getProvider获取它
因为某些provider可能会很沉重，这里支持传入一个返回AnalyticsProvider的Closure
以实现懒加载，只有需要使用它的时候才会生成
接下来再看看provider需要怎么编写
AnalyticsProvider类
不同的provider有不同的访问逻辑，但至少有没有些共性？
还真有！
需要未雨绸缪的问题
Provider负责组织后台任务，但每次请求更新都立刻组织一个后台任务还是很恐怖的。
比如：一个页面有100篇文章
如果我们需要为每篇文章组织一个任务
此时需要组织100个任务
虽然我们这里使用
is_singluar()限制了只在文章页面发起更新请求（见上文）
但这里讨论的问题是更一般化的
我们编写的代码可不只是为了显示访问量一种数据而已
因为php无守护进程，每个后台任务其实需要通过写数据库进行任务信息持久化
因此组织100个后台任务，意味着访问数据库上百次
而组织任务这个过程，是同步的、阻塞的
用户会看着页面转十秒加载不出来
但说到底，有没有必要把它视为100个任务？不能批处理一下吗？
当然可以，而且这就是不同AnalyticsProvider的一个共性。
实现
在/App/Services/Analytics/创建AnalyticsProvider.php文件
编写Analytics类
namespace App\Services\Analytics {
abstract class AnalyticsProvider
{
}
}
pushUpdatePostViews
这是登记更新任务的逻辑
上文说了，我们不希望立刻生成后台任务，而是记录它：
protected array $updatesList = [];
/**
* 将目标加入浏览量更新任务队列
* @param array $args 查询需要的参数，与具体实现有关
*/
public function pushUpdatePostViews(WP_Post $post, array $args = [])
{
$this->updatesList[$post->ID] = $args;
}
$args主要是请求API时的参数，比如：时间段？目标地址？国家？……
这与具体数据源的实现有关，但总之，我们需要把这些可能用到的数据存到$updatesList里
$updatesList记录了本次请求中，所有需要请求阅读量更新的文章和相应参数
但我们如何把它加到后台任务？
submitTasks()
submitTasks由子类负责给出任务提交的逻辑
父类只需要给出约束
abstract public function submitTasks();
没完，我们需要有人在最后调用这个函数，才能完成所有任务一次性提交
可以利用WordPress的shutdownhook
public function __construct()
{
add_action('shutdown', [$this, 'submitTasks']);
}
因为shutdown是WordPress最后一个hook，因此不用担心之后还会有新的任务提交请求
注意，WordPress hook的回调必须是
public函数
调用
还记得Analytics::getPageViews的空缺位置吗？
它应该调用AnalyticsProvider！
public static function getPageViews(WP_Post|int $post)
{
// ...
if (is_singular()) {
// 记录更新请求
// <-- ?? async call to update ?? -->
static::getProvider()->pushUpdatePostViews($post);
// ...
}
// ...
}
注意：static在上下文中就是Analytics
具体的AnalyticsProvider
主要完成两件事：
- 完成任务提交逻辑
- 封装处理参数
以下我以
Umami为例
在/App/Services/Analytics/Umami创建UmamiAnalyticsProvider.php文件
编写UmamiAnalyticsProvider类：
namespace App\Services\Analytics\Umami {
use WP_Post;
use App\Services\Analytics\AnalyticsProvider;
class UmamiAnalyticsProvider extends AnalyticsProvider
{
public function submitTasks()
{
if ($this->updatesList) {
// <-- ?? submit this background task ?? -->
}
}
public function pushUpdatePostViews(WP_Post $post, array $args = [])
{
$args['path'] = parse_url(get_permalink($post))['path'];
parent::pushUpdatePostViews($post, $args);
}
}
}
Umami API获取阅读量必须提供页面的path，因此我重写pushUpdatePostViews并按id获取了它的pathsubmitTask先检测了是否真有待提交任务数据，如有，提交
- 具体提交逻辑见下文
后台任务
万事俱备，只欠东风
我们只剩下后台任务需要解决了，但你先别急
这篇文章目前只到一半
本文将使用Action Scheduler作为后台任务的驱动
但不管你是否使用它，后文的task结构都可以给你一点灵感
Action-Scheduler
Action Scheduler基本上是WordPress中支持后台进程的唯一选择了
它的官方例子如下：
require_once( plugin_dir_path( __FILE__ ) . '/libraries/action-scheduler/action-scheduler.php' );
/**
* Schedule an action with the hook 'eg_midnight_log' to run at midnight each day
* so that our callback is run then.
*/
function eg_schedule_midnight_log() {
if ( false === as_has_scheduled_action( 'eg_midnight_log' ) ) {
as_schedule_recurring_action( strtotime( 'tomorrow' ), DAY_IN_SECONDS, 'eg_midnight_log', array(), '', true );
}
}
add_action( 'init', 'eg_schedule_midnight_log' );
/**
* A callback to run when the 'eg_midnight_log' scheduled action is run.
*/
function eg_log_action_data() {
error_log( 'It is just after midnight on ' . date( 'Y-m-d' ) );
}
add_action( 'eg_midnight_log', 'eg_log_action_data' );
这个例子将在每天午夜输出一个log
但这例子其实有个坑，Action Scheduler的执行机制事实上跨越了2次php执行：
- 第一次，制定任务
- 使用
as_schedule_recurring_action制定任务 - 此时
eg_midnight_loghook无效
- 使用
- 第二次，午夜时执行任务（可能由cron或其它机制触发）
- 它从数据库中检测到预定的任务，生成
eg_midnight_loghook - 执行
eg_midnight_loghook的逻辑
- 它从数据库中检测到预定的任务，生成
所以坑点就在于add_action( 'eg_midnight_log', 'eg_log_action_data' );必须在执行任务时加入，在制定任务时加入是无效的
而我们的目标，则是：
- 把2次php执行的代码尽可能地透明化，封装起来
- 使用面向对象的思想处理任务，使其模块化
TaskManager类
TaskManager主要用于负责所有任务的提交和触发，我的实现主要针对Action Scheduler，如果使用其它后台任务库，该类需要做对应修改。
在阅读前，建议先了解
Action Scheduler的基本操作
实现
在/App/Services/Task创建TaskManager.php文件
编写TaskManager类：
namespace App\Services\Task {
class TaskManager
{
protected static array $taskList;
public static function init()
{
}
public static function registerTask($taskName)
{
static::$taskList[] = $taskName;
}
public static function submitTask(string $handlerType, array $taskMeta, array $taskParams): int
{
}
}
}
registerTask用于记录所有需要管理的任务名，它的作用只是将名字加入$taskList列表
submitTask
用于提交“保证任务触发时正常执行”所需的一切数据，包括：
- 交给谁处理（给谁处理）
- 执行处理的指引（怎么处理）
- 需要处理的数据（处理什么）
因此它需要传入3个参数：
$handlerType: 承载任务处理逻辑的类名- 后文会详细介绍，它的基类是
Task，包含一个handleTask方法
- 后文会详细介绍，它的基类是
$taskMeta: 承载任务处理的元数据- 比如任务时限？重试次数？
- 反正是与任务相关，但与任务执行主体无关的
$taskParams: 任务执行所需的数据- 比如我们需要访问api，那可能就是api参数等等
因此可以写出这样的代码：
public static function submitTask(string $handlerType, array $taskMeta, array $taskParams): int
{
if (!$handlerType) return 0;
$args = ['handler' => $handlerType, 'meta' => $taskMeta, 'params' => $taskParams];
return as_enqueue_async_action($handlerType::$taskName, $args, md5(json_encode($args)), true);
}
- 使用
Action Scheduler提供的as_enqueue_async_action，将任务数据移交至其托管。 - 所有
$args参数将被Action Scheduler存储于数据库，当执行时取出- 有点像序列化
$taskName是Task类的静态变量，表示任务名- 因为
Task与任务直接关联，因此任务名就存在它那了
- 因为
- 防止完全重复任务
- 标记为唯一任务（第四个参数
unique:true） - 计算参数的md5作为分组，用于识别重复任务
- 标记为唯一任务（第四个参数
init
init需要在每次执行、所有registerTask调用结束后调用，它用于监听后台任务是否已触发，如果是，则分配到相应的处理函数
public static function init()
{
require_once(get_template_directory() . '/vendor/woocommerce/action-scheduler/action-scheduler.php');
/**
* 监听事件触发并转交给handler
*/
foreach (static::$taskList as $taskName) {
add_action($taskName, function (string $handlerType, array $meta, array $params) {
$provider = new $handlerType();
$provider->handleTask($meta, $params);
}, 10, 3);
}
}
首先需要引入Action Scheduler文件，然后对每个注册的任务名，都使用监听函数（这里实现为匿名函数）订阅它的action hook
当事件触发时，这个函数将获得我们从TaskManager::submitTaask()中传入的3个参数：
$handlerType: 任务处理逻辑的类名- 用于动态生成负责处理事件的handler对象
$provider = new $handlerType(); - 调用它的
Task::handleTask方法
- 用于动态生成负责处理事件的handler对象
$meta: 承载任务处理的元数据- 将其转交给handler
$params: 任务执行所需的数据- 将其转交给handler
当某个任务真正触发时，其对应的action hook就会被触发，然后由监听函数转发至真正的执行逻辑
Task类-任务处理类
Task代表了一个任务，它包括：
任务名、任务提交逻辑、任务执行逻辑
实现
在/App/Services/Task创建Task.php文件
编写Task类：
namespace App\Services\Task {
use Exception;
abstract class Task
{
public static string $taskName;
/**
* 提交一个该类型的任务，需要提供必要元数据和执行参数
*/
public static function submitTask(int $maxRetry, array $taskParams)
{
}
/**
* 对应任务触发时的执行逻辑
* @param mixed $taskMeta 任务元数据
* @param mixed $taskParams 任务处理数据
* @throws Exception 若任务未全部完成，抛出异常
*/
public function handleTask(array $taskMeta, array $taskParams)
{
// ...
$this->handle($taskParams);
// ...
}
/**
* 任务逻辑主体
* @param mixed $taskParams 传入给该任务的参数
* @return mixed
*/
protected abstract function handle($taskParams);
}
}
submitTask
submitTask()是对TaskManager提交函数的简单封装：
- 因为自身存储了
$taskName，因此它可以省略TaskManager的第一个参数 - 元数据可以明确限定
- 比如我只需要重试次数，我就只把它当做输入参数，然后封装成
meta
- 比如我只需要重试次数，我就只把它当做输入参数，然后封装成
具体编写为以下逻辑：
public static function submitTask(int $maxRetry, array $taskParams)
{
$taskMeta = ['retry' => $maxRetry];
TaskManager::submitTask(static::class, $taskMeta, $taskParams);
}
handleTask
前面也提到了，handleTask是最终用于处理任务的逻辑
它其实有两个作用：
- 准备、善后处理
- 接受任务元数据，先进行准备
- 处理任务
- 接受任务参数，真正处理任务
在这里，“准备、善后”部分我只用作处理重试逻辑
处理任务的逻辑我把它分割到另一个handle方法，由子类实现
handleTask应在成功时返回假，失败时返回需要任务再次执行所需的参数
public function handleTask(array $taskMeta, array $taskParams)
{
$pushBacks = $this->handle($taskParams);
/**
* 任务失败了，需要重新push任务：
* 1. 有需要执行的东西
* 2. 有retry的定义且不为0
*/
if (!empty($pushBacks)) {
if (!empty($taskMeta['retry'])) {
$taskMeta['retry'] -= 1;
TaskManager::submitTask(static::class, $taskMeta, $pushBacks);
throw new Exception("Retries have been scheduled for some uncompleted tasks. params are: " . var_export($pushBacks, true));
} else
throw new Exception("Some of tasks failed. params are: " . var_export($pushBacks, true));
}
}
exception将由Action Scheduler处理并显示在控制台中
PageViewTask-具体的任务类
真正的功能类继承自Task类，这里需要编写访问远程分析工具，并返回页面浏览量的逻辑
因此命名为PageViewTask
同样地，具体的PageViewTask依靠于具体的远程分析工具API
但在这层抽象中，我们只关注它们的共性：都需要失败重试
实现
在/App/Services/Analytics创建PageViewTask.php文件
编写PageViewTask类：
namespace App\Services\Analytics {
use App\Services\Task\Task;
use Excecption;
abstract class PageViewTask extends Task
{
public static string $taskName = 'nova_page_view_task';
protected function handle($updatesList)
{
foreach ($updatesList as $postId => $args) {
try {
$views = $this->getPostView($args);
Analytics::setPageViews($postId, $views);
// 删掉
unset($updatesList[$postId]);
} catch (\Exception $e) {
// 无视
}
}
return $updatesList;
}
abstract protected function getPostView($args): int;
}
}
首先别忘了我们需要给任务起名$taskName
php的静态多态太爽了
C#什么时候能站起来（）
handle()这段逻辑呼应了我们远古时代实现的AnalyticsProvider::$updatesList逻辑
我们为了节省开销，将多次阅读量更新捆绑成一次提交
因此$updatesList包含的是一个列表的待更新文章
我们在foreach循环中分割成单个更新，再次踢皮球到getPostView交给子类处理
然后更新过程中的try ctach就有点秀了：
- 如果没出意外，我们把它从列表中移除，意为不再需要
- 如果出了意外，将被catch，并跳转到foreach下个循环
所以一顿操作后，最终执行失败的参数会保留在$updateList中
将它返回，则会触发父类的重试逻辑，再次压入后台进程队列
妙妙妙妙妙
具体的PageViewTask
每个远程统计工具实现不同，所以这层是必须的
这里还是以Umami为例，其它的也差不多，只是需要修改访问的参数
在/App/Services/Analytics/Umami创建UmamiPageViewTask.php文件
编写UmamiPageViewTask类：
namespace App\Services\Analytics\Umami {
use Exception;
use App\Services\Analytics\PageViewTask;
class UmamiPageViewTask extends PageViewTask
{
protected function getPostView($args): int
{
// 获取secret
$baseUrl = of_get_option('analytics_api_domain', '');
$authToken = of_get_option('analytics_api_token', '');
// header
$headers = array(
'Authorization' => "Bearer $authToken",
'Content-Type' => 'application/json',
'Accept' => 'application/json',
);
// 向umami发送请求
$umami_url = trailingslashit($baseUrl) . 'stats' . '?' . http_build_query([
'startAt' => '0',
'endAt' => time() . '000',
'url' => $args['path'],
]);
$response = wp_remote_get($umami_url, ["headers" => $headers]);
if (is_wp_error($response))
throw new Exception($response->get_error_message());
if (!empty($response['body']))
$data = json_decode($response['body'], true);
return \intval($data['uniques']['value']) ?? 0;
}
}
}
这段代码因为比较简单，也直接给出了
需要提醒的是：
- 重要数据不要硬编码在代码中，在WordPress中可以使用控制台的设置功能
- 不过这里用到的
of_get_option是装了options framework插件
- 不过这里用到的
- 大部分参数都可以自身构造而来，真正从外部接受的参数其实就只有：
$args['path'] - 我们在
$response为WP_Error时抛出异常，以示意出错- 出错的主要原因是网络连接不佳，因此我们需要抛出错误，并重试
- 返回401,404等不算出错，有返回的情况反而没有重试的必要
- 因为试几次都是一样的
- 返回的处理取决于返回数据，这里是顺着
Umami的返回写的
化身为神的最后一块拼图！
ruaaaaaaaaaaaaaaaaaaaaa
还记得吗？之前的代码有一段空了一块
在UmamiAnalyticsProvider提交任务时，没有给出具体的操作代码
因为当时还没引入后面的一堆
但现在，我们都是懂哥了
加入这句代码，让这个系统运作起来：
class UmamiAnalyticsProvider extends AnalyticsProvider
{
public function submitTasks()
{
if ($this->updatesList) {
// <-- ?? submit this background task ?? -->
UmamiPageViewTask::submitTask(1, $this->updatesList);
}
}
}
调用UmamiPageViewTask::submitTask()
- 参数1：重试1次
- 参数2：更新若干文章的必要数据
初始化
最后，我们需要初始化TaskManager，如果不初始化，没有任务会被监听
不管需不需要加入新任务，请确保每次php执行都会执行以下语句：
use App\Services\Analytics as Analytics;
use App\Services\Task\TaskManager;
Analytics\Analytics::setProvider(new Analytics\Umami\UmamiAnalyticsProvider());
TaskManager::registerTask(Analytics\PageViewTask::$taskName);
TaskManager::init();
- 记得设置
Provider，当然你也可以传入Closure实现懒加载- e.g.
fn() => new UmamiAnalyticsProvider();
- e.g.
- 记得注册（
TaskManager::registerTask）所有可能执行的任务- 注册开销并不大，不要省
- 省了任务绝对执行不了
- 在最后，记得调用
init()，否则不会进行任何实质初始化操作
小结
花了好久，写了这么多
包括代码，包括文章
这过程中不止一次问自己，至于吗？
我最终的答案是肯定的
至于把东西封装到类里吗？多绕啊
确实绕，甚至是俄罗斯套娃
但在理解了绕之后，带来的是可拓展性、可维护性
当然也可以直接一步步写下来
实不相瞒，我第一个版本就是一步步写下去的，根本就没有一个类
但这样做，怎么进行拓展？
不同的代码混在一起，怎么维护？
所以就算是花更多时间，在把这坨屎跑起来之后，都要给它框架化、规则化
消化了这坨小屎，才能避免整个程序变成大屎
框架本身增加复杂性，但它也带来了规则性：
有了框架，就很容易借用相似的逻辑
有了框架，一切东西都井然有序
现在这个版本，你可以随意增加更多的Task，逻辑都是一样的
多舒服啊？
至于把问题想那么复杂吗？
至于访问远程统计工具获取精准数据吗？
至于搞缓存吗？
至于搞后台进程吗？
没错，要实现“显示浏览量”可以很简单
甚至不精准的统计数据，可以增加我网站的显示访问量（草，现在全是个位数）
但当把程序当做一种艺术，它就不能容忍凑合
精益求精，才是工匠精神
347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
