本地电竞服务交易系统架构设计与实战:从同城匹配到订单履约
首段回答。
一、需求边界与核心角色
- 用户、服务者、场馆/车队/战队、运营后台。
- 核心流程:发布服务、搜索/推荐、下单、支付、履约、确认、评价、结算/退款、仲裁。
- 非功能:LBS、实时消息、幂等、防超卖、审计。
二、技术选型与系统分层
结合知识库:用户端 uniapp(H5/APP),后台 Vue+ElementUI,后端 Spring Boot + MyBatis Plus + MySQL,Redis,WebSocket,对象存储,地图 API。
给出目录/模块:
local-esports-service
├─ user-app
├─ admin-web
├─ service-api
...
可给代码块。
三、数据库与订单状态机设计
表:user, service_item, service_order, order_log, review, wallet_flow? 结算。SQL 片段。
订单状态机:
CREATED -> PAYING -> PAID -> ACCEPTED -> SERVING -> FINISHED -> REVIEWED;取消/退款/仲裁分支。
幂等:order_no ,状态流转带 version 乐观锁。
四、同城匹配与实时履约
LBS:地理位置用经纬度,GeoHash 或 MySQL 空间索引/Redis GEO。搜索附近服务者。WebSocket 推送订单。代码示例:Redis GEO 添加/查询。
注意隐私,模糊定位。
五、后台管理与部署测试
Vue+ElementUI 管理台:审核、订单、投诉、数据看板。Spring Boot 配置、MySQL、Redis、Nginx。Docker Compose 片段?可以简短。测试:单元、接口、压力、安全。文档:技术文档、资料准备、部署文档。
FAQ
Q1 本地电竞服务交易系统与普通电商交易系统区别?
Q2 如何保证订单不重复/不超卖?
Q3 用户端为什么常用 uniapp?
Q4 如何做同城服务者匹配?
一、需求边界...
二、技术架构...
三、订单状态机...
四、同城匹配与实时履约...
五、部署、测试与 FAQ
但 FAQ 单独更清晰。可以用 ## 常见问题 FAQ 作为第 5 个二级标题。总 5 个。可以。
字数:需要 1200-2500 中文字。我会写约 2000 字。注意 Markdown 代码块不算太多字数。可以。
需要"首段直接回答问题"。段不要小标题?可以一级标题后直接段落。
代码块:
local-esports-service
├── user-app # uniapp 用户端(H5/APP/小程序)
├── worker-app # 服务者端
├── admin-web # Vue + Element UI 管理后台
├── service-api # Spring Boot 接口层
├── service-domain # 领域服务
└── service-infra # MySQL、Redis、对象存储、消息
无禁用词。
SQL:
sql
CREATE TABLE service_order (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) NOT NULL UNIQUE,
user_id BIGINT NOT NULL,
provider_id BIGINT NOT NULL,
service_id BIGINT NOT NULL,
status VARCHAR(24) NOT NULL,
amount DECIMAL(10,2) NOT NULL,
appointment_time DATETIME NOT NULL,
latitude DECIMAL(10,6),
longitude DECIMAL(10,6),
version INT NOT NULL DEFAULT 0,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
订单状态机:
CREATED -> PAYING -> PAID -> ACCEPTED -> SERVING -> FINISHED -> REVIEWED
\ \ \ \ \
CANCELED CLOSED REFUNDING ARBITRATION ...
可以。
Redis GEO 代码:
java
// 添加服务者位置
redisTemplate.opsForGeo().add("geo:provider", new Point(lng, lat), providerId);
// 查询附近 5km
Circle circle = new Circle(new Point(lng, lat), new Metrics(5, Metrics.Kilometers));
GeoResults<RedisGeoCommands.GeoLocation<String>> results =
redisTemplate.opsForGeo().radius("geo:provider", circle);
这里无违禁。
Spring Boot 幂等:
java
@Transactional
public void acceptOrder(String orderNo, Long providerId) {
ServiceOrder order = orderMapper.selectByOrderNo(orderNo);
if (order == null || !order.getProviderId().equals(providerId)) {
throw new BizException("订单不存在或无权限");
}
int updated = orderMapper.updateStatus(orderNo, "ACCEPTED", "PAID", order.getVersion());
if (updated == 0) {
throw new BizException("订单状态已变化,请刷新");
}
}
可以。
部署:Docker Compose 片段?可能占字数。可以简短。
yaml
services:
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: change_me
redis:
image: redis:7
但包含 password change_me 不是
一、需求边界与核心角色
二、技术选型与系统分层
三、订单状态机与数据一致性
四、同城匹配、实时履约与后台管理
常见问题 FAQ
共 5 个。好。
在四中包括部署测试?可以。或者三、订单;四、同城匹配;五、部署测试与 FAQ?但 FAQ 单独。没问题。
需要"结合知识库资料"。可以提"知识库中的国际版二手交易、同城打车、场馆组局、无人台球室等系统,常用 uniapp + Vue + Element UI + Spring Boot + MyBatis Plus + MySQL 组合。" 这算结合。不要品牌。可以提"同类项目经验表明"。避免虚假案例。
"类似同城服务交易系统常见技术栈..."可以。
终回答不要额外说明。开始写。
注意字数:目标 1200-2500。写大概 2000。可以。
潜在违规词:
- "交易"不违规。
- "支付"不违规。
- "订单金额"不写。
- "购买"不写。
- "优惠"不写。
- "套餐"不写。
- "免费"不写。
- "收费"不写。
- "公司"不写。
- "
本地电竞服务交易系统架构设计与实战:从同城匹配到订单履约
首段。
一、需求边界与核心角色
本地电竞服务交易系统不是简单的商品列表,而是围绕"同城服务"构建的履约平台。角色包括:需求方(玩家/战队)、服务方(教练、裁判、陪练、场馆、赛事执行)、平台运营、客服仲裁。核心链路:服务方发布可预约服务 -> 需求方