去年帮朋友搭了个发卡站，网站卖游戏点卡和会员充值。搭建上线第三天就被扫，网站支付接口差点被薅穿。搭建这事让我意识到，网站发卡网站的搭建技术门槛不在“建”，而在“防”。网站

先说什么叫发卡站。搭建简单讲就是网站自动售货机——用户下单付款，系统从库存里取一条卡密发给他。搭建听起来简单，网站但涉及支付回调、搭建库存锁定、网站防并发、搭建防刷单几个环节，网站任何一环出问题都是真金白银的损失。

选型：别上来就微服务

朋友一开始想用Spring Cloud，我劝住了。日订单量不到两千，一台2核4G的云服务器跑个单体应用绰绰有余。最后选了PHP + MySQL，框架用ThinkPHP。原因很实际：虚拟主机便宜，出了故障好排查，网上现成的发卡源码多，改起来快。

数据库设计有个坑要注意。卡密表不要用自增ID做主键，用订单号关联。自增ID会暴露销量，竞争对手下几单就能算出你一天卖了多少。另外卡密字段加唯一索引，防止重复发放。

支付回调才是重灾区

这是整个系统最脆弱的地方。用户付款后，支付平台会异步通知你的服务器。如果处理不当，会出现“付了款没发货”或者“没付款却发了货”。

我的做法是：回调接口先验签，验签通过后把订单状态改为“已支付”，然后丢进消息队列。发货逻辑单独跑一个消费者进程，从队列里取任务。这样即使发货程序挂了，重启后还能继续消费，不会丢单。

还有个细节：回调接口必须做幂等。同一个订单号重复回调，只处理第一次。否则用户刷新一下支付页面，你的卡密就被领两次。

防刷是持久战

上线第二天，日志里出现大量来自同一IP的请求，间隔精确到毫秒。典型的CC攻击，想撞库试出未支付的订单号。我加了几个限制：同一IP每秒最多3次查询，同一订单号查询超过5次直接拉黑，所有查询接口加验证码。

更隐蔽的是“卡密试探”。有人用脚本批量下单，但不付款，只为占用库存。等库存显示为0，真实用户买不了，他再联系客服说“我帮你们测出了漏洞，给点奖励”。碰到这种直接封号，不用客气。

库存锁：别用数据库行锁

高并发下用SELECT ... FOR UPDATE锁库存行，数据库连接池很快会被打满。我用Redis的DECR命令做预扣减，扣到0就直接返回“已售罄”，不再查数据库。下单成功后把订单号和卡密ID写进Redis队列，异步落库。这样数据库压力小很多，响应也快。

但Redis和MySQL之间有一致性问题。我的容忍度是：极端情况下超卖不超过3单。超过的部分手动补发，成本可控。追求强一致性的方案不是没有，但架构复杂度翻三倍，对小站不划算。

日志和告警不能省

我在服务器上装了个fail2ban，监控Nginx日志。同一IP五分钟内出现10次404，自动封禁一小时。支付回调失败超过3次，发短信告警。库存低于10条，发邮件提醒补货。

这些配置花不了半小时，但能让你睡个安稳觉。发卡站最怕半夜被刷，第二天起来发现卡密全没了，钱还没到账。

最后说句实在话：技术方案没有绝对优劣，只有适不适合。日流水几千块的小站，别学大厂搞中台。把支付回调写稳，把库存锁做好，把日志看住，已经能跑赢80%的同行。剩下的精力，不如多找几个靠谱的卡密供应商。