i茅台预约自动化从Docker Compose一键启动到多账号调度配置【免费下载链接】campus-imaotaii茅台app自动预约每日自动预约支持docker一键部署本项目不提供成品使用的是已淘汰的算法项目地址: https://gitcode.com/GitHub_Trending/ca/campus-imaotaicampus-imaotai 是一个开源的 i茅台自动预约系统它替你保存多个账号的 token 会话每天 9 点整按分钟错峰执行预约请求并自动选店、推送结果。适合想完整跑通「定时任务 多账号调度 接口逆向封装」全流程的学习者。项目定位它和写个脚本有什么不一样技术栈一句话Spring BootJDK 8 MyBatis-Plus MySQL 5.7 Redis 6 做后端Vue 2 Element UI 的管理台做前端Docker Compose 编排四个容器。它和一段 Python 脚本的核心差异在两点账号是结构化数据而不是环境变量。每个 i茅台账号一行记录会话token/cookie/deviceId、预约参数、城市经纬度、推送地址都入库管理台里可增删改查多账号之间互相隔离。预约是一个调度问题而不是一个请求。9 点整所有账号同时打请求既没必要也容易被限流项目把什么时候打、打哪个门店拆成了两条独立策略后面单独讲。需要提前说明项目描述明确写了使用的是已淘汰的算法即它封装的 i茅台接口版本较老接口随时可能变动。把它当作学习样本很合适当作必成功的工具不合适。Docker Compose 启动与首次登录前置条件只有 Docker 和 Docker Compose。下面三步每步都给了验证方式。第一步获取代码git clone https://gitcode.com/GitHub_Trending/ca/campus-imaotai cd campus-imaotai/doc/docker第二步启动服务docker-compose up -d docker-compose ps验证四个容器mysql、redis、nginx-web、campus-server全部 Up。编排文件是 Docker 编排配置注意两点所有容器用network_mode: host直接占用宿主机的 80 和 8160 端口先确认没被别的程序占着数据目录挂在宿主机/docker/下mysql、redis、nginx、server 四个子目录路径写死改挂载点要动 docker-compose.yml。第三步导入数据库脚本compose 已自动建好campus_imaotai库root 密码123456789但表结构还在 数据库初始化脚本 里mysql -uroot -p123456789 campus_imaotai ../sql/campus_imaotai-1.0.5.sql验证mysql -uroot -p123456789 -e use campus_imaotai; show tables;能看到i_user、i_shop、i_item、i_log及sys_*系列表即导入成功。浏览器打开http://localhostNginx 80 端口托管前端并把/prod-api/反代到 8160配置见 nginx.conf用 SQL 里预置的admin账号登录即可进入管理台。一次预约是怎么被决定的把 9 点拆成 59 个时间片要解决的问题如果所有账号都在 09:00:00 发请求请求被折叠成一个尖峰失败率最高。做法在 定时任务定义 里两个 cron 配合每天 01:10 给所有待预约账号批量分配一个minute1–59。账号不超过 60 个时随机取分钟超过 60 个自动切换均匀分布算法保证每个分钟槽的账号数接近。9 点期间每分钟触发一次reservationBatch只挑minute等于当前分钟数的账号串行执行账号之间固定间隔 3 秒。账号上的random_minute字段0 随机、1 固定决定 01:10 那次分配是否覆盖你手动指定的分钟。效果是一组 10 个账号的请求自然摊到 9:00–9:59 的窗口里而不是挤在同一秒。门店选择出货量优先距离兜底要解决的问题预约必须绑定具体门店的库存shopId而全省门店有几十上百家每天手动挑不现实。决策逻辑在 门店选择实现 的getShopIdshop_type1在当日商品投放列表里筛出账号所在城市有货的门店按库存出货量降序取第一本市无货时退回省内按经纬度取最近。shop_type2直接按账号经纬度取省内最近门店。门店和商品数据不是预约时现查的每天 07:10 和 08:55 各执行一次refreshAll提前把版本号、商品列表、门店列表刷进缓存预约时纯本地决策。所以 08:55 那次刷新决定了当天 9 点能用的数据是否够新这也是为什么宿主机时间必须准确。会话保活与结果推送要解决的问题i茅台的登录态会过期预约完也不知道结果。做法在管理台添加账号时用手机号 验证码走一遍完整登录服务端把返回的 token、cookie、deviceId 落库默认按 30 天计算到期时间expire_time。预约请求全部带上这些会话头每天 18:05 定时任务统一查询当日申购结果写入日志表若账号配置了push_plus_token结果还会通过 PushPlus 推送到微信不用守着页面。i茅台账号录入与关键字段管理台左侧「i茅台 → 用户管理」有两个入口「添加账号」走验证码登录服务端代跑注册/登录接口「直接新增」手动粘贴已有会话。录入后的关键字段对应i_user表实体见 IUser字段说明mobile主键一行对应一个 i茅台账号item_code商品预约 code多个用间隔会逐个预约province_name/city_name/lat/lng选店依据经纬度务必真实shop_type1 本市出货量最大2 位置附近最近minute预约分钟 1–59一般交给 01:10 自动分配random_minute0 随机 / 1 固定分钟push_plus_token可选结果微信推送调优与扩展只列操作价值最高的三项外部配置覆盖campus-server 的 compose 环境里已声明spring.config.additional-location: /home/campus/conf/application-prod.yml对应宿主机/docker/server/conf。要改数据源、日志级别把application-prod.yml放这里即可无需重建镜像说明见 外部配置说明。MySQL 内存compose 里写死--innodb-buffer-pool-size80M是给低配主机的保底值。宿主机内存 4GB 以上时把 docker-compose.yml 中该参数改为512M再docker-compose up -d mysql生效。HTTPSnginx.conf 中 443 段已写好注释证书放到/docker/nginx/cert/后取消注释、docker-compose up -d nginx-web即可远程访问时建议开启。常见故障现象与修复现象页面 502 或 /prod-api 404→ 原因campus-server 未起来或宿主机 8160/80 被占容器是 host 网络→ 解法docker-compose logs campus-imaotai看启动日志netstat -lntp | grep -E :8160|:80 查端口占用。现象后台登录失败或列表全空→ 原因SQL 脚本没导入库是空库 → 解法重跑上文的mysql -uroot -p123456789 campus_imaotai ../sql/...用show tables确认。现象日志全是登录失败/token 失效→ 原因会话过期默认 30 天或宿主机出不了app.moutai519.com.cn→ 解法用户管理里对该账号重新走验证码登录刷新 token或检查宿主机外网连通性。现象预约没在 9 点执行或整体偏晚→ 原因宿主机时间/时区不对TZ: Asia/Shanghai只影响容器内环境变量的解释改不了主机时钟→ 解法date检查与 NTP 同步后再观察次日任务。现象docker-compose up报 /docker 目录相关错误→ 原因compose 假设宿主机存在/docker挂载树 → 解法mkdir -p /docker/{mysql/{data,conf},redis/{conf,data},nginx/{html,cert,conf,log},server/conf}后重启。适用边界项目 README 已声明使用已淘汰的接口算法且仅供学习研究因此它不适合任何保证预约成功的场景也不适合多人共用一套会话库做生产用途接口一旦变动代码需要自己跟进。它的价值在于一个结构完整、可 Docker 一键复现的多账号定时调度样例。仓库地址campus-imaotai上文 clone 地址二次开发可基于 campus-modular 业务模块扩展。【免费下载链接】campus-imaotaii茅台app自动预约每日自动预约支持docker一键部署本项目不提供成品使用的是已淘汰的算法项目地址: https://gitcode.com/GitHub_Trending/ca/campus-imaotai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考