gateway-worker 并發(fā)場景下的查詢結(jié)果混亂,是變量污染問題嗎?

shyer886 更新于2023-12-12

問題描述

gateway-worker 并發(fā)場景下,查詢數(shù)據(jù)庫的結(jié)果返回混亂.

程序代碼

在gateway-worker中實際執(zhí)行的laravel代碼,使用了orm 的with關(guān)聯(lián), 查詢用戶A,B的信息:

$selfUser = User::query()->with('userInfo')->where(['uuid' => $selfUuid])->first();
info('$selfUuid='.$selfUuid);   //查詢用戶A $UUID= 956498 的用戶信息
info($selfUser);

$targetUser = User::query()->with('userInfo')->where(['uuid' => $targetUuid])->first();
info('$targetUuid='.$targetUuid);   //查詢用戶B $UUID= 724129的用戶信息
info($targetUser);

返回的結(jié)果卻是用戶C的信息:

[2023-12-12 14:17:11] prod.INFO: $selfUuid=956498
[2023-12-12 14:17:11] prod.INFO: {"id":3,"uuid":371006,"register_device_type":0,"register_device_imei":"E0B993E56CC","register_ip":"221.234.178.221","created_at":"2023-12-07 16:18:35","updated_at":"2023-12-12 12:18:36","deleted_at":null,"user_info":null}

[2023-12-12 14:17:11] prod.INFO: $targetUuid=724129
[2023-12-12 14:17:11] prod.INFO: {"id":3,"uuid":371006,"register_device_type":0,"register_device_imei":"E0B993E56CC","register_ip":"221.234.178.221","created_at":"2023-12-07 16:18:35","updated_at":"2023-12-12 12:18:36","deleted_at":null,"user_info":null}

框架執(zhí)行時候輸出的sql:

   [2023-12-12 14:17:11] time: 0.08 ms; sql: select * from `user` where (`uuid` = "956498") and `user`.`deleted_at` is null limit 1;    //查詢956498的用戶信息
    [2023-12-12 14:17:11] time: 2.27 ms; sql: select * from `user_info` where `user_info`.`uuid` in ("371006") and `user_info`.`deleted_at` is null;    //with查詢956498用戶的擴展信息, 但是框架執(zhí)行的時候,變成了用戶C的UUID 371006

    [2023-12-12 14:17:11] time: 0.05 ms; sql: select * from `user` where (`uuid` = "724129") and `user`.`deleted_at` is null limit 1;   //查詢 724129 的用戶信息
    [2023-12-12 14:17:11] time: 2.2 ms; sql: select * from `user_info` where `user_info`.`uuid` in ("371006") and `user_info`.`deleted_at` is null; //with查詢 724129 用戶的擴展信息, 但是框架執(zhí)行的時候,變成了用戶C的UUID 371006

重現(xiàn)問題的步驟

此bug不是必現(xiàn),多數(shù)時候框架是正常運行 , 但是一旦觸發(fā)這種混亂查詢 ,就會大面積的使線上其他用戶的查詢, 全部返回這條異常ID的結(jié)果.必須通過重啟gateway-worker,才能使其它人的查詢結(jié)果再次正常.

看了gateway-worker的運行日志,沒有報錯信息.
請教下版主,這種情況是gateway-worker的變量污染嗎?應(yīng)該怎么處理呢?

操作系統(tǒng)環(huán)境及workerman/webman等具體版本

php: 8.1.19
gateway-worker: 3.1.4

 1078  2 0

2個回答

walkor 2023-12-12

打賞

寫業(yè)務(wù)都是臨時變量，不存在變量污染問題。
從你上面的代碼看不會出現(xiàn)錯亂問題。

但是日志記錄可能會錯亂，因為每個進程都在不斷的記錄日志，寫到一個文件里會錯亂是正常的，不影響業(yè)務(wù)。

shyer886 2023-12-12

不是根據(jù)sql日志看出來的代碼異常, 而是代碼本身執(zhí)行的結(jié)果是異常的.所以才輸出sql日志查看,結(jié)果發(fā)現(xiàn)sql語句不對勁.然后重啟gateway-worker結(jié)果集就正常了. 那這個如果不是變量污染的問題,那會不會是MySQL鏈接的問題? 每次出現(xiàn)這種問題, 連調(diào)試都沒法調(diào)試, 比如上述代碼,特別簡答, 就是根據(jù)uid查詢用戶信息, 可是輸入的ID是正確的, 代碼執(zhí)行的結(jié)卻是錯誤的.調(diào)試都沒辦法調(diào)試,而只要一重啟gateway-worker就又好了,能提供幾個方向,啟發(fā)下怎么定位這種問題根源嗎...
shyer886 2023-12-12

像上面的代碼,并不是復雜邏輯,但是打印輸出的結(jié)果就是異常的,也按照手冊裝了event擴展, 改了linux參數(shù), gateway-worker 80%的時間也都是正常運行的, 偶爾會觸發(fā)這種ID查詢的結(jié)果異常的問題, 但每次觸發(fā)這種異常都會大面積影響其他用戶,就只能重啟gateway-worker...而上面的邏輯也沒復雜封裝,實在太過簡單.連調(diào)試都無從調(diào)試起...
walkor 2023-12-12

大概排查方向
1、定時器里不要用$_SESSION超級變量
2、數(shù)據(jù)庫不要在啟動腳本里直接初始化，要在onWorkerStart里初始化
3、看下是不是使用了什么特殊的擴展
shyer886 2023-12-12

看起來②的試錯最快，我按照②①③的順序，先研究下laravel的orm怎么手動在onWorkerStart中初始化，感謝版主的啟示
shyer886 2023-12-13

bug已解決,把所有composer包卸載后,重新require了最簡支撐,未再觸發(fā)此bug,應(yīng)該是之前使用的某個包引起的.感謝版主.

meows 2023-12-13

為毛我感覺你這ORM 寫得不太對呢

with（）查詢幾乎是整個表in(id集合)查詢
你這指定用戶查詢信息不應(yīng)該是

$user = User::where('uid', '724129')->firstOrFail();
$data = $user->load(['userInfo']);

shyer886 2023-12-13

實際執(zhí)行的sql是一樣的,with是查出關(guān)聯(lián)數(shù)據(jù),并在這次調(diào)用時把關(guān)聯(lián)數(shù)據(jù)也返回;load也查了關(guān)聯(lián)數(shù)據(jù),只是并未在這次調(diào)用時返回關(guān)聯(lián)數(shù)據(jù),在后續(xù)使用時才加載而已.預加載和懶加載的區(qū)別.