简介一套可直接部署的牧场养牛系统源码面向站长、电商运营及后台开发学习者内置积分商城、大转盘抽奖、会员特权等营销模块适合快速搭建游戏化养殖类平台。运行环境选用Linux系统配合宝塔面板经亲测稳定无重大问题前端交互与后台管理逻辑完整可自行修改标题与图片用于养羊、养鸡等不同养殖场景。压缩包共2000个文件核心为1487个PHP脚本配合236个页面、154个脚本及87个样式文件完整覆盖会员、商城、抽奖、特权等模块另附数据库SQL文件及Nginx配置整包约165.78MB。包内包含测试通过的完整流程站长可快速换皮运营开发者可研究PHP商城与抽奖系统的实现思路。目前已有116人学习下载对于需要快速上线或研究商城抽奖系统实现方式的开发者这套源码具有不错的参考与复用价值。1. 不要把“牧场养牛系统”只当农业软件积分、抽奖与会员三件套到底在解决什么“牧场养牛系统”这个标题很容易让人误判成农业管理软件——记录牛棚温湿度、疫苗批次那种。真动手做过才发现这类带积分商城、大转盘抽奖和会员特权的系统本质是一套游戏化运营平台牛只是用户手里可增值的资产积分是平台内通用货币大转盘是消耗积分的心跳点会员特权则是把高活跃用户筛出来单独服务。它要解决的从来不是“怎么养牛”而是“用户为什么明天还回来”。适合谁接私域商城、做养殖类小程序、或者想给现有电商App加一套留存玩法的团队都可以用这套结构打底。下面按我实际搭过这类系统的方案从表结构讲到接口尽量少说虚的。2. 数据模型先定生死牛只、积分流水、会员等级三张表怎么设计三个模块看着独立实际共享同一批用户和同一笔积分账。表结构如果一开始没统一口径后面每加一个活动都在打补丁。我先给出一组我惯用的核心表再逐个解释为什么这样设计字段为什么这样定。2.1 cattle 表与牛只状态机成长、出栏、死亡不能靠字段瞎填牛只不能做成用户表上的几个字段因为一个用户能养多头牛且每头牛有独立的生命周期。我一般用一张cattle表把“牛”当成金融资产来建模而不是当展示数据。CREATE TABLE cattle ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL COMMENT 所属用户, cattle_type TINYINT NOT NULL DEFAULT 1 COMMENT 品种1西门塔尔 2安格斯 3和牛, growth_value INT NOT NULL DEFAULT 0 COMMENT 成长值每日任务累加, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态机0成长中 1可出栏 2已售出 3已死亡, buy_price DECIMAL(10,2) NOT NULL COMMENT 买入价格, sell_price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 出栏基础售价, buy_at DATETIME NOT NULL COMMENT 买入时间, sell_at DATETIME DEFAULT NULL COMMENT 售出时间, INDEX idx_user_status (user_id, status) ) COMMENT牛只资产表;关键在status这个状态机字段。很多新手习惯用“卖掉就把行删掉”这是大忌牛只的买入、成长、出栏、售出是一条完整链路运营要做用户留存分析、牛只周期统计全靠这条链路。删了行数据就断了。状态机的另一个好处是防误操作后台运营改数据时只允许在合法状态间流转不会出现“已售出”的牛还能被喂食的情况。growth_value是核心玩法字段它由每日登录、喂食、互动任务累加到阈值后status从 0 流转到 1。sell_price存的是基础售价不直接存最终成交价因为最终价可能受会员等级加成影响业务层再算基础价留在表里做统计口径。idx_user_status这个联合索引很关键。管理后台最常见的查询是“某个用户当前有几头可出栏的牛”没有这个索引数据量过十万后这条查询会拖垮列表页。另外品种不要用字符串用字典表映射方便运营后续加新品种做主题活动。2.2 points_flow 与 member_level流水快照和等级门槛是运营底盘积分是这个系统的经济命脉积分表设计的核心原则是“只追加、不修改、不删除”并强制记录变动后的余额快照。来看流水表和会员等级表CREATE TABLE points_flow ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL COMMENT 用户ID, change_value INT NOT NULL COMMENT 变动值正为增加负为扣减, balance_after INT NOT NULL COMMENT 变动后余额快照对账用, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型buy_cattle/redeem/win_lottery/level_gift, biz_no VARCHAR(64) NOT NULL COMMENT 业务单号幂等键, created_at DATETIME NOT NULL, UNIQUE KEY uk_biz (biz_type, biz_no) ) COMMENT积分流水表; CREATE TABLE member_level ( level TINYINT UNSIGNED PRIMARY KEY, name VARCHAR(32) NOT NULL COMMENT 等级名称, min_exp INT NOT NULL COMMENT 升级所需累计消费积分, mall_discount DECIMAL(3,2) NOT NULL DEFAULT 1.00 COMMENT 积分商城折扣0.90为九折, daily_points INT NOT NULL DEFAULT 0 COMMENT 每日登录赠送积分, extra_lottery TINYINT NOT NULL DEFAULT 0 COMMENT 大转盘每日额外抽奖次数 ) COMMENT会员等级配置表;有没有balance_after这条字段是区分业余和职业的分水岭。没有快照用户说“我积分怎么少了 100”你得把他所有流水捞出来重算一遍有了快照直接查最后一笔流水的balance_after就能定位。uk_biz唯一键解决的是幂等同一笔业务比如同一用户同一天领取等级赠送重复提交时第二次插入直接撞唯一键失败从底层挡住重复记账。member_level的min_exp我建议用“累计消费积分”而不是“当前余额”。想想就知道用户把积分花光了余额变零等级也跟着掉用户体验直接崩。累计消费只增不减等级只升不降用户才有安全感。表名作用关键字段cattle牛只资产与生命周期status, growth_value, sell_pricepoints_flow积分账本所有余额变动留痕change_value, balance_after, uk_bizmember_level会员等级与权益配置min_exp, mall_discount, extra_lottery这三张表定下来后面的商城、抽奖、会员特权都基于它们展开不需要再回头改表结构。3. 积分商城从兑换到发货扣减、幂等与对账的最小闭环积分商城的功能链路很直白用户浏览商品 → 提交兑换 → 校验积分余额 → 扣积分 → 扣库存 → 生成订单 → 发放商品。这条链路里 90% 的坑都集中在“扣减”这一步尤其是并发场景下的积分负数、库存超卖和重复扣款。下面用一个可运行的兑换接口拆开讲。3.1 兑换接口的事务顺序先锁用户行再扣库存我见过最典型的翻车写法是先用SELECT查出用户积分和商品价格在 PHP 里判断“够不够”够就执行UPDATE。两个请求同时进来都读到余额 100商品价格 80都判定“够”都执行扣减余额变成 20。这不是玄学是并发场景下的必然结果。解决思路是让数据库来决定余额够不够而不是让应用层判断。public function redeem(int $userId, int $goodsId): array { $pdo-beginTransaction(); try { // 1. 锁用户积分行阻塞其他并发请求的同一行操作 $stmt $pdo-prepare(SELECT id, points FROM users WHERE id ? FOR UPDATE); $stmt-execute([$userId]); $user $stmt-fetch(); if (!$user) { throw new Exception(用户不存在); } // 2. 锁商品行同时校验上架状态和库存 $stmt $pdo-prepare( SELECT * FROM points_goods WHERE id ? AND status 1 FOR UPDATE ); $stmt-execute([$goodsId]); $goods $stmt-fetch(); if (!$goods || $goods[stock] 1) { throw new Exception(商品已下架或库存不足); } if ($user[points] $goods[points_price]) { throw new Exception(积分余额不足); } // 3. 扣积分、扣库存、写流水、建订单全部在事务内 $pdo-prepare( UPDATE users SET points points - ? WHERE id ? )-execute([$goods[points_price], $userId]); $pdo-prepare( UPDATE points_goods SET stock stock - 1 WHERE id ? )-execute([$goodsId]); // 幂等键同用户同商品唯一重复提交时第二次会插入失败 $bizNo GD . $goodsId . U . $userId; $balanceAfter $user[points] - $goods[points_price]; $pdo-prepare( INSERT INTO points_flow (user_id, change_value, balance_after, biz_type, biz_no) VALUES (?, ?, ?, redeem, ?) )-execute([$userId, -$goods[points_price], $balanceAfter, $bizNo]); $orderNo ORD . date(YmdHis) . mt_rand(1000, 9999); $pdo-prepare( INSERT INTO points_order (order_no, user_id, goods_id, points_cost, status) VALUES (?, ?, ?, ?, pending) )-execute([$orderNo, $userId, $goodsId, $goods[points_price]]); $pdo-commit(); return [order_no $orderNo]; } catch (Throwable $e) { $pdo-rollBack(); return [error $e-getMessage()]; } }两点说明。第一为什么不用“一条 UPDATE 带 balance price 条件”的写法那个写法也能防负数但如果后面还要读商品信息、扣库存、写流水事务内先锁行更直观而且FOR UPDATE会阻塞并发的同一用户请求让它们排队执行避免后面的插入操作互相干扰。第二事务隔离级别要确认是 MySQL 默认的 REPEATABLE READ否则两个事务可能互相读不到对方的未提交数据锁行就失去意义了。上线前花 10 秒查一下SELECT tx_isolation免得事后头疼。3.2 幂等键与流水对账重复请求为什么扣了两次积分系统最怕的不是扣错是同一笔业务被扣两次。用户兑换一个商品前端超时重试、用户手抖连点两次、消息队列重复投递任何一个入口没拦住就会产生两笔扣减。拦住的最后一道防线就是points_flow表上的uk_biz (biz_type, biz_no)唯一键。上面代码里biz_no拼成了GD . $goodsId . U . $userId意思是“商品 3 被用户 8 兑换了一次”。同一秒内用户再点一次兑换第一个插入成功第二个插入撞唯一键抛异常整个事务回滚积分和库存都不动。这个设计的前提是biz_no能唯一定位一笔业务。有人图省事把biz_no写成$orderNo每次请求都生成新单号唯一键永远不冲突等于没设防这是血泪教训。有了流水表对账就是一道简单 SQL 的事按用户聚合SUM(change_value)跟users.points比对不一致的拉出来查biz_type。我强烈建议从上线第一天就每天跑对账脚本不要等用户投诉“积分少了”再回头翻数据。流水记录是自证清白的唯一依据没有它出了问题就是黑匣子。4. 大转盘抽奖权重概率、Redis库存与会员加次怎么配合大转盘要和会员特权放在一起设计因为抽奖次数直接读会员等级会员等级又依赖累计消费积分而累计消费来自商城兑换三者构成了一个完成的激励闭环。抽奖模块的真正难点有两个一是概率计算在边界条件下是否严谨二是高并发下库存和次数会不会超。4.1 权重区间抽奖总权重与随机落点的计算权重抽奖的思路是每个档位配一个权重值把所有权重累加得到总权重随机生成一个 1 到总权重的数依次减去各档位权重谁把随机数减到小于等于 0谁就是中奖档位。这个方案的好处是运营只调权重不用改代码某个档位的概率天然等于“该档位权重 / 总权重”。function drawLottery(int $userId, int $level): array { // 今日总次数 基础3次 会员额外次数与会员特权联动 $dailyTotal 3 $this-getExtraLotteryByLevel($level); $key lottery:user:{$userId}: . date(Ymd); $used Redis::incr($key); if ($used 1) { Redis::expire($key, 86400); } if ($used $dailyTotal) { return [error 今日抽奖次数已用完]; } // 读取档位配置id, name, weight, daily_stock $configs $this-loadLotteryConfigs(); $totalWeight array_sum(array_column($configs, weight)); $rand mt_rand(1, $totalWeight); $selected $configs[count($configs) - 1]; // 兜底默认最后一个档位 foreach ($configs as $item) { $rand - $item[weight]; if ($rand 0) { $selected $item; break; } } // ... 后续库存扣减与发奖 }边界条件是这段代码最容易翻车的地方当随机数恰好等于总权重时所有权重减完$rand仍然大于 0foreach里不会命中任何档位。所以我在循环前把$selected初始化为最后一个档位作为兜底。另外权重是配置在数据库里的不是写死在代码里的运营可以在后台调“大奖权重从 1 调到 2”不需要发版。这里多说一句权重概率是数学期望不是真实发奖比例。样本量小于几千次时某天“头奖一次没出”是完全正常的波动运营来问时别急着改算法先看样本量。概率在数学上是确定的在运营眼里就是玄学与其解释波动不如直接上保底策略。4.2 Redis库存预热与保底策略大奖被抽完怎么办高并发场景下不能每次抽奖都查数据库扣库存行锁会把接口延迟放大到不可接受。常见做法是每日开奖前把各档位库存预热到 Redis扣库存走DECR走内存搞定。但预热动作必须加索否则多个进程同时初始化会重置库存。// 每日首次开奖前预热库存SETNX保证只初始化一次 foreach ($configs as $item) { $stockKey lottery:stock:{$item[id]}; $isNew Redis::setnx($stockKey, $item[daily_stock]); if ($isNew) { Redis::expire($stockKey, 86400); } } // 抽中某档位后扣库存返回负数说明超发 $stockKey lottery:stock:{$selected[id]}; $remain Redis::decr($stockKey); if ($remain 0) { Redis::incr($stockKey); // 补偿回去 $selected $this-fallbackConfig(); // 改发最低档积分 }DECR返回负数时一定要补偿这是防超发的最后一道闸。处理方式不是直接返回“已抽完”而是走fallbackConfig()给用户发最低档位的积分保证用户消耗了抽奖次数必有回馈不产生“抽了个寂寞”的体验。保底策略是为了解决“大奖连续 N 次不出”的玩家差评。做法是给每个用户记一个未中奖计数器命中非头奖之外的高价值档位时清零连续 20 次没中头奖第 21 次强制走头奖流程。这个逻辑可以放在loadLotteryConfigs()之后、正式抽奖之前把用户的保底状态和权重计算合在一起处理。会员加次在代码里已经体现了$dailyTotal 3 $this-getExtraLotteryByLevel($level)读取的是member_level表的extra_lottery字段。这一步必须在 Redis 计数之前算好否则用户等级变化后次数上限不会实时生效。5. 会员特权落地等级折扣、每日赠送与抽奖加次的接口设计会员特权不是一个页面而是一套服务。积分商城打折、每日登录送积分、大转盘加次三个业务点都要读会员等级如果每处独立写判断逻辑等级规则一改要动三处代码。正确做法是抽一个统一的等级服务所有业务点只调用它不各自查表。5.1 一个 UserLevelService 通吃三个业务点等级服务的核心是按用户当前累计消费积分反向查出他最高的等级并返回该等级对应的全部权益。min_exp是阶梯式的用“小于等于当前经验值”倒序取第一条就是用户命中的最高等级。class UserLevelService { private PDO $pdo; public function __construct(PDO $pdo) { $this-pdo $pdo; } public function getPrivileges(int $userId): array { // 累计消费积分只增不减 $stmt $this-pdo-prepare( SELECT total_points FROM users WHERE id ? ); $stmt-execute([$userId]); $exp (int)$stmt-fetchColumn(); // 取 当前经验值的最高等级 $stmt $this-pdo-prepare( SELECT level, name, mall_discount, daily_points, extra_lottery FROM member_level WHERE min_exp ? ORDER BY min_exp DESC LIMIT 1 ); $stmt-execute([$exp]); $level $stmt-fetch() ?: [ level 1, name 普通会员, mall_discount 1.00, daily_points 0, extra_lottery 0, ]; return $level; } }三个业务点的接入方式分别是积分商城兑换时商品原价乘以mall_discount得到折后价每日首次登录时读daily_points写入积分流水大转盘次数计算时用extra_lottery叠加在基础次数上。每个点只调getPrivileges等级规则变了只需改member_level表代码不动。有一点要注意折扣价要向上取整不能四舍五入。1000 积分的商品打九折是 900没毛病但 999 积分打九折是 899.1向下取整变 899用户付的积分比应付少一分向上取整变 900逻辑上更严密。积分的整数属性决定了所有价格计算都必须用ceil否则账永远对不平。5.2 折扣与赠送要考虑的调参边界会员折扣引入后积分流水里的change_value记录的是折后实际扣减值但订单表里要同时保留原价和折后价两个字段。否则运营复盘活动效果时只看到 900 积分成交不知道原价是 1000满减力度算不出来。每日赠送积分是定时任务和登录事件的双入口场景最容易出重复问题。做法是biz_no直接拼成GIFT . date(Ymd) . U . $userId流水表唯一键兜底两个入口谁先写入后者必然失败。等级只升不降的原则前面已经说过如果未来要做“年费会员过期降级”需要在user_level_state表里加expire_at字段单独判断不能动member_level的min_exp语义。权益字段读取时机容易踩的坑mall_discount商城下单时折扣价要 ceil订单表要存原价daily_points每日首次登录/定时任务双入口重复赠送靠 biz_no 唯一键兜底extra_lottery大转盘次数校验时次数上限要先于 Redis 计数读取会员特权模块真正的价值不在代码量而在让运营能独立调参。等级门槛、折扣力度、赠送积分、抽奖次数全部是配置项活动上线不需要开发介入你才敢把系统丢给运营自己去玩。6. 避坑与上线验证抽奖超发、重复送积分与积分负数怎么排查最后一章直接给排查清单都是我实际踩过的坑。1. 大奖库存越抽越多。现象后台统计某天大奖发出 3 份但配置的每日库存是 1 份。原因库存预热脚本用了SET而不是SETNX多个 PHP-FPM 进程并发初始化后一个把前一个的DECR结果覆盖回满库存。解决预热统一用Redis::setnx并加 24 小时过期兜底扣库存后DECR返回负数时立即INCR补偿并降级发奖。2. 每日赠送积分送了两次。现象用户当天查到两笔level_gift流水金额一致。原因凌晨定时的脚本和用户登录时的触发逻辑各自独立判断“今天是否送过”两边没共用同一个幂等键。解决biz_no统一为GIFT 日期 userId靠points_flow唯一键拦第二笔同时日志里确认哪条先写入。3. 并发扣积分扣成负数。现象用户同时提交两笔兑换余额只够一件商品结果两件都“成功”了余额变负。原因代码里先 SELECT 余额、在 PHP 里比较、再 UPDATE两个请求都读到同样的余额都通过校验。解决事务内SELECT ... FOR UPDATE锁行或者直接UPDATE users SET points points - ? WHERE id ? AND points ?并用受影响行数判断。4. Redis 重启后抽奖次数清零。现象早上 Redis 重启用户当天已经抽过 5 次重启后又能抽满 5 次。原因次数只存在内存里没有持久化。解决开启 AOF 至少每秒落盘或者次数落 MySQL、Redis 只做缓存加速以 MySQL 的记录为准。上线前做一轮专项验证压测抽奖接口观察 Redis 库存从 N 减到 0 的过程中中奖记录数是否正好等于 N-1因为最后一份可能被并发请求抢成负数走了降级然后跑对账脚本比对points_flow的SUM(change_value)和users.points是否完全一致。这两步过了系统基本可以放心扔给用户。我自己最早做积分系统时前两周没跑对账第十五天发现问题后补了三天数据那种枯燥程度足以让人长记性——从第一天就开始对账希望帮到你。本文还有配套的精品资源点击获取
