簡介面向同城家政、上門按摩等本地生活服務(wù)場景的預(yù)約系統(tǒng)完整源碼后端基于ThinkPHP與FastAdmin框架前端采用Uniapp實(shí)現(xiàn)微信H5和小程序端適合具備PHP基礎(chǔ)、希望快速搭建可商用預(yù)約平臺(tái)的開發(fā)者或創(chuàng)業(yè)團(tuán)隊(duì)。系統(tǒng)已完整跑通并通過測試包內(nèi)包含公眾號(hào)通知模塊、后端主程序、前端Uniapp源碼、數(shù)據(jù)庫SQL腳本及通知音頻文件運(yùn)行環(huán)境為LinuxNginxphp7.2mysql5.6需安裝fileinfo與redis擴(kuò)展H5屬于公眾號(hào)H5須在微信內(nèi)訪問并配合認(rèn)證服務(wù)號(hào)、微信支付、小程序賬號(hào)完成部署。資源共2000個(gè)文件以JavaScript、Vue組件、Markdown文檔為主輔以JSON、HTML、CSS等配置樣式文件以及SQL、Python輔助腳本整體66.31MB目錄按功能模塊劃分便于快速定位與二次開發(fā)。已有255人學(xué)習(xí)下載參照包內(nèi)說明即可完成環(huán)境搭建、支付與服務(wù)號(hào)配置明顯降低從零開發(fā)聯(lián)調(diào)的踩坑成本。1. 為什么一套thinkphpuniapp的上門預(yù)約源碼能把三個(gè)月工期壓到兩周接到一個(gè)上門家政按摩的需求時(shí)多數(shù)團(tuán)隊(duì)的第一反應(yīng)是拆端用戶端一個(gè)小程序技師端一個(gè)微信小程序后臺(tái)一個(gè)管理系統(tǒng)再來一套H5做分享四端聯(lián)動(dòng)光聯(lián)調(diào)就得一個(gè)月。而thinkphpmysqluniappfastadminuniapp這套組合的思路是后端只有一份PHP負(fù)責(zé)接口和后臺(tái)前端只有一份uniapp代碼同時(shí)編譯成H5、微信小程序和App。后臺(tái)管理用fastadmin二次開發(fā)RBAC權(quán)限、菜單管理、數(shù)據(jù)表格CRUD這些重復(fù)勞動(dòng)直接點(diǎn)出來用。也就是說你真正要寫的只有業(yè)務(wù)層的預(yù)約、派單、支付回調(diào)、結(jié)算這幾個(gè)模塊。這個(gè)方案適合的正是中小本地生活團(tuán)隊(duì)、接外包的獨(dú)立開發(fā)者以及想用最小成本快速驗(yàn)證同城上門模式的初創(chuàng)團(tuán)隊(duì)。它不追求架構(gòu)上的炫技追求的是從拿源碼到跑通首單的速度。2. 選型邏輯這套技術(shù)組合憑什么能扛住上門預(yù)約業(yè)務(wù)2.1 thinkphpfastadmin為什么還是上門預(yù)約類項(xiàng)目的主力選型上門預(yù)約系統(tǒng)這類項(xiàng)目核心業(yè)務(wù)是訂單而訂單系統(tǒng)的首要要求是開發(fā)快、能維護(hù)、招人容易。thinkphp在國內(nèi)中小型項(xiàng)目里的存量非常大中文文檔和社區(qū)問答足夠覆蓋開發(fā)中遇到的絕大多數(shù)問題。對(duì)這個(gè)場景來說生態(tài)比性能重要——你招一個(gè)PHP開發(fā)大概率不用從零教框架你在搜索引擎里搜一個(gè)問題大概率能直接搜到別人踩過的坑。這就是為什么很多同城服務(wù)源碼、外賣源碼、預(yù)約源碼都在thinkphp里做市場已經(jīng)用腳投票了。fastadmin則是建立在thinkphp之上的后臺(tái)開發(fā)框架。它解決的痛點(diǎn)和上門預(yù)約項(xiàng)目高度相關(guān)后臺(tái)要管理用戶、技師、訂單、服務(wù)項(xiàng)目、優(yōu)惠券、提現(xiàn)申請(qǐng)……這些本質(zhì)上都是數(shù)據(jù)表格。fastadmin提供了一鍵生成CRUD的功能你在數(shù)據(jù)庫建好表后臺(tái)就能自動(dòng)生成對(duì)應(yīng)的菜單、控制器、模型和視圖模板。對(duì)于技師審核、訂單列表、資金流水這類管理頁面幾乎不用手寫。我一般接手這類項(xiàng)目時(shí)第一步是先把fastadmin后臺(tái)跑起來看它的菜單結(jié)構(gòu)再?zèng)Q定哪些表直接生成CRUD哪些表需要寫自定義接口。這比從零搭后臺(tái)至少省一半工作量。還有一個(gè)關(guān)鍵點(diǎn)是權(quán)限。上門預(yù)約系統(tǒng)需要區(qū)分總管理、商家/門店管理、財(cái)務(wù)、客服這些角色。fastadmin自帶RBAC權(quán)限管理每個(gè)角色分配菜單和操作權(quán)限這套機(jī)制是現(xiàn)成的。如果自己寫角色-權(quán)限-菜單三張關(guān)聯(lián)表加上中間的邏輯校驗(yàn)又是兩三天的活。省下來的時(shí)間投到業(yè)務(wù)里去。2.2 uniapp一套代碼覆蓋H5、微信小程序和App的編譯鏈路上門預(yù)約系統(tǒng)的前端有一個(gè)特點(diǎn)用戶可能在微信里搜小程序進(jìn)來也可能從朋友圈的H5鏈接進(jìn)來技師端又往往需要裝App。如果用原生開發(fā)這三端各寫一遍維護(hù)壓力巨大。uniapp的價(jià)值就在這里——一套vue語法的代碼通過不同的編譯配置分別產(chǎn)出微信小程序包、H5頁面和原生App包。我在實(shí)際項(xiàng)目中一般把前端分成兩個(gè)uniapp工程一個(gè)是用戶端包含首頁、服務(wù)分類、下單、訂單列表、支付、評(píng)價(jià)另一個(gè)是技師端包含接單大廳、訂單詳情、導(dǎo)航、結(jié)算記錄、提現(xiàn)。兩個(gè)工程共用公共組件和接口封裝但頁面和登錄邏輯分開。用戶端用微信授權(quán)登錄H5端用手機(jī)號(hào)驗(yàn)證碼登錄不同端之間的差異通過條件編譯處理。條件編譯是uniapp里比較重要的一個(gè)機(jī)制。比如支付邏輯小程序端需要調(diào)起wx.requestPaymentH5端走的是公眾號(hào)支付或掃碼支付。代碼里可以這樣處理// #ifdef MP-WEIXIN uni.requestPayment({ provider: wxpay, orderInfo: res.data.payParams, success: () this.loadOrderDetail() }); // #endif // #ifdef H5 window.location.href res.data.payUrl; // #endif這段代碼的邏輯是編譯到微信小程序時(shí)只保留MP-WEIXIN塊調(diào)用小程序原生的支付接口編譯到H5時(shí)只保留H5塊直接跳轉(zhuǎn)到支付鏈接。這樣支付這種強(qiáng)平臺(tái)差異的邏輯就分開了頁面結(jié)構(gòu)和業(yè)務(wù)邏輯則完全復(fù)用。新人在接這類項(xiàng)目時(shí)最容易出問題的地方就是分不清哪些代碼是跨端通用的哪些是端特有的。我的經(jīng)驗(yàn)是只管接口和渲染的代碼盡量寫通用一碰到登錄、支付、地理位置、文件上傳這類邊界能力馬上用條件編譯隔離。2.3 mysqlredis的分工哪些數(shù)據(jù)必須走數(shù)據(jù)庫哪些走緩存上門預(yù)約系統(tǒng)的數(shù)據(jù)可以分成兩層一層是訂單、用戶賬戶、技師資料、交易流水這些是核心業(yè)務(wù)數(shù)據(jù)必須保證強(qiáng)一致一律放mysql另一層是驗(yàn)證碼、token會(huì)話、在線狀態(tài)、首頁熱門技師緩存這些允許短暫過期和延遲放redis是常規(guī)做法。mysql這邊有一個(gè)值得注意的點(diǎn)所有的訂單狀態(tài)變更都應(yīng)該用事務(wù)條件更新來保證安全。比如用戶取消訂單、技師接單、平臺(tái)關(guān)閉訂單三者的本質(zhì)都是把某個(gè)狀態(tài)的訂單變成另一個(gè)狀態(tài)必須確保同一時(shí)刻只有一個(gè)操作能成功。事務(wù)在這里是底線。redis的作用則更偏提速和限流。上門預(yù)約系統(tǒng)里最典型的redis應(yīng)用是短信驗(yàn)證碼的發(fā)送間隔控制同一個(gè)手機(jī)號(hào)60秒內(nèi)只能發(fā)一次直接在redis里存一個(gè)key設(shè)置有效期60秒發(fā)送前先查這個(gè)key。另一個(gè)典型應(yīng)用是技師端接單大廳的訂單列表緩存——新訂單寫入mysql后同步寫一條到redis列表技師端輪詢接口優(yōu)先讀redis減輕mysql的查詢壓力。緩存和數(shù)據(jù)庫之間的一致性我的做法是只在非關(guān)鍵路徑上用緩存訂單狀態(tài)、賬戶余額這種敏感數(shù)據(jù)絕不先進(jìn)緩存再落庫直接寫mysql讀也直接讀mysql。為省那么一點(diǎn)查詢壓力引入數(shù)據(jù)不一致的坑不值得。2.4 為什么不用微服務(wù)單體架構(gòu)對(duì)這個(gè)業(yè)務(wù)到底夠不夠很多開發(fā)者拿到這類項(xiàng)目后會(huì)問訂單、用戶、支付、技師管理是不是應(yīng)該拆成微服務(wù)這里要給個(gè)明確的結(jié)論同城上門預(yù)約的流量模型是典型的脈沖式峰值QPS大概率在幾十到幾百之間單體架構(gòu)完全扛得住。拆微服務(wù)帶來的服務(wù)發(fā)現(xiàn)、分布式事務(wù)、鏈路追蹤這些問題對(duì)一支三五個(gè)人的開發(fā)團(tuán)隊(duì)來說是負(fù)擔(dān)而不是收益。我傾向于這樣看架構(gòu)業(yè)務(wù)量級(jí)沒到一個(gè)模塊單獨(dú)部署一臺(tái)機(jī)器之前保持單體但把模塊在代碼層面拆清楚。比如fastadmin里的應(yīng)用目錄按模塊組織admin后臺(tái)、api接口、job隊(duì)列各自獨(dú)立邏輯上已經(jīng)分離了。等哪天真需要拆先把a(bǔ)pi模塊抽出來獨(dú)立部署其他模塊保持原樣遷移成本是可控的。這套組合選型的最終理由是它能讓你把有限的開發(fā)資源全部投到業(yè)務(wù)邏輯里而不是基礎(chǔ)設(shè)施里。3. 把上門預(yù)約系統(tǒng)從源碼跑成本地可用的完整步驟3.1 環(huán)境準(zhǔn)備PHP版本、擴(kuò)展和nginx偽靜態(tài)上門預(yù)約系統(tǒng)的源碼跑起來之前先確認(rèn)本機(jī)環(huán)境。PHP建議用7.2到7.4之間的版本這既是thinkphp 5.x系列最穩(wěn)妥的運(yùn)行區(qū)間也兼容fastadmin第三方的絕大多數(shù)插件。需要用到的擴(kuò)展包括pdo_mysql、redis、fileinfo、openssl、gd。其中fileinfo在部分環(huán)境下默認(rèn)沒開thinkphp的文件上傳和圖片處理會(huì)用到漏了會(huì)報(bào)Class finfo not found。redis擴(kuò)展也常被忽略但驗(yàn)證碼和token依賴它后面會(huì)專門說。PHP環(huán)境就緒后設(shè)置php.ini里的兩個(gè)參數(shù)date.timezone Asia/Shanghai post_max_size 100M upload_max_filesize 20M時(shí)區(qū)必須顯式配置。PHP默認(rèn)是UTCmysql默認(rèn)又是系統(tǒng)時(shí)區(qū)兩個(gè)不一致訂單創(chuàng)建時(shí)間、技師接單時(shí)間全都會(huì)歪8個(gè)小時(shí)查數(shù)據(jù)時(shí)翻車概率很高。upload相關(guān)的兩個(gè)參數(shù)是為了后臺(tái)上傳服務(wù)項(xiàng)目圖片、技師頭像時(shí)不至于被大小限制卡住。接下來是nginx的偽靜態(tài)配置。thinkphp的URL訪問方式是入口文件index.php加上路由參數(shù)nginx默認(rèn)配置下訪問https://域名/order/detail?id1這類地址時(shí)nginx會(huì)嘗試找order目錄下的detail文件結(jié)果404。必須在server塊里加上重寫規(guī)則server { listen 80; server_name your.domain.com; root /path/to/your-project/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 30d; } }這段配置的邏輯是當(dāng)請(qǐng)求的文件不存在時(shí)把路徑交給index.php處理并作為參數(shù)s傳遞php文件由fastcgi處理靜態(tài)資源單獨(dú)設(shè)置30天緩存減輕接口服務(wù)器壓力。參數(shù)方面root指向的是項(xiàng)目下的public目錄而不是項(xiàng)目根目錄這是thinkphp的安全要求public之外的目錄不允許被直接訪問。fastcgi_pass的端口要和你本機(jī)php-fpm的listen端口一致默認(rèn)9000如果改動(dòng)過要同步。3.2 導(dǎo)入數(shù)據(jù)庫與后臺(tái)初始化從SQL文件到第一個(gè)管理員賬號(hào)源碼包一般會(huì)帶一個(gè).sql格式的數(shù)據(jù)庫備份文件。操作前先創(chuàng)建一個(gè)utf8mb4編碼的數(shù)據(jù)庫編碼用utf8mb4是為了正確存儲(chǔ)用戶昵稱里的emoji字符。然后導(dǎo)入SQL文件mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS house_service DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p house_service house_service.sql命令說明第一條命令創(chuàng)建數(shù)據(jù)庫第二條把備份文件里的表結(jié)構(gòu)和初始數(shù)據(jù)灌入。導(dǎo)入過程如果報(bào)錯(cuò)常見原因是sql文件里包了創(chuàng)建數(shù)據(jù)庫語句或者是mysql版本差異導(dǎo)致語法不兼容。遇到這種情況直接用可視化工具導(dǎo)入更省心導(dǎo)入后再確認(rèn)一下表數(shù)量和數(shù)據(jù)量避免中途中斷導(dǎo)致缺表。數(shù)據(jù)庫導(dǎo)入后配置項(xiàng)目根目錄下的.env文件或application/database.php。核心是數(shù)據(jù)庫連接信息// application/database.php 中的連接配置 return [ type mysql, hostname 127.0.0.1, database house_service, username root, password your_password, hostport 3306, prefix fa_, charset utf8mb4, ];注意prefix這個(gè)參數(shù)它對(duì)應(yīng)數(shù)據(jù)表前綴。fastadmin的數(shù)據(jù)表默認(rèn)前綴是fa_例如fa_order、fa_technician。如果導(dǎo)入的表還是源碼自帶的前綴這里就不動(dòng)如果手動(dòng)改過表名前綴這里必須保持同步否則模型查詢時(shí)找不到表。表前綴不一致是拿到新項(xiàng)目后最常見的啟動(dòng)報(bào)錯(cuò)原因看到table not exists先查這里。后臺(tái)初始化在瀏覽器訪問http://127.0.0.1/install.phpfastadmin會(huì)引導(dǎo)你設(shè)置管理員賬號(hào)和密碼。安裝完成后后臺(tái)入口一般是http://127.0.0.1/admin.php。管理員登錄后第一件事是檢查菜單管理是否完整其次是權(quán)限管理里的角色是否可用。如果登錄后空白頁或者報(bào)權(quán)限錯(cuò)誤基本都是后臺(tái)菜單緩存或權(quán)限緩存沒生成清掉runtime目錄下的緩存文件再刷新。3.3 前端uniapp編譯到H5和小程序manifest配置與接口域名前端工程是uniapp項(xiàng)目用HBuilderX或命令行工具打開。編譯到H5之前必須修改manifest.json里的配置。H5模塊需要設(shè)置路由模式小程序模塊需要填A(yù)ppID——如果還沒有小程序AppID在微信公眾平臺(tái)注冊(cè)一個(gè)測試號(hào)即可。另一個(gè)容易漏的是小程序后臺(tái)的request合法域名配置這個(gè)放到避坑章節(jié)詳細(xì)說。接口請(qǐng)求地址統(tǒng)一封裝在一個(gè)工具文件里下面是實(shí)際項(xiàng)目里常用的寫法// utils/request.js const BASE_URL https://api.yourdomain.com; export function request(path, data {}, method POST) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json, Token: uni.getStorageSync(token) }, success: (res) { resolve(res.data); }, fail: (err) { reject(err); } }); }); }這個(gè)封裝把三件事統(tǒng)一了接口前綴統(tǒng)一、token自動(dòng)帶上、返回結(jié)果統(tǒng)一走Promise。實(shí)際開發(fā)中所有業(yè)務(wù)模塊都引用這個(gè)request函數(shù)不要在每個(gè)頁面里直接調(diào)uni.request否則后續(xù)要改接口地址或者加統(tǒng)一錯(cuò)誤處理時(shí)就得全局搜索替換。BASE_URL對(duì)應(yīng)的是后端api模塊的地址本地聯(lián)調(diào)時(shí)先指向本機(jī)IP加端口編譯發(fā)布時(shí)再改成正式域名。3.4 前后端聯(lián)調(diào)打通從登錄到首單的接口路徑環(huán)境全準(zhǔn)備好后按一條鏈路驗(yàn)證整個(gè)前后端是否打通用戶登錄、獲取服務(wù)項(xiàng)目、提交預(yù)約、技師接單、生成訂單。這條鏈路走通系統(tǒng)就算跑起來了。我一般會(huì)先在后端api模塊里寫一個(gè)ping接口驗(yàn)證網(wǎng)絡(luò)鏈路// application/api/controller/Test.php public function ping() { return json([code1, msgpong, timetime()]); }前端瀏覽器或微信開發(fā)者工具請(qǐng)求http://localhost/thinkphp/public/index.php/api/test/ping能拿到JSON就說明后端可用。這里要提醒一點(diǎn)如果是本地聯(lián)調(diào)H5瀏覽器直接請(qǐng)求http://localhost的php接口通常是通的但小程序開發(fā)者工具有自己的限制后面避坑章節(jié)展開講。接下來按業(yè)務(wù)流程逐項(xiàng)測試手機(jī)號(hào)驗(yàn)證碼登錄、服務(wù)項(xiàng)目列表、提交預(yù)約單、模擬技師端接單。每測試一個(gè)接口都在mysql里查一下對(duì)應(yīng)表的數(shù)據(jù)變化確認(rèn)寫庫成功再進(jìn)入下一步。前后端聯(lián)調(diào)的常見問題十有八九出在參數(shù)名不一致上php端讀的是tech_id前端傳成technician_id接口返回參數(shù)錯(cuò)誤。我的習(xí)慣是先打開php的DEBUG模式把真實(shí)報(bào)錯(cuò)暴露出來再逐個(gè)接口對(duì)齊參數(shù)名。聯(lián)調(diào)通過之后再把DEBUG關(guān)掉避免線上暴露敏感信息。4. 上門預(yù)約系統(tǒng)核心業(yè)務(wù)訂單狀態(tài)、搶單邏輯與同城距離排序4.1 訂單狀態(tài)機(jī)讓狀態(tài)的每一次流轉(zhuǎn)都有據(jù)可查上門預(yù)約系統(tǒng)的訂單和標(biāo)準(zhǔn)電商訂單有本質(zhì)差異多了一個(gè)上門的物理過程。一次完整的服務(wù)要經(jīng)過用戶提交預(yù)約、平臺(tái)或技師接單、技師上門、正在服務(wù)、服務(wù)完成待評(píng)價(jià)、結(jié)算完成中間還穿插用戶取消、技師取消、超時(shí)未接自動(dòng)取消等多種分支。把這個(gè)流程管理好訂單模塊就穩(wěn)了一半。狀態(tài)清單和允許的流轉(zhuǎn)方向如下狀態(tài)含義允許流轉(zhuǎn)到0待支付1-待接單、-1-已取消1待接單2-待服務(wù)、-1-已取消2待服務(wù)3-服務(wù)中、-1-已取消3服務(wù)中4-待評(píng)價(jià)4待評(píng)價(jià)5-已完成5已完成無-1已取消無注意待支付可以直接跳待接單而不是經(jīng)過已支付這個(gè)狀態(tài)。這里是為了和支付回調(diào)對(duì)齊用戶支付成功回調(diào)里直接把狀態(tài)改成待接單同時(shí)更新支付時(shí)間和第三方流水號(hào)。把已支付省掉能減少一次狀態(tài)流轉(zhuǎn)也避免出現(xiàn)已支付但沒進(jìn)待接單的中間態(tài)。我在項(xiàng)目里見過這個(gè)坑問題不大但排查時(shí)很繞。狀態(tài)流轉(zhuǎn)的校驗(yàn)必須在后端做不能依賴前端傳state直接update。一個(gè)簡單的狀態(tài)機(jī)控制類// application/common/model/OrderStatus.php class OrderStatus { const UNPAID 0; const PENDING 1; const TO_SERVE 2; const SERVING 3; const WAIT_COMMENT 4; const COMPLETED 5; const CANCELED -1; private static $flows [ self::UNPAID [self::PENDING, self::CANCELED], self::PENDING [self::TO_SERVE, self::CANCELED], self::TO_SERVE [self::SERVING, self::CANCELED], self::SERVING [self::WAIT_COMMENT], self::WAIT_COMMENT [self::COMPLETED], ]; public static function canChange($from, $to) { return isset(self::$flows[$from]) in_array($to, self::$flows[$from]); } }這段代碼定義了訂單狀態(tài)的全集和每個(gè)狀態(tài)允許跳轉(zhuǎn)到的目標(biāo)狀態(tài)。所有修改訂單狀態(tài)的地方先調(diào)canChange校驗(yàn)不通過就直接拒絕。這樣即使前端被改過、接口被惡意調(diào)用訂單也不會(huì)進(jìn)入非法狀態(tài)。值得注意的是狀態(tài)變更接口對(duì)外提供時(shí)只能接受當(dāng)前狀態(tài)目標(biāo)狀態(tài)訂單號(hào)絕不能直接把整個(gè)訂單對(duì)象傳上來讓你自由更新字段那是自尋死路。4.2 技師搶單的并發(fā)控制為什么直接update比先select再update可靠技師端接單大廳的核心操作是搶單而搶單的本質(zhì)是并發(fā)競爭一個(gè)資源。兩個(gè)技師同時(shí)看到同一個(gè)訂單都點(diǎn)了接單如果代碼寫成先select查狀態(tài)再update改狀態(tài)就會(huì)出大問題。兩個(gè)請(qǐng)求幾乎同時(shí)讀到status為1都認(rèn)為訂單可接然后各自執(zhí)行update后執(zhí)行的覆蓋先執(zhí)行的一個(gè)訂單被兩個(gè)技師同時(shí)接走。這屬于典型的競態(tài)條件。正確做法是單條SQL原子更新把狀態(tài)檢查放進(jìn)update的where條件里// application/api/controller/Order.php 技師接單 public function accept() { $orderId $this-request-post(order_id); $techId $this-request-post(tech_id); $result Db::name(order) -where(id, $orderId) -where(status, OrderStatus::PENDING) -update([ status OrderStatus::TO_SERVE, tech_id $techId, accept_time time(), ]); if ($result 1) { // 影響行數(shù)為1說明本次更新成功訂單歸這位技師 return json([code 1, msg 接單成功]); } // 影響行數(shù)為0說明訂單狀態(tài)已不是待接單被別的技師搶了 return json([code 0, msg 手慢了訂單已被接走]); }這個(gè)寫法的精妙之處在于where里帶了status條件數(shù)據(jù)庫行鎖在更新時(shí)會(huì)再次校驗(yàn)where條件只有狀態(tài)仍是1的記錄才會(huì)被更新返回值影響行數(shù)是1否則影響行數(shù)是0。不需要事務(wù)不需要redis鎖一條SQL就把并發(fā)問題解決了。這是這類項(xiàng)目里最值得記住的寫法比引入分布式鎖簡單得多也穩(wěn)得多。再說一下redis鎖在什么情況下才需要當(dāng)一個(gè)操作涉及多張表的多個(gè)步驟且必須在整個(gè)過程中獨(dú)占資源時(shí)才需要考慮鎖。比如用戶余額提現(xiàn)到微信錢包需要凍結(jié)余額、創(chuàng)建提現(xiàn)單、調(diào)第三方接口這串操作需要一把鎖保護(hù)。而單純搶單這種單表單字段的變更原子update就夠了。不要把所有并發(fā)問題都甩給redis很多問題的正解就在數(shù)據(jù)庫本身。4.3 同城距離計(jì)算經(jīng)緯度排序在mysql里的高效寫法同城兩個(gè)字是這類系統(tǒng)的業(yè)務(wù)核心。上門預(yù)約服務(wù)里用戶看到技師列表時(shí)一般有兩個(gè)訴求只看到同一個(gè)城市的技師并且按照距離從近到遠(yuǎn)排序。城市過濾用city_id字段即可難點(diǎn)在距離排序。同城業(yè)務(wù)的覆蓋范圍通常在一個(gè)城市內(nèi)部經(jīng)緯度差異不大這時(shí)可以用haversine公式的簡化形式在mysql里直接算距離并排序。下面這段SQL在幾千技師的數(shù)據(jù)量下性能可以接受SELECT id, name, avatar, lat, lng, 6371 * 2 * ASIN(SQRT( POWER(SIN((:user_lat - lat) * PI() / 360), 2) COS(:user_lat * PI() / 180) * COS(lat * PI() / 180) * POWER(SIN((:user_lng - lng) * PI() / 360), 2) )) AS distance FROM fa_technician WHERE city_id :city_id AND status 1 HAVING distance 10 ORDER BY distance ASC LIMIT 20;參數(shù)說明user_lat和user_lng是用戶當(dāng)前定位的經(jīng)緯度city_id是用戶所選城市distance的單位是公里HAVING distance 10表示只顯示10公里內(nèi)的技師。這段SQL的代價(jià)是每條記錄都做三角函數(shù)運(yùn)算在技師表數(shù)據(jù)量超過幾萬時(shí)響應(yīng)會(huì)變慢但同城業(yè)務(wù)單城市技師數(shù)通常不會(huì)到這個(gè)量級(jí)所以前期完全夠用。如果技師數(shù)增長到十萬級(jí)再考慮引入按經(jīng)緯度網(wǎng)格分區(qū)或使用空間索引不要一開始就上重型方案。數(shù)據(jù)量上來后常見的優(yōu)化手段是粗篩后精算第一步用經(jīng)緯度差做一個(gè)方形框過濾把計(jì)算限定在一個(gè)小矩形區(qū)域里第二步只對(duì)框內(nèi)記錄做精準(zhǔn)的距離計(jì)算。方形框的邊界值用固定比例估算一個(gè)經(jīng)度約111公里緯度約111乘以cos緯度公里來算。這個(gè)優(yōu)化可以直接在一開始就寫進(jìn)SQL里把三角函數(shù)計(jì)算量降一個(gè)量級(jí)。5. 上門預(yù)約系統(tǒng)避坑記錄5個(gè)上線前后最容易翻車的現(xiàn)場5.1 小程序請(qǐng)求接口直接失敗連失敗回調(diào)都不觸發(fā)現(xiàn)象H5端一切正常換成微信開發(fā)者工具后所有接口請(qǐng)求都報(bào)request:fail。原因微信小程序?qū)W(wǎng)絡(luò)請(qǐng)求有域名限制正式環(huán)境要求request的url必須是HTTPS且在微信公眾平臺(tái)后臺(tái)配置過request合法域名開發(fā)環(huán)境下雖然可以勾選不校驗(yàn)合法域名但前端代碼里的接口地址如果是http://localhost或http://192.168.x.x這類本機(jī)地址在真機(jī)預(yù)覽時(shí)依然會(huì)被攔截。解決本地調(diào)試時(shí)在微信開發(fā)者工具的詳情設(shè)置里勾選不校驗(yàn)合法域名、web-view業(yè)務(wù)域名、TLS版本以及HTTPS證書要真機(jī)預(yù)覽則需把接口部署到一臺(tái)有公網(wǎng)地址且已配置HTTPS證書的服務(wù)器上并在小程序管理后臺(tái)添加合法域名。另外注意小程序要求TLS版本不能低于1.2部分老服務(wù)器上自簽證書或舊openssl配置會(huì)在這里卡住。5.2 thinkphp在nginx下訪問任何非首頁路由都404現(xiàn)象首頁能打開但訪問http://域名/order/list這類地址時(shí)nginx直接返回404后端接口全掛。原因nginx沒有配置thinkphp的偽靜態(tài)規(guī)則nginx在找不到對(duì)應(yīng)文件時(shí)按自身默認(rèn)行為處理沒有把路徑轉(zhuǎn)交給index.php。解決在nginx的server配置里加上rewrite規(guī)則核心是if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; }。改完配置后reload nginx不要忘記。還有一個(gè)容易踩的細(xì)節(jié)點(diǎn)thinkphp的入口文件是public/index.php如果root配置指向了項(xiàng)目根目錄而不是public目錄即使rewrite正確也會(huì)報(bào)錯(cuò)因?yàn)閕ndex.php不在根目錄下也等于把非public目錄里的文件暴露了出去。5.3 mysql時(shí)間差8小時(shí)訂單時(shí)間、技師服務(wù)時(shí)間全錯(cuò)位現(xiàn)象后臺(tái)看到的訂單創(chuàng)建時(shí)間比實(shí)際時(shí)間慢8個(gè)小時(shí)技師端顯示的預(yù)約時(shí)間也偏移。原因PHP的默認(rèn)時(shí)區(qū)是UTCmysql的默認(rèn)時(shí)區(qū)取決于服務(wù)器系統(tǒng)配置。PHP寫入的時(shí)間戳在mysql里顯示出來會(huì)因?yàn)闀r(shí)區(qū)換算產(chǎn)生8小時(shí)偏移。解決先確保php.ini中配置date.timezone Asia/Shanghai再確認(rèn)mysql的時(shí)區(qū)設(shè)置可以執(zhí)行SQL查詢select now();如果結(jié)果和服務(wù)器本地時(shí)間不一致在mysql配置文件的[mysqld]段加一行default-time-zone08:00。兩個(gè)地方都對(duì)齊之后再測試一遍。這個(gè)問題玄學(xué)的地方在于本地開發(fā)可能不出現(xiàn)一部署到云服務(wù)器就出現(xiàn)因?yàn)樵品?wù)器默認(rèn)時(shí)區(qū)往往是UTC。5.4 技師端輪詢接口打垮服務(wù)器沒有增量拉取的搶單大廳現(xiàn)象上線第一天技師端接單大廳接口的響應(yīng)從50毫秒漲到3秒服務(wù)器CPU持續(xù)跑滿mysql連接數(shù)被打滿。原因技師端每3秒輪詢一次訂單列表每次都返回全量待接單訂單幾百個(gè)技師同時(shí)輪詢瞬間打出的查詢量遠(yuǎn)超mysql承受能力。解決輪詢接口改成增量拉取。前端記錄上一次請(qǐng)求返回的最大訂單ID下一次請(qǐng)求帶上這個(gè)ID后端只返回ID大于它的新訂單和狀態(tài)有變更的訂單。這個(gè)方案能在不引入websocket的前提下把服務(wù)器壓力降低一個(gè)量級(jí)。改造后同樣規(guī)模的并發(fā)接口響應(yīng)時(shí)間恢復(fù)到100毫秒以內(nèi)。這里要特別強(qiáng)調(diào)不要一上來就上websocket方案先把輪詢的增量邏輯做對(duì)大多數(shù)同城預(yù)約場景的實(shí)時(shí)性要求根本用不上長連接。5.5 并發(fā)搶單出現(xiàn)一單多接先查后改的代碼寫錯(cuò)了位置現(xiàn)象兩個(gè)技師都收到接單成功的通知后臺(tái)查詢訂單發(fā)現(xiàn)tech_id字段被后操作的技師覆蓋。原因接單接口寫成了先select查詢訂單狀態(tài)、判斷可接、再update更新狀態(tài)的三段式。兩個(gè)并發(fā)請(qǐng)求同時(shí)讀到status為待接單都通過了判斷先后執(zhí)行update后執(zhí)行的覆蓋先執(zhí)行的。解決按第4章講的方式改寫為單條update語句將狀態(tài)判斷放進(jìn)where條件用影響行數(shù)判斷是否搶單成功。代碼改完后可以做一次并發(fā)壓測驗(yàn)證簡單方式是用兩個(gè)瀏覽器同時(shí)點(diǎn)接單按鈕也能復(fù)現(xiàn)。這是一條典型的血淚經(jīng)驗(yàn)我在早期項(xiàng)目里踩過直接在線上出現(xiàn)過一單多接的運(yùn)維事故。修完之后要同步檢查其它可能的并發(fā)點(diǎn)用戶余額扣減、優(yōu)惠券核銷、技師時(shí)間表占用凡是存在先查后寫模式的地方一律改成條件更新。6. 上線前的最后一道工序把演示源碼變成能商用的可用系統(tǒng)演示源碼跑通和真正對(duì)外接單之間還隔著幾道不得不做的工序。第一道是支付和結(jié)算確認(rèn)微信支付/支付寶的小程序商戶號(hào)配置在后端配置項(xiàng)里支付回調(diào)地址必須是公網(wǎng)HTTPS地址回調(diào)邏輯要處理支付成功但訂單狀態(tài)沒更新的重復(fù)通知——支付回調(diào)可能被微信多次推送冪等處理必須做。第二道是把用戶協(xié)議、隱私協(xié)議、技師入駐協(xié)議加上這是這類平臺(tái)的合規(guī)底線。第三道是接口的鑒權(quán)和限流后臺(tái)登錄、下單、提現(xiàn)、驗(yàn)證碼發(fā)送這幾個(gè)接口至少要加頻率限制redis計(jì)數(shù)器就能實(shí)現(xiàn)避免被刷。真正進(jìn)入運(yùn)營后有個(gè)技巧值得優(yōu)先投入把技師端搶單做成可配置的策略。前期單量少可以先用平臺(tái)派單——管理員在后臺(tái)直接把訂單分配給指定技師單量上來了再切先到先得的搶單模式。這個(gè)開關(guān)的核心邏輯就是一個(gè)配置項(xiàng)// 配置項(xiàng)dispatch_mode值為manual表示后臺(tái)派單compete表示搶單 $mode config(site.dispatch_mode); if ($mode manual) { // 后臺(tái)指派管理員選技師接口直接綁定訂單 Db::name(order)-where(id, $orderId) -where(status, OrderStatus::PENDING) -update([status OrderStatus::TO_SERVE, tech_id $techId]); } else { // 搶單模式走第4章的原子更新邏輯 }參數(shù)說明dispatch_mode這個(gè)配置放在后臺(tái)的系統(tǒng)配置里運(yùn)營人員可以不用改代碼直接切換。不同模式下前端技師端的交互也要配合——搶單模式顯示立即接單按鈕派單模式只顯示訂單已指派的提示。這是從源碼走向商業(yè)運(yùn)營最值得做的改造之一能讓運(yùn)營策略的試錯(cuò)成本降到最低。我自己的經(jīng)驗(yàn)是做這類系統(tǒng)卡住進(jìn)度的從來不是技術(shù)難點(diǎn)而是以為演示能跑就等于能上線的心態(tài)。演示源碼解決的是從無到有的問題從有到可用還需要把并發(fā)、支付、合規(guī)這三件事挨個(gè)磨一遍。每多提前一天處理這些問題上線后就少一分被用戶罵的風(fēng)險(xiǎn)。希望這篇筆記對(duì)你有點(diǎn)幫助。本文還有配套的精品資源點(diǎn)擊獲取