17. 健身房会员管理系统（technical-architecture）

1. 系统架构设计

1.1 总体架构

本系统采用前后端分离的微服务架构（或模块化单体架构，视规模而定），以适应移动端（会员/教练）和PC端（管理后台）的不同交互需求。

• 客户端:
  • 会员端: 微信小程序/APP，侧重轻量级交互、预约、数据查看。
  • 教练端: 微信小程序/APP，侧重日程管理、学员互动。
  • 管理后台: Web端 SPA，侧重复杂的数据录入、报表分析、全局配置。
• 服务端: 提供统一的 RESTful API 或 GraphQL 接口。
• 数据层: 关系型数据库存储核心业务数据，缓存层处理高频读写和会话，时序数据库（可选）存储IoT设备或高频运动数据。

1.2 模块划分

• User Center: 用户认证、角色权限、基础档案管理。
• Membership Service: 会员卡核心逻辑，包括发卡、续费、状态变更、权益计算。
• Course & Booking Service: 课程排期、库存管理、预约逻辑、签到核销。
• Training Service: 健身计划库、动作库、体测数据记录。
• Analytics Service: 报表生成、数据聚合、大屏展示接口。
• Notification Service: 消息推送（预约提醒、过期提醒、营销通知）。

2. 技术栈选型

2.1 前端

• 会员/教练端 (小程序/APP):
  • 框架: Uni-app (跨平台推荐) 或 Taro / React Native / Flutter。
  • UI库: uView UI / Vant Weapp - 轻量、美观、适合移动端。
• 管理后台 (Web):
  • 框架: Vue 3 或 React。
  • UI组件库: Element Plus (Vue) 或 Ant Design (React)。
  • 数据可视化: ECharts (百度开源，功能丰富，适合各类统计图表) 或 AntV F2 (移动端优化)。
  • 日历组件: FullCalendar 或 tui-calendar (处理排课视图)。

2.2 后端

• 开发语言: Node.js (NestJS/Koa) / Java (Spring Boot) / Go (Gin)。
• 数据库:
  • MySQL / PostgreSQL: 核心业务数据存储。
  • Redis: 缓存热门课程信息、处理抢课锁、存储用户Session。
• 对象存储: 阿里云OSS / AWS S3 (存储会员头像、体测照片、课程封面)。

2.3 关键中间件

• 消息队列: RabbitMQ / Kafka (用于预约成功通知、解耦数据统计任务)。
• 定时任务: XXL-JOB 或 Quartz (用于每日扫描过期会员卡、自动释放未支付预约)。

3. 数据库设计 (核心表结构示例)

3.1 会员卡表 (membership_cards)

• id: Primary Key
• member_id: Foreign Key, 持卡人
• card_template_id: Foreign Key, 卡种模板
• type: Enum (Time, Count, StoredValue), 卡类型
• balance: Decimal/Integer, 余额/余次
• start_date: Date, 生效日期
• end_date: Date, 失效日期
• status: Enum (Active, Frozen, Expired), 状态
• frozen_start_date: Date, 冻结开始时间 (用于计算顺延)

3.2 课程排期表 (course_schedules)

• id: Primary Key
• course_id: Foreign Key, 课程定义
• coach_id: Foreign Key, 授课教练
• room_id: Foreign Key, 教室
• start_time: DateTime, 上课时间
• end_time: DateTime, 下课时间
• max_attendees: Integer, 最大人数
• booked_count: Integer, 已约人数 (需并发控制)
• status: Enum (Open, Full, Cancelled, Finished)

3.3 预约记录表 (bookings)

• id: Primary Key
• schedule_id: Foreign Key, 排期ID
• member_id: Foreign Key, 会员ID
• card_id: Foreign Key, 使用的会员卡ID
• status: Enum (Confirmed, Cancelled, CheckedIn, Absent)
• create_time: DateTime
• queue_number: Integer, 候补排位 (若为候补状态)

3.4 体测数据表 (body_metrics)

• id: Primary Key
• member_id: Foreign Key
• record_date: Date, 记录日期
• weight: Decimal, 体重
• body_fat_rate: Decimal, 体脂率
• bmi: Decimal
• photos: Json, 体型照片URL列表

4. 关键技术实现方案

4.1 预约并发控制 (Booking Concurrency)

• 问题: 热门团课名额有限，可能出现多人同时点击预约导致超卖。
• 方案:
  1. Redis预减库存: 将课程名额存入Redis，预约请求先在Redis中扣减 (DECR)。
  2. 扣减成功: 进入消息队列，异步写入数据库生成订单/预约记录。
  3. 扣减失败: 直接返回“已满员”或提示加入候补。
  4. 数据一致性: 定时任务比对Redis与DB库存，处理异常情况。

4.2 会员卡状态自动化 (Card Status Automation)

• 过期处理: 每日凌晨运行定时任务，扫描 end_date < today 且状态为 Active 的卡片，更新为 Expired。
• 请假/冻结逻辑:
  • 会员申请冻结，设置 frozen_start_date，状态变更为 Frozen。
  • 解冻时，计算 (today - frozen_start_date) 的天数，将 end_date 向后顺延相应天数，状态恢复 Active。

4.3 数据可视化 (Data Visualization)

• 体测趋势图: 前端使用 ECharts 折线图组件。
• 数据处理: 后端提供聚合接口，返回按时间排序的 [date, value] 数组。
• 交互: 支持缩放（DataZoom），查看不同时间跨度（近1月、近3月、近1年）的体重/体脂变化曲线。

4.4 智能排课冲突检测

• 在管理员或教练排课时，后端需校验：
  • 该教练在此时段是否已有排课。
  • 该教室在此时段是否被占用。
• 算法: 查询 course_schedules 表，条件 (new_start < existing_end) AND (new_end > existing_start)。若存在记录则提示冲突。