“基于Python的线上购书平台、图书商城、抽奖、积分兑换”这个组合我在不少技术社区的提问区和私信里都见过。很多开发者拿到类似需求第一反应是“这不就是个增删改查的电商系统吗”真做起来才发现图书商城只是起点抽奖和积分兑换才是真正考验设计功底的地方。它们牵扯到库存、并发、用户激励和账务一致性稍不注意线上就要出事故。这篇文章我打算用一套实际可复现的方案把这几个模块从需求拆解到落地实现完整过一遍。技术栈采用Python 3.10 Django 4.x MySQL Redis比较适合作为毕设、简历项目或者中小团队内部图书系统的原型参考。不搞花哨的微服务和消息队列就用单体应用加上缓存和事务讲清楚每一步为什么这么做以及哪些坑是文档里不会告诉你的。1. 需求拆解与整体架构设计1.1 三类核心需求的真实定位先把这个项目的需求拆开看。表面上是“购书商城 抽奖 积分兑换”三个功能块但实际上它覆盖的是一个电商系统最典型的三种业务场景基础交易流、营销激励流、虚拟资产流。图书商城部分解决的是“用户怎么买书”图书展示、分类检索、详情页、购物车、订单、库存扣减、订单状态流转。这部分是纯电商逻辑核心考的是数据建模和事务处理能力。抽奖模块解决的是“怎么让用户愿意来”签到送抽奖次数、下单送抽奖机会、抽奖消耗机会并发放奖品。这里最核心的是概率控制、奖品库存、防刷防并发本质上是一个营销系统的缩影。积分兑换解决的是“怎么让用户留下来”通过购买行为获取积分再用积分兑换优惠券、实物书或周边。积分系统的难度在于账务一致性——积分的发放、扣减、流水记录、过期处理每一步都不能出错。这三块业务看似独立其实共享同一套用户体系、同一套订单数据、同一套事务机制。所以设计的时候不能把它们当成三个孤立的模块来写而要在一开始就统一建模。1.2 技术栈选型背后的理由为什么选Django而不是Flask或者FastAPI我简单说下理由Django自带的ORM和Admin后台能极大加速图书管理后台的开发书籍、分类、订单、奖品的后台维护直接用Admin二次开发就行不用从零写一遍管理界面。Django的中间件、信号、事务钩子比较成熟做积分流水、订单状态变更这类需要“在某个动作发生后自动触发副作用”的场景很方便。模板系统自带如果项目要求服务端渲染页面Django能直接搞定如果分离前后端用它写REST接口也完全够用。数据库选MySQL是因为它是电商系统最稳妥的默认选项事务支持、行级锁、可靠性都够。Redis在这里不是缓存那么简单它承担了三个关键任务抽奖并发计数、积分扣减的原子操作、热点数据的读缓存。模块划分上我建议按照业务域来拆Django应用而不是按“功能类型”来拆bookstore/ # 项目根目录配置、路由、WSGI apps/ users/ # 用户、登录、会员等级 books/ # 图书分类、图书信息、库存 orders/ # 购物车、订单、订单状态流转 lottery/ # 抽奖规则、奖品、抽奖记录 points/ # 积分账户、积分流水、积分商品兑换 promotions/ # 优惠券、活动配置这样拆的好处是订单可以调用积分服务积分服务也可以感知订单行为但调用关系通过服务层控制不直接相互import模型避免应用之间的循环依赖。1.3 数据流和状态流的核心设计整站的数据流我建议这样规划用户浏览图书时先查Redis缓存缓存未命中再查MySQL并回填Redis。用户提交订单时先校验库存和价格再用数据库事务锁住库存行扣减同时生成订单。下单成功后触发信号或同步调用积分服务给用户发放本次消费对应的积分。用户参与抽奖时先校验剩余次数再用Redis的原子自增控制奖品领取数量最后记录抽奖结果并异步发奖。用户兑换积分商品时先检查积分余额是否充足再用乐观锁或行锁扣积分并生成兑换记录。这套流程里有一个最容易被新手忽略的设计订单支付成功后积分发放不能简单地在“支付回调里加一行insert”就完事必须有幂等处理否则回调重试会导致积分重复发放。我在后面的章节会专门讲怎么处理。2. 图书商城模块数据建模和交易主流程2.1 图书数据模型怎么设计才够用又不过度设计图书商城的数据模型不用做得像京东那样复杂但要覆盖一个合格电商系统的核心字段。我给的这套模型是经过实际项目检验的没有多余的字段但刚性需求都包含在内。# apps/books/models.py from django.db import models from django.core.validators import MinValueValidator class Category(models.Model): name models.CharField(max_length50, uniqueTrue, verbose_name分类名) parent models.ForeignKey( self, nullTrue, blankTrue, on_deletemodels.CASCADE, related_namechildren, verbose_name父分类 ) sort_order models.IntegerField(default0, verbose_name排序权重) is_active models.BooleanField(defaultTrue) class Meta: verbose_name 图书分类 ordering [sort_order, id] class Book(models.Model): isbn models.CharField(max_length20, uniqueTrue, verbose_nameISBN) title models.CharField(max_length200, verbose_name书名) author models.CharField(max_length100, verbose_name作者) publisher models.CharField(max_length100, verbose_name出版社) category models.ForeignKey(Category, on_deletemodels.PROTECT, related_namebooks) price models.DecimalField(max_digits8, decimal_places2, verbose_name定价) cover_url models.URLField(blankTrue, verbose_name封面图) description models.TextField(blankTrue, verbose_name简介) stock models.IntegerField(default0, validators[MinValueValidator(0)], verbose_name库存) sales_count models.IntegerField(default0, verbose_name销量) is_on_sale models.BooleanField(defaultTrue, verbose_name上架) created_at models.DateTimeField(auto_now_addTrue) class Meta: verbose_name 图书 indexes [ models.Index(fields[category, is_on_sale]), models.Index(fields[title]), ]几个容易被忽略的设计细节ISBN设成唯一索引这个非常关键。图书商城如果允许同一本书多条记录订单、库存、统计都会乱套。分类使用自引用外键做成树形结构可以支持“文学 小说 科幻”这种多级分类后期做推荐和筛选会比较方便。库存字段用IntergerField加非负校验同时在后端逻辑中必须控制并发扣减不能只依赖validator。价格用DecimalField而不是FloatField这个不用多解释浮点数有精度问题涉及钱的字段必须用十进制。2.2 购物车与订单状态机购物车我给的建议是不建购物车表用Redis存临时数据。理由很直接购物车本身不是核心资产用户关掉页面后大概率不会再回来整理存数据库还要处理登录态、合并、过期成本比收益高得多。用Redis的话数据结构用hash就够了key: cart:{user_id} field: book_id value: quantity后端只需要封装三个操作加购、修改数量、读取购物车。每次加购时顺便做一次库存预检查如果库存不足给前端返回明确提示。订单模型才是重头戏。订单的状态流转我建议做成显式的状态机不要用一堆if-else散落在各个视图里# apps/orders/models.py from django.db import models from django.utils import timezone class Order(models.Model): class Status(models.TextChoices): PENDING_PAYMENT pending_payment, 待支付 PAID paid, 已支付 SHIPPED shipped, 已发货 COMPLETED completed, 已完成 CANCELED canceled, 已取消 REFUNDING refunding, 退款中 order_no models.CharField(max_length32, uniqueTrue, verbose_name订单号) user models.ForeignKey(users.User, on_deletemodels.PROTECT, related_nameorders) status models.CharField(max_length20, choicesStatus.choices, defaultStatus.PENDING_PAYMENT) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name订单总金额) receiver_name models.CharField(max_length50) receiver_phone models.CharField(max_length20) receiver_address models.CharField(max_length200) created_at models.DateTimeField(auto_now_addTrue) paid_at models.DateTimeField(nullTrue, blankTrue) class Meta: verbose_name 订单 indexes [ models.Index(fields[user, status]), models.Index(fields[order_no]), ] class OrderItem(models.Model): order models.ForeignKey(Order, on_deletemodels.CASCADE, related_nameitems) book models.ForeignKey(books.Book, on_deletemodels.PROTECT) book_title models.CharField(max_length200, verbose_name下单时书名快照) book_price models.DecimalField(max_digits8, decimal_places2, verbose_name下单时单价快照) quantity models.IntegerField(verbose_name购买数量) subtotal models.DecimalField(max_digits10, decimal_places2, verbose_name小计) class Meta: verbose_name 订单明细订单明细里的book_title和book_price快照是我特别想强调的一点。如果直接关联Book表去读书名和价格图书改版、价格调整之后历史订单就全乱套了。快照字段就是把下单那一刻的商品信息固化下来这是电商系统的基本素养。订单状态流转我用一个校验函数来控制避免非法跳跃# apps/orders/services.py ORDER_ALLOWED_TRANSITIONS { Order.Status.PENDING_PAYMENT: {Order.Status.PAID, Order.Status.CANCELED}, Order.Status.PAID: {Order.Status.SHIPPED, Order.Status.REFUNDING}, Order.Status.SHIPPED: {Order.Status.COMPLETED, Order.Status.REFUNDING}, } def transition_order(order, target_status): if target_status not in ORDER_ALLOWED_TRANSITIONS.get(order.status, set()): raise ValueError(f非法状态流转: {order.status} - {target_status}) order.status target_status if target_status Order.Status.PAID: order.paid_at timezone.now() order.save(update_fields[status, paid_at, updated_at])这样写的好处有两个第一状态跳转的逻辑集中在一个地方改起来方便第二调用方视图、管理后台、回调处理都走同一个入口不会出现某些状态下漏处理的情况。2.3 下单与库存扣减的事务设计下单是图书商城最容易出并发问题的场景尤其是热门书籍或者促销活动期间。我见过太多项目在这里直接用“先查库存够不够够就减库存然后创建订单”的写法结果高并发下一查一个准库存全变负数。根本原因就是查和减之间不是原子的。正确的做法是先扣减库存再创建订单并且把这两个操作包在同一个事务里同时对库存行加锁from django.db import transaction from django.db.models import F def create_order(user, items, receiver_info): with transaction.atomic(): order Order.objects.create(...) for item in items: # 使用select_for_update锁定图书行 book Book.objects.select_for_update().get(iditem[book_id]) if book.stock item[quantity]: raise ValueError(f《{book.title}》库存不足) book.stock F(stock) - item[quantity] book.sales_count F(sales_count) item[quantity] book.save(update_fields[stock, sales_count]) OrderItem.objects.create( orderorder, bookbook, book_titlebook.title, book_pricebook.price, quantityitem[quantity], subtotalbook.price * item[quantity] ) return order为什么用select_for_update而不是乐观锁因为图书库存是强一致性资源用户下单时必须确保扣减正确行锁在这里是合理的而且锁的粒度很小只锁一本书对应的行不会对整张表产生明显影响。如果是活动期间同一本书频繁被下单行锁反而能排队保护库存不被超卖。提到超卖这里还有一个细节库存扣减不能只依赖数据库热点书籍的库存要提前预热到Redis用Redis的原子操作做秒杀式的库存扣减数据库作为最终的兜底。我在抽奖模块里会详细讲这个思路两者是相通的。另一个容易踩的坑是事务里别做远程调用。比如下单事务里如果混入了发短信、调支付接口、调用外部物流接口事务长时间持有数据库连接并发一高就会出现连接池耗尽。正确做法是事务只做与数据库强相关的操作发送通知和异步任务放到事务提交后再处理可以用Django的transaction.on_commit钩子或者直接把任务塞进Celery。3. 抽奖模块概率、库存与防刷的完整方案3.1 抽奖规则的配置化设计抽奖模块最容易写死的地方就是奖项和概率。很多第一次做这个功能的人直接在代码里写死“一等奖概率0.01二等奖概率0.05”需求一变就要改代码重新上线非常痛苦。我建议把所有规则都配置化存到数据库或者配置文件里运营人员可以随时调整。奖品配置模型可以这样设计# apps/lottery/models.py from django.db import models class LotteryActivity(models.Model): name models.CharField(max_length100, verbose_name活动名称) started_at models.DateTimeField() ended_at models.DateTimeField() daily_limit_per_user models.IntegerField(default0, verbose_name每人每日抽奖次数上限) is_active models.BooleanField(defaultTrue) class Prize(models.Model): activity models.ForeignKey(LotteryActivity, on_deletemodels.CASCADE, related_nameprizes) name models.CharField(max_length50, verbose_name奖品名) level models.IntegerField(verbose_name奖项等级, 1为最高) total_quantity models.IntegerField(verbose_name奖品总数) remaining_quantity models.IntegerField(verbose_name剩余数量) weight models.IntegerField(verbose_name中奖权重) prize_type models.CharField( max_length20, choices[(book, 图书), (coupon, 优惠券), (points, 积分), (none, 未中奖)], verbose_name奖品类型 ) points_value models.IntegerField(default0, verbose_name积分奖品分值) coupon_value models.DecimalField(max_digits8, decimal_places2, nullTrue, blankTrue, verbose_name优惠券面值) book models.ForeignKey(books.Book, nullTrue, blankTrue, on_deletemodels.SET_NULL, verbose_name对应图书)核心字段是weight权重。通过权重而不是百分比的配置方式可以避免“所有奖品概率加起来必须等于1”这种校验麻烦。比如一等奖权重1、二等奖权重5、谢谢参与权重100系统自动计算出总权重为106然后随机数落在哪个区间就命中哪个奖品。调整某个奖项的权重时不需要回头改其他奖项。3.2 权重随机算法和抽奖主流程抽奖的核心算法其实不复杂就是一个“按权重比例映射随机数区间”的过程。先算出总权重再生成一个1到总权重之间的随机整数然后按奖品顺序累加权重看随机数落在哪个区间。import random def draw_prize(activity): prizes list(activity.prizes.order_by(level)) total_weight sum(p.weight for p in prizes) if total_weight 0: raise ValueError(总权重必须大于0) lucky_number random.randint(1, total_weight) acc_weight 0 for prize in prizes: acc_weight prize.weight if lucky_number acc_weight: return prize这个逻辑本身不难难在并发情况下保证奖品不会超发。设想一下一等奖剩余1件同时来了3个请求都在随机数区间里命中了它如果没有额外的库存保护3个人都会认为自己中了奖但奖品只有1件。解决办法有两个层面数据库层面更新剩余数量时用条件更新UPDATE lottery_prize SET remaining_quantity remaining_quantity - 1 WHERE id ? AND remaining_quantity 0;受影响行数为0就说明名额已被抢完此时需要重新抽一次。这是数据库级别的原子操作不会超发。Redis层面在抽奖热点时期可以把奖品剩余数量预热到Redis用DECR命令来扣减。DECR是原子操作即使并发很高也不会扣成负数扣到负数就说明库存没了需要回滚并重新抽奖。我建议两层同时用Redis做第一层快速拦截和削峰数据库条件更新做最终兜底保证极端情况下的数据一致性。3.3 抽奖防刷的四个关键手段抽奖功能如果不在防刷上下足功夫活动上线第一天就会被刷爆。我吃过这个亏所以强烈建议提前把下面这些规则定好第一用户维度频控。每个用户每天最多抽N次用Redis的计数器实现key为lottery:{activity_id}:user:{user_id}:{yyyymmdd}每次抽奖前检查计数是否达到上限并发场景下用INCR后判断返回值而不是先GET再SET。第二IP维度频控。同一个IP下多个账号的抽奖次数每天也设一个总上限防止工作室批量注册账号薅羊毛。虽然IP不完全可靠但能挡掉相当一部分初级刷量。第三设备指纹维度。如果有前端配合可以采集一些浏览器和设备特征比如Canvas指纹、UserAgent组合等做成一串设备码以此为单位做频控。这个方案对防刷效果最好但实现成本也最高小项目可以不做。第四抽奖行为时机校验。抽奖机会的获取必须绑定真实的用户行为比如“每日登录送1次”“下单满50元送1次”。机会发放走服务端逻辑不能相信前端传过来的参数。很多被刷的空子就出在“机会发放”这个环节——假设前端能传lottery_times999那后端就没法防了。3.4 中奖后的发奖流程怎么保证不出错中奖后一般有两种处理方式即时发奖和异步发奖。我推荐异步发奖。原因有两点第一发奖通常涉及多个系统如果中奖送的是优惠券要生成券码、关联用户、标记有效期如果送的是图书要生成发货单、触发物流流程这些操作不适合在用户抽奖的HTTP请求里同步完成耗时太长第二异步可以把发奖失败重试的逻辑和用户主流程解耦不至于因为某个奖品发放异常导致整个抽奖接口报错。具体到发奖类型不同奖品有不同处理逻辑积分奖品调用积分服务给用户加积分同时产生一条积分流水。加分必须幂等加唯一索引约束避免重复发放。优惠券奖品在优惠券表里生成一条用户券记录带有效期和适用范围。图书奖品创建一笔类型为“抽奖中奖”的特殊发货单走订单系统但金额为0标记奖品关联抽奖记录ID。这里要特别提醒抽奖记录和中奖发奖的关系必须带上一次抽奖的唯一ID作为幂等键。异步任务可能因为异常被重试如果没有幂等控制同一个中奖记录会被发两次奖。我前面说的“先记录再发奖、发奖后回写发送状态”是稳妥的做法。class LotteryRecord(models.Model): user models.ForeignKey(users.User, on_deletemodels.PROTECT) activity models.ForeignKey(LotteryActivity, on_deletemodels.CASCADE) prize models.ForeignKey(Prize, nullTrue, blankTrue, on_deletemodels.SET_NULL) result_name models.CharField(max_length50, verbose_name中奖结果描述) is_winning models.BooleanField(defaultFalse) prize_status models.CharField( max_length20, choices[(pending, 待发放), (sent, 已发放), (failed, 发放失败)], defaultpending, verbose_name发奖状态 ) created_at models.DateTimeField(auto_now_addTrue) class Meta: indexes [models.Index(fields[user, created_at])]发奖任务每次执行前查一下prize_status如果已经是sent就直接跳过如果failed就重试用这条状态作为天然的幂等判断依据不需要额外引入分布式锁。4. 积分系统与兑换流程账务一致性的硬仗4.1 积分账户、积分流水的双表设计积分的核心难点不是“加一个数字”而是“这笔积分怎么来的、怎么没的、还剩多少”。只用一个points字段存总额的做法在项目初期省事但一旦需要排查“用户积分为什么对不上”这种问题就完全没有回溯的依据。所以我强烈推荐用账户流水的双表设计# apps/points/models.py from django.db import models from django.core.validators import MinValueValidator class PointsAccount(models.Model): user models.OneToOneField(users.User, on_deletemodels.CASCADE, related_namepoints_account) balance models.IntegerField(default0, verbose_name可用积分) blocked_balance models.IntegerField(default0, verbose_name冻结积分) updated_at models.DateTimeField(auto_nowTrue) class Meta: verbose_name 积分账户 class PointsTransaction(models.Model): class ChangeType(models.TextChoices): EARN_ORDER earn_order, 下单获得 EARN_LOTTERY earn_lottery, 抽奖获得 EARN_ADMIN earn_admin, 后台调整 CONSUME_EXCHANGE consume_exchange, 兑换消耗 CONSUME_EXPIRE consume_expire, 过期扣除 REFUND refund, 退款退回 user models.ForeignKey(users.User, on_deletemodels.PROTECT, related_namepoints_transactions) account models.ForeignKey(PointsAccount, on_deletemodels.PROTECT) change_type models.CharField(max_length20, choicesChangeType.choices) amount models.IntegerField(verbose_name变动值, 正数为增加, 负数为扣减) balance_after models.IntegerField(verbose_name变动后余额) ref_order_no models.CharField(max_length64, blankTrue, verbose_name关联单号) remark models.CharField(max_length255, blankTrue) created_at models.DateTimeField(auto_now_addTrue) class Meta: verbose_name 积分流水 indexes [ models.Index(fields[user, created_at]), models.Index(fields[ref_order_no]), ]这里有三个设计重点一是balance_after字段。每笔流水不仅要记录变动了多少还要记录当时余额是多少。这样出问题的时候按时间顺序拉出流水一眼就能看出哪一步余额对不上。二是ref_order_no关联单号字段。积分的每次变动都要能关联到业务单据比如订单号、抽奖记录ID、兑换单号。否则用户投诉“我积分怎么少了”的时候后台压根没法解释每一笔变动的来源。三是冻结积分字段blocked_balance。用户发起兑换时先把对应积分冻结而不是直接扣减。如果兑换取消或失败解冻退回如果兑换完成冻结转正式扣减。这个设计和电商退款处理里的冻结资金是一个思路能避免很多“积分被扣了但东西没换到”的纠纷。4.2 积分赚取下单后如何安全地加分下单送积分是最常见的积分来源也是最容易出重复发放问题的地方。支付回调可能因为网络原因重试多次如果你直接写“回调里加积分”每重试一次就加一次用户的钱只付了一次积分却翻倍了。我建议的做法是把积分发放放到一个独立的方法里用订单号做幂等# apps/points/services.py from django.db import transaction def earn_points_for_order(order): account, created PointsAccount.objects.get_or_create(userorder.user) # 检查流水是否已存在保证幂等 if PointsTransaction.objects.filter( userorder.user, change_typePointsTransaction.ChangeType.EARN_ORDER, ref_order_noorder.order_no, ).exists(): return 0 points_to_add int(order.total_amount) # 简化规则每消费1元返1积分 with transaction.atomic(): account PointsAccount.objects.select_for_update().get(userorder.user) account.balance F(balance) points_to_add account.save(update_fields[balance, updated_at]) account.refresh_from_db() PointsTransaction.objects.create( userorder.user, accountaccount, change_typePointsTransaction.ChangeType.EARN_ORDER, amountpoints_to_add, balance_afteraccount.balance, ref_order_noorder.order_no, remarkf订单{order.order_no}完成 ) return points_to_add这个实现里有几个关键点先查流水是否存在存在就直接返回这是幂等检查。用select_for_update锁账户行后再更新余额防止“读余额-写余额”之间出现并发问题。用F表达式直接在数据库层面做加法避免先读后写的竞态条件。写完余额后refresh_from_db()再把准确的余额写入流水。这里要提醒一下不要把积分发放和订单状态更新放在同一个事务里。订单状态回调是高频操作如果积分发放逻辑过于复杂或者积分账户恰好被其他操作锁住会拖慢订单回调的性能。更稳妥的做法是在回调里先更新订单状态然后调用积分发放方法积分方法自己有事务和幂等控制即使失败也可以重试。4.3 积分兑换并发扣减防负数积分兑换的流程是用户选择积分商品 → 检查积分是否够 → 扣积分 → 生成兑换记录 → 发放商品。最容易出事故的是“检查积分够”和“扣积分”之间的窗口期。两个请求同时发起兑换各自都查到余额1000分商品分别需要600分两个事务都通过检查最后余额变成-200这就是经典的超扣问题。解决方案就是前面提过的行锁# apps/points/services.py from django.db import transaction from django.db.models import F def exchange_points_goods(user, points_goods_id): goods PointsGoods.objects.select_for_update().get(idpoints_goods_id) if goods.remaining_quantity 0: raise ValueError(兑换商品已兑完) with transaction.atomic(): account PointsAccount.objects.select_for_update().get(useruser) if account.balance goods.required_points: raise ValueError(积分余额不足) # 扣减积分 account.balance F(balance) - goods.required_points account.save(update_fields[balance, updated_at]) account.refresh_from_db() # 扣减商品库存 goods.remaining_quantity F(remaining_quantity) - 1 goods.save(update_fields[remaining_quantity]) # 生成兑换记录 exchange_record PointsExchangeRecord.objects.create( useruser, goodsgoods, exchange_nogenerate_exchange_no(), points_costgoods.required_points, statuspending, ) PointsTransaction.objects.create( useruser, accountaccount, change_typePointsTransaction.ChangeType.CONSUME_EXCHANGE, amount-goods.required_points, balance_afteraccount.balance, ref_order_noexchange_record.exchange_no, remarkf兑换{goods.name}, ) return exchange_record注意在事务里我把积分账户和兑换商品都加了行锁锁的顺序是“账户→商品”这里有个经验之谈多资源锁定的顺序必须全局一致否则可能出现死锁。抽奖事务要锁“奖品→账户”兑换事务要锁“账户→奖品”如果顺序不统一两个事务互相等待对方持有的锁数据库就会抛死锁异常。定一个全局约定先加积分账户锁再加业务资源锁能规避很多麻烦。4.4 积分过期与退款问题如何处理积分过期是很多项目上线很久后才遇到的问题。schema设计时没有过期字段临时要加就费劲了。我建议在积分流水的设计里提前预留两个与过期相关的字段或者在积分账户上增加“积分到期时间”维度的表。简单做法是给每笔积分流水加一个expire_at字段定期任务到期时生成“过期扣减”类型的流水。退款场景也必须提前设计如果用户用积分加现金购买了商品订单退款时按规则要把部分积分退回给用户。这个过程同样要写流水并且在订单模型上关联积分使用记录否则财务对账时会发现负数余额问题。5. 高频疑难杂症与实战排查5.1 并发超卖为什么锁了还是超了这是我在排查线上问题时遇到最多的一类。症状是活动开始后后台发现库存变成了负数或者发出去的奖品超过了配置的总数。原因通常是以下三种情况之一第一种没锁就更新。代码逻辑是“先读库存再判断再更新”这种必炸的概率很高。解法是用select_for_update或者条件更新SQL。第二种锁了但锁的粒度不对。比如锁的是整张表而不是对应的行或者锁的key用的是“活动ID”而不是“具体奖品ID”导致所有奖品的所有并发请求都互相阻塞吞吐量骤降或者反过来锁的key粒度太小没有覆盖到真正需要同步的资源。第三种事务范围不对。有的开发者把锁写在事务外锁住的查询跑完了事务还没开始另一个请求照样可以溜进来。关于这一点我在第2章已经强调过select_for_update必须在事务内才有效事务结束锁就释放了。我见过一个很隐蔽的坑用filter(idxxx).update(...)这种条件更新时如果条件是“剩余数量 0”更新行数为0时没有做“重新抽奖”的处理而是直接把结果返回为失败。用户明明中了奖却因为并发导致奖品被抢完而失败这种体验比较糟糕。所以条件更新失败时应该重新走一遍抽奖流程而不是直接返回失败。5.2 抽奖机会和积分被重复发放重复发放这个问题的根源通常不是SQL写错而是缺少幂等控制。支付回调被重试、异步任务被重放、用户连续快速点击提交按钮都会触发重复执行。我总结的排查思路是先看业务单据上有没有唯一的幂等键。订单靠order_no、抽奖靠record_id、积分流水靠ref_order_no加change_type的组合。如果没有唯一键约束就在数据库层面加唯一索引。前端防重复点击只是降低概率不能作为业务保障。真正可靠的幂等只能靠后端。支付回调这种外部系统调用尤其要仔细处理如果回调方没有提供幂等键可以用“订单号支付状态”作为幂等判断处理好已支付状态下的重复回调。5.3 线上为什么越来越慢缓存和索引排查图书商城上线跑一段时间后最常见的性能问题是列表页和大促活动时的热点查询变慢。原因通常是下面几个商品列表的SQL没有走索引比如按category和is_on_sale筛选时没建立复合索引导致全表扫描。订单查询按user和status过滤时没有索引用户订单页一打开就慢。图书详情页每次都查数据库没有加Redis缓存。热门书籍被频繁访问数据库压力陡增。排查方法很简单在MySQL里执行EXPLAIN看扫描行数重点看type和rows字段。然后针对慢查询SQL建立合适的索引。缓存的思路我建议分级图书详情用Redis缓存key包含图书ID和状态分类列表页可以缓存整页数据但要注意更新时机。图书信息变更时要主动删除缓存避免脏数据。5.4 死锁和锁等待的实战处理并发系统中不可避免会遇到死锁。MySQL抛错形如Deadlock found when trying to get lock; try restarting transaction很多开发者第一次看到就懵了。死锁的产生往往和两个事务加锁顺序不一致有关。比如这个场景事务A先锁账户后锁奖品事务B先锁奖品后锁账户两个事务互相等对方的锁就形成死锁。处理死锁有固定的套路一是统一加锁顺序全项目约定一个固定的锁获取顺序我在第4章已经提过。二是尽量缩短事务时间。事务里不要做网络IO不要调用外部接口不要让用户在事务等待期间还坐着思考要把一切耗时操作挪到事务外。三是设置合理的锁等待超时时间和事务超时时间。给数据库和Django的事务加上超时控制一个事务如果因为等待锁超过几秒还没拿到就应该快速失败并回滚而不是无限期等下去。四是对死锁异常做重试。即便做了前面的优化高并发下死锁仍然小概率会发生业务代码里捕获死锁异常并重试整个事务是最后一道兜底手段。5.5 订单和积分账对不上怎么快速定位最后聊一个财务类问题后台对账时发现订单总额和积分发放总额对不上或者用户积分余额和流水对不上。这种问题最磨人但也能最大程度检验一个系统的设计质量。如果系统是从一开始就按我前面说的“账户流水balance_afterref关联单号”来设计的排查路径会清晰很多挑一个出问题的用户按时间顺序拉出他所有的积分流水。把流水的正向变动和负向变动分别汇总算出理论余额。和账户当前余额对比定位出哪一笔流水算错或者缺失。顺着ref_order_no找到对应的订单或兑换记录核实业务状态。如果流水汇总和账户余额对不上大概率是某处代码绕过流水直接改了余额这种问题要找代码里所有PointsAccount.objects.update(balance...)的调用点排查。订单积分对不上的情况绝大多数和退款有关退款时订单状态变为“已退款”但没有同时生成冲减积分的流水或者冲减的金额计算错误。解决方法是退款流程里强制走积分回退服务并且在订单模型上保存“该订单已发放积分”“该订单已回退积分”的状态字段双保险。6. 后台管理和监控告警的落地建议一个线上购书平台如果只有前台没有后台运营效率会极其低下。Django Admin在项目初期就是最好的后台不用重复造轮子但要做几件事给图书和订单注册Admin加上搜索和筛选给抽奖活动配置注册Admin方便运营调整权重和上下线给积分流水注册只读Admin防止误操作。奖品库存低于阈值时生成告警提现到监控系统或者直接发邮件这个可以做成一个简单的定时任务。接口层面要统一封装一个响应格式错误信息不能把数据库异常裸奔给前端要有一个全局异常捕获。日志是排查线上问题最依赖的工具每个关键节点比如下单、支付、抽奖、兑换都要打操作日志。如果项目没有接日志平台先用本地文件按日期切割把请求ID和业务单号关联起来。等到系统复杂了再考虑全链路追踪。监控分两条线业务监控看核心指标比如下单成功率、支付回调延迟、抽奖参与次数、奖品库存水位、积分发放量技术监控看系统资源比如Redis命中率、MySQL慢查询数量、连接数、Django请求平均响应时间。这些指标不一定要上重型监控平台先有数据再谈可视化。最后再分享一点我的切身体会这类带营销玩法的商城项目最考验人的不是某一个单点功能而是跨模块的数据一致性。买书送积分、抽奖中优惠券、优惠券又能抵扣书款链路一绕状态一变错排查起来就是连环事故。我个人的建议是在动手写代码之前先把所有跨模块的交互画成一张状态流转表把每个状态变更对应的积分、库存、发奖动作都列清楚再开始建表。如果代码已经写到一半也值得停下来补上这个步骤。我踩过最大的坑就是“先把功能写出来再说”结果上线后用户薅了一次活动羊毛积分和奖品对不上账连续两个通宵都在手工修数据。后来我把所有涉及余额、库存、发奖的写操作全部重构成“事务内锁行 流水留痕 幂等键控制”之后再也没有出过同类的账务问题。如果你也想让这个项目在线上稳定跑下来我建议你把这三条原则当成硬标准来执行。
