yii中房态管理需以“日期+房型”为粒度建模于room_availability表，用select ... for update行锁校验并原子更新locked_count，结合订单状态事件或消息队列释放/确认锁定，辅以redis缓存（空值防护+降级机制）保障高并发下一致性与性能。
民宿预订系统中，房态（Room Availability）是核心业务逻辑之一，直接关系到超订、重复下单、库存不一致等关键问题。Yii 框架本身不提供房态管理组件，需结合业务规则、数据库事务、缓存策略与时间粒度设计来保障一致性与性能。
房态数据建模：按日期+房型粒度存储
避免用“剩余房间数”这种易冲突的整型字段，推荐采用“日期维度 + 房型维度 + 预订状态快照”的方式建模：
- 表名建议 room_availability，字段含：room_type_id、date（DATE 类型，如 '2025-04-10'）、available_count（当日该房型可售间数）、locked_count（已预占/待支付锁定数）、updated_at
- 主键设为 (room_type_id, date)，确保单日单房型唯一，便于乐观锁或条件更新
- 初始化需按运营周期（如未来180天）批量生成基础记录，可用 Yii 命令行脚本（yii room/init-availability）完成
预订流程中的房态校验与锁定
用户提交订单时，不能仅查“是否 > 0”，而要原子性完成“检查→预留→落库”，推荐在 ActiveRecord 层封装方法：
- 使用 SELECT ... FOR UPDATE（InnoDB 行锁）查询指定日期范围内的房态记录，例如：4月10日至4月12日共3天，需锁定这3条记录
- 逐日校验 available_count - locked_count >= 1；任一日不满足则中断并抛出 InvalidParamException('房态不足')
- 校验通过后，对每条记录执行 locked_count = locked_count + 1 更新（带 WHERE 条件防止并发覆盖），返回影响行数做二次确认
- 若更新失败（如被其他请求抢先锁定），自动重试 1–2 次，超时则回滚整个事务
订单状态变更触发房态释放或确认
房态锁定不是永久的，必须绑定订单生命周期进行清理：
- 支付成功：调用 confirmBooking($order)，将对应日期的 locked_count 减 1，available_count 减 1
- 订单取消 / 支付超时：调用 releaseLock($order)，仅将 locked_count 减 1（不扣 available_count）
- 建议用 Yii 的 afterInsert / afterUpdate 事件监听订单状态变更，或通过消息队列（如 RabbitMQ）异步处理，避免主流程阻塞
- 补充定时任务（yii cron:cleanup-lock），每天扫描 locked_count > 0 且关联订单状态异常（如 pending 超过30分钟） 的记录，自动释放锁定
读多写少场景下的缓存与降级策略
房态查询频次远高于修改，尤其在搜索页、日历控件中，需兼顾实时性与响应速度：
- 使用 Redis 存储热房态数据，Key 格式如 avail:{room_type_id}:{date}，值为 JSON 字符串 {"available":2,"locked":1}
- 写操作（锁定/确认/释放）后，同步更新 Redis，并设置合理过期时间（如 10 分钟），避免缓存雪崩
- 缓存穿透防护：对查不到的日期+房型组合，也写入空对象（TTL 缩短至 60s），防止恶意刷不存在的日期
- Redis 不可用时，自动降级为直连数据库查询，不影响核心功能，仅牺牲部分性能
