主题编辑器的页面保存后与实际页面不一致的排查分析(源于并发请求时，后端处理完成顺序与前端请求顺序未完全一致所导致)
1、现在主题编辑器的实现原理为：当编辑器中的某配置项发生变化时，会请求后端的暂存 API，将数据缓存至 Redis 中。当用户点击保存按钮后，会请求后端的保存 API，将会从 Redis 中读取数据存储至 MySQL 中。
2、当用户在快速编辑一些配置项时，可能会出现主题编辑器的页面数据与实际页面不一致的情况。如图1
图1
3、查看网络请求的发起顺序，最后一次请求后端的暂存 API，确定是在请求后端的保存 API 之前。那么可以推测得出的结论是，当在请求后端的保存 API ，后端从 Redis 中读取数据时，最后一次请求后端的暂存 API 还未将数据保存至 Redis 中，此时，读取的是上一次的暂存数据。举例说明如下，时间用毫秒计算：
最后一次请求后端的暂存 API 的发起时间点：2022/11/22 10:38:49.200
请求后端的保存 API 的发起时间点：2022/11/22 10:38:49.300
最后一次请求后端的暂存 API 将数据缓存至 Redis 的时间点：2022/11/22 10:38:49.800
请求后端的保存 API 从 Redis 中读取数据存储至 MySQL 的时间点：2022/11/22 10:38:49.600
4、在网络请求中查看最后一次请求后端的暂存 API的响应时间点：Tue, 22 Nov 2022 02:38:49 GMT。如图2
图2
5、在网络请求中查看请求后端的保存 API的响应时间点：Tue, 22 Nov 2022 02:38:49 GMT。如图3
图3
6、在网络请求中查看最后一次请求后端的暂存 API的时长：686.69 毫秒。如图4
图4
7、在网络请求中查看请求后端的保存 API的时长：380.19 毫秒。如图5
图5
8、现阶段有 2 个方案，第一个方案为前端处理，当用户点击保存按钮后，只有当所有的请求后端的暂存 API 结束后，再请求后端的保存 API。第二个方案为后端处理，只有当所有的请求后端的暂存 API 将数据缓存至 Redis 后，后端的保存 API 才从 Redis 中读取数据存储至 MySQL 中。
9、最终决定采用第二个方案，由后端处理。(1)当后端接收到暂存 API 的请求后，在当前会话中的 key ：update_count 加 1，当将数据缓存至 Redis 后，update_count 减 1。当后端接收到保存 API 的请求后，判断当前会话中的 key ：update_count，如果大于 0 ，则继续等待，在等待中会每间隔 500毫秒 再次判断当前会话中的 key ：update_count，当判断达到 3 次后，继续往后执行。注：1秒= 1000毫秒； 1毫秒= 1000微秒。(2)从 Redis 中读取数据存储至 MySQL 中。
10、暂存 API 中的实现，基于 Redis 的命令：incr、decr 实现如下
/**
* 将 更新计数 中储存的数字值增一
* @param string $sessionId
* @return int
*/
public static function incrUpdateCount(string $sessionId): int
{
$key = self::getUpdateCountKey($sessionId);
$incr = Redis::connection('cache')->incr($key);
Redis::connection('cache')->expire($key, ThemePreviewInterface::TTL);
return $incr;
}
/**
* 将 更新计数 中储存的数字值减一
* @param string $sessionId
* @return int
*/
public static function decrUpdateCount(string $sessionId): int
{
$key = self::getUpdateCountKey($sessionId);
$decr = Redis::connection('cache')->decr($key);
Redis::connection('cache')->expire($key, ThemePreviewInterface::TTL);
return $decr;
}
11、保存 API 中的实现，基于 while 判断，总计判断 3 次
/**
* 获取 更新计数 中储存的数字值
* @param string $sessionId
* @return mixed
*/
public static function getUpdateCount(string $sessionId)
{
return Redis::connection('cache')->get(self::getUpdateCountKey($sessionId));
}
$i = 1;
while (ThemePreview::getUpdateCount($sessionId) !== null && ThemePreview::getUpdateCount($sessionId) > 0 && $i <= 3) {
file_put_contents(storage_path() . '/logs/Publish-' . microtime(true) . '-' . mt_rand() . '.txt', print_r($i, true), FILE_APPEND | LOCK_EX);
usleep(500000); // 延迟执行 0.5 秒
$i++;
}
12、输出的文件如下。1669187163.3346 – 1669187162.8234 = 0.5112。1669187162.8234 – 1669187162.3034 = 0.52。创建时间相差大致为 0.5 秒，符合预期。如图8
图8
Publish-1669187162.3034-776928128.txt Publish-1669187162.8234-549007488.txt Publish-1669187163.3346-885156477.txt
13、在本地环境再次复现，已经无法复现，不过确定生成了文件：Publish-1669188133.9627-720653875.txt，其值为 1。表明在 保存 API 中执行了一次等待。如图9
图9
14、在网络请求中查看最后一次请求后端的暂存 API 的时长：2.79 秒，原因在于本地环境性能不佳。如图10
图10
15、在网络请求中查看请求后端的保存 API 的时长：3.37 秒，其长于暂存 API的时长。如图11
图11
16、不过此方案仍然存在一定的概率丢失数据了。如果暂存接口到达服务器的时间晚于保存接口完成的时间的话。最终决定参考 Shopify 的实现。
17、参考 Shopify 的主题编辑器。查看其请求后端的保存 API，请求与响应变量如下。如图12
图12
{
"eventMetadata": {
"dirtyTransitionCountInSession": 13,
"durationSeconds": 0,
"lastViewport": "desktop",
"pageType": "JSON"
},
"sessionId": "etPGCT4PQr7YyCr87svY9KJz",
"resourceHashes": [
{
"hashValue": "fe8062f520ac1ab9be9a336c76d9f77517551223",
"resourceId": "gid://shopify/OnlineStoreTheme/130440429753"
},
{
"hashValue": "17183337545547076327",
"resourceId": "gid://shopify/OnlineStoreThemeJsonTemplate/index?theme_id=130440429753"
}
],
"ignoreConflicts": null
}
{
"data": {
"onlineStoreThemeEditorSessionPublish": {
"conflicts": null,
"userErrors": [],
"updatedHash": {
"resourceId": "gid:\/\/shopify\/OnlineStoreTheme\/130440429753",
"hashValue": "fe8062f520ac1ab9be9a336c76d9f77517551223",
"__typename": "OnlineStoreResourceHash"
},
"__typename": "OnlineStoreThemeEditorSessionPublishPayload"
}
},
"extensions": {
"cost": {
"requestedQueryCost": 10,
"actualQueryCost": 10,
"throttleStatus": {
"maximumAvailable": 1200.0,
"currentlyAvailable": 1190,
"restoreRate": 60.0
}
}
}
}
18、初步推测，应该与 hashValue 有关系，只有当缓存中的数据的 hashValue 与请求参数中的 hashValue 相等时，才执行保存操作。其保存 API 的时长接近 1.5 秒左右。如图13
图13
19、最终设计如下方案，在暂存接口中，基于请求体内容计算出 hashValue，并保存至 Redis 的 key 中。然后在保存接口中，基于请求参数中的 hashValue 与保存至 Redis 的 hashValue 进行比对，如果相等，则保存。如果不相等，但是 ignoreConflicts 下存在对应的 hashValue，也可以保存。 如果不相等，且 ignoreConflicts 下不存在对应的 hashValue，则不保存，在返回的 conflicts 包含对应的 hashValue。
20、现有的请求与响应。如图14
图14
21、暂存 API 中的实现
/**
* 获取更新时的哈希的缓存键
* @param string $sessionId
* @param string $resourceId
* @return string
*/
private static function getUpdateHashKey(string $sessionId, string $resourceId): string
{
return ThemePreviewInterface::THEME_EDITOR_SESSION_PREFIX . $sessionId . ':' . $resourceId . ':' . ThemePreviewInterface::UPDATE_HASH_KEY;
}
/**
* 保存更新时的哈希
* @param string $sessionId
* @param string $resourceId
* @param string $hashValue
* @return bool
*/
public static function saveUpdateHash(string $sessionId, string $resourceId, string $hashValue): bool
{
return self::getCacheTags($sessionId)->put(self::getUpdateHashKey($sessionId, $resourceId), $hashValue, ThemePreviewInterface::TTL);
}
/**
* 获取更新时的哈希
* @param string $sessionId
* @param string $resourceId
* @return mixed
*/
public static function getUpdateHash(string $sessionId, string $resourceId)
{
return self::getCacheTags($sessionId)->get(self::getUpdateHashKey($sessionId, $resourceId));
}
/**
* 判断哈希值是否与缓存中的相等
* @param string $sessionId
* @param string $resourceId
* @param string $hashValue
* @return bool
*/
public static function isHashEq(string $sessionId, string $resourceId, string $hashValue): bool
{
return self::getUpdateHash($sessionId, $resourceId) == $hashValue;
}
$variables = json_encode($args);
ThemePreview::saveUpdateHash($sessionId, $templateBasename, sha1($variables));
22、保存 API 中的实现
public function __invoke($rootValue, array $args, GraphQLContext $context, ResolveInfo $resolveInfo)
{
$conflicts = null;
$ignoreResourceIds = data_get($args, 'ignoreConflicts.*.resourceId');
$hashValue = $themeId;
foreach ($args['resourceHashes'] as $resourceHash) {
if ($this->isConflict($sessionId, $resourceHash, $ignoreResourceIds)) {
$conflicts[] = [
'resourceId' => $resourceHash['resourceId'],
'hashValue' => $resourceHash['hashValue']
];
continue;
}
if ($resourceHash['resourceId'] == $themeId) {
$hashValue = $resourceHash['hashValue'];
$this->themeConfigLoader->publishSettingsData();
} else {
$this->rawSchemaLoaderAdapter->publishTemplateSettings($resourceHash['resourceId']);
}
}
return [
'conflicts' => $conflicts,
'session' => ['sessionId' => $sessionId],
'updatedHash' => [
'resourceId' => $themeId,
'hashValue' => $hashValue
],
'publishedAt' => $publishedAt
];
}
/**
* 判断哈希值是否冲突
* @param string $sessionId
* @param array $resourceHash
* @param ?array $ignoreResourceIds
* @return bool
*/
private function isConflict(string $sessionId, array $resourceHash, ?array $ignoreResourceIds): bool
{
if (!ThemePreview::isHashEq($sessionId, $resourceHash['resourceId'], $resourceHash['hashValue'])) {
if (!is_array($ignoreResourceIds) || !in_array($resourceHash['resourceId'], $ignoreResourceIds)) {
return true;
}
}
return false;
}
23、第1次请求，当 hashValue 命中时，响应的冲突列表为 null。此时前端不再做处理。如图15
图15
24、第1次请求，当 hashValue 未命中时，响应的冲突列表不为 null。如图16
图16
25、当第1次请求，响应的冲突列表不为 null 时，此时前端需要第2次请求，请求参数不变化。如图17
图17
26、第2次请求，当 hashValue 命中时，响应的冲突列表为 null。此时前端不再做处理。
27、当第2次请求，响应的冲突列表不为 null 时，此时前端需要第3次请求，请求参数 ignoreConflicts 的值与 resourceHashes 保持一致。如图18
28、参考：https://www.shuijingwanwq.com/2022/12/08/7260/ 。在 Laravel 6、Lighthouse 5 中，方法 __invoke 的参数 $args，其内部顺序与前端请求参数不一致。暂存接口最终实现如下
ThemePreview::saveUpdateHash($sessionId, $templateBasename, sha1($context->request()->getContent()));
近期评论