基于SpringBoot的游乐场一卡通充值消费系统毕业设计源码(源码+lw+部署文档+讲解等)

博主介绍：✌ 专注于VUE,小程序，安卓，Java,python,物联网专业，有18年开发经验，长年从事毕业指导，项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题，我会尽力帮助你。

一、研究目的

随着信息技术的迅猛发展，游乐场等娱乐设施正面临着从传统人工收费向智能化、数字化运营模式转型的迫切需求。传统一卡通系统普遍存在充值与消费分离、数据同步滞后、交易安全性不足以及对业务扩展支持有限等短板，这些问题不仅导致运营成本上升，还影响游客体验与商业决策的及时性。为此，构建一套基于SpringBoot的统一充值消费平台显得尤为重要，该平台需具备高并发处理能力、灵活的业务拓展机制以及完善的数据安全保障，以满足游乐场多元化业务场景下对实时性与可靠性的双重要求。

本研究旨在通过微服务架构实现一卡通充值与消费功能的无缝集成，并在此基础上提供统一的接口规范、数据存储方案与监控体系，以实现业务流程的自动化与可视化。具体目标包括：①采用SpringBoot框架搭建核心服务，支持RESTful API调用；②设计分布式事务管理机制，确保充值与消费操作的一致性；③集成主流支付渠道和二维码扫码技术，实现多渠道支付体验；④构建安全认证与权限控制模块，防止恶意攻击与数据泄露；⑤利用缓存与消息队列提升系统吞吐量与响应速度；⑥通过日志分析与指标监控，为运营团队提供实时业务洞察。研究方法将采用需求调研、系统设计、原型实现、性能测试和用户体验评估等步骤，并在实际游乐场环境中进行部署验证。预期成果包括一套可复用的微服务框架、完整的技术文档与案例分析，为行业提供可复制、可扩展的解决方案，推动游乐场运营模式向数字化、智能化迈进。

二、研究意义

本研究在游乐场一卡通系统领域具有重要的产业价值与社会意义，能够显著提升运营效率与服务质量。传统人工收费模式存在交易延迟、数据不一致以及安全隐患等缺陷，而基于SpringBoot的微服务架构能够实现高并发处理与模块化扩展，满足游乐场多业务场景下对实时性与可靠性的双重需求。通过统一的充值与消费接口，运营人员可实现对客流、收入与库存的实时监控，从而优化资源配置与营销策略。与此同时，系统集成多渠道支付方式与二维码扫码技术，为游客提供便捷的支付体验，提升用户满意度与复购率。安全方面，本研究采用JWT鉴权、TLS加密及细粒度权限控制，有效防范恶意攻击与数据泄露风险，保障财务安全与个人隐私。系统设计中引入分布式事务管理与消息队列，实现跨服务的数据一致性与异步处理，进一步提升业务吞吐量与可用性。通过部署实验验证，本研究展示了在实际游乐场环境中实现高可用、低延迟的全流程一卡通服务，为行业提供可复制、可扩展的技术范式。

从学术视角看，本研究填补了微服务架构在娱乐行业应用中的空白，系统性地探讨了SpringBoot框架与分布式事务、缓存与监控技术的协同作用。通过对比实验，本研究验证了微服务化设计相较于传统单体应用在性能、可维护性与弹性伸缩方面的优势，为后续相关领域的系统设计提供了经验与参考。研究中提出的安全模型结合JWT与TLS实现细粒度访问控制，为分布式系统安全研究提供了可操作的方案。性能评估结果表明，采用消息队列与缓存技术能够将平均响应时间降低至毫秒级，显著提升用户体验。综上所述，本研究不仅在产业实践中具有推广价值，也为微服务架构、分布式事务管理与安全设计等学术议题提供了新的研究视角与实验数据，具有重要的理论与应用双重意义。

三、国内外研究现状

在全球信息化快速发展的背景下，基于微服务架构的智能门票与一卡通系统已成为研究热点，尤其在旅游、娱乐与公共交通等行业中得到了广泛关注。SpringBoot作为一种轻量级的Java开发框架，以其简洁的配置方式、丰富的生态插件以及对微服务模式的天然支持，在国内外学术界和工业界均被视为构建高可用、可扩展系统的重要技术手段。近年来，相关研究多聚焦于如何通过微服务实现业务模块的解耦、如何提升系统吞吐量以及如何保障分布式事务的一致性。

在国内，主要研究机构与高校普遍将SpringBoot与云原生技术相结合，以满足大规模并发访问的需求。学者们提出了基于Dubbo或Spring Cloud的服务治理方案，并通过熔断器、限流器等机制提升系统弹性。针对娱乐行业的支付与消费场景，国内研究重点在于实现多渠道支付集成、二维码扫码交易以及实时数据同步。通过引入Redis缓存与Kafka消息队列，实验结果表明系统平均响应时间可降至毫秒级，吞吐量显著提升。此外，一些团队在安全方面开展了基于JWT与TLS的鉴权模型研究，并结合细粒度权限控制实现对用户数据的精细管理。国内研究也关注业务智能化，利用大数据平台对消费行为进行实时分析，为运营决策提供支持。

在国外，相关研究主要集中在云计算平台与区块链技术的融合上。学术论文普遍探讨如何通过区块链实现门票的不可篡改与双重支付防护，并将其与微服务架构结合，以提升系统透明度与信任度。美国、欧洲等地区的研究者则在分布式事务管理方面提出了基于Saga模式的解决方案，并通过实验验证其在高并发场景下的可行性。国外学术会议上，关于微服务性能调优的论文多强调容器化部署与自动伸缩策略，指出通过Kubernetes等平台可实现弹性扩容与资源优化。安全研究方面，国外团队关注零信任网络访问（Zero Trust）与多因素身份验证的结合，以提升系统对外部攻击的抵御能力。

综上所述，国内外在基于SpringBoot的微服务系统研究中已取得诸多成果，包括高并发处理、分布式事务一致性、支付渠道集成以及安全鉴权等方面。然而，针对游乐场一卡通充值与消费的完整闭环系统仍缺乏统一的技术框架与标准化接口。现有研究多聚焦于单一业务模块或分散的技术实现，缺少针对娱乐行业特定业务流程的整体解决方案。为填补这一空白，亟需在微服务架构基础上进一步整合支付、数据同步、实时监控与安全防护等关键技术，并通过实验验证其在真实游乐场环境中的可行性与性能优势。

四、预期达到目标及解决的关键问题

预期目标在于构建一套基于SpringBoot的微服务框架，实现游乐场一卡通充值与消费业务的全流程自动化与实时化。首先，系统需支持多渠道支付集成，包括传统银行卡、移动支付及二维码扫码等方式，并通过统一的RESTful接口实现充值、消费与余额查询功能；其次，需实现分布式事务管理机制，保证跨服务调用中的数据一致性；再次，系统应具备高并发处理能力，能够在峰值时段维持毫秒级响应时间；第四，安全方面要求采用JWT鉴权、TLS加密及细粒度权限控制，以防止未授权访问与数据泄露；第五，通过引入缓存与消息队列技术，实现业务解耦与异步处理，提升系统吞吐量与可维护性；第六，构建监控与日志分析平台，实时获取业务指标并支持故障定位。关键问题主要包括：①如何在微服务架构下实现高效的分布式事务管理，避免传统两阶段提交的性能瓶颈；②在多支付渠道集成过程中，如何统一交易状态、异常处理与回滚策略；③在高并发场景下，如何通过缓存与消息队列实现业务解耦，同时保证最终一致性；④系统安全设计需兼顾性能与防护力度，如何在保持低延迟的前提下实现多因素身份验证与细粒度权限控制；⑤监控与告警体系的设计需覆盖业务、平台及网络层面，确保快速响应与故障恢复。通过解决上述关键问题，可实现一套高可靠、高性能且安全可扩展的一卡通充值消费系统。

五、研究内容

本研究以构建基于SpringBoot的游乐场一卡通充值消费系统为核心，围绕微服务架构展开系统化设计与实现。首先，系统总体架构采用服务拆分与容器化部署策略，将用户管理、支付处理、消费记录、优惠券管理及监控告警等业务功能拆分为独立的微服务；每个微服务均通过SpringBoot快速搭建，并使用Spring Cloud Config进行配置中心化管理，以实现统一的配置治理。其次，采用Dubbo或Spring Cloud OpenFeign实现服务间调用，利用熔断器Hystrix或Resilience4j实现容错与降级机制，从而提升系统整体可用性。

在技术细节层面，本研究重点解决分布式事务一致性问题。为此，系统引入Saga模式的补偿事务设计，并通过消息中间件Kafka实现事件驱动的异步补偿流程；同时，利用Spring Cloud Sleuth与Zipkin对跨服务调用链进行追踪，以便快速定位事务异常。支付渠道集成方面，系统支持多种支付方式，包括银行卡、支付宝、微信以及二维码扫码等；通过统一的支付网关服务，将不同支付平台的接口抽象为标准化的RESTful API，并在服务层实现统一的异常处理与回滚策略。

为保障系统高并发性能与低延迟响应，研究采用Redis缓存热点数据（如用户余额、优惠券信息）以及使用RocketMQ或Kafka实现消费记录的异步写入；同时，利用Spring Cloud Gateway进行请求路由与限流控制，并通过Nginx或Envoy实现负载均衡。安全层面，系统采用JWT进行无状态鉴权，并在传输层使用TLS加密；细粒度权限控制通过Spring Security ACL实现，支持角色与资源的动态绑定。所有微服务均部署于Docker容器中，并通过Kubernetes实现弹性伸缩与自愈能力。

最后，本研究将构建完整的监控与运维体系。通过Prometheus采集各服务指标，并结合Grafana可视化展示；同时，利用ELK（Elasticsearch-Logstash-Kibana）堆栈实现日志集中管理与实时分析；对关键业务指标设置阈值告警，并通过Slack或邮件推送给运维团队。实验验证阶段，将在真实游乐场环境中部署系统，收集充值、消费、并发请求等数据，评估系统吞吐量、平均响应时间与事务一致性；并与传统单体应用进行对比，验证微服务架构在性能与可维护性方面的优势。

六、需求分析

用户需求  
在游乐场一卡通系统的使用场景中，主要用户群体包括游客、园区运营人员以及系统管理员。游客对系统的首要需求是充值与消费过程的便捷与高效，期望能够通过多种支付方式（如银行卡、移动支付及二维码扫码）完成一次性或分批充值，并在进入游乐设施时实现快速扫码消费，避免排队等待；同时，游客还希望能够随时查询余额与交易记录，以便掌握个人消费情况并进行预算管理。运营人员则关注系统的实时性与准确性，需要在后台及时获取客流量、收入与库存等关键指标，以支持动态定价与资源调度；他们还需要对异常交易进行快速定位和处理，保障园区运营的顺畅。系统管理员则更侧重于整体系统的安全与可维护性，要求具备完善的权限管理、日志审计与故障恢复机制，以确保数据完整性与业务连续性。综上所述，用户需求主要体现在交易便捷、实时信息获取、安全可靠以及运维支持四个维度。

功能需求  
基于上述用户需求，系统需实现以下核心功能。首先，账户管理模块提供游客注册、登录与身份验证服务，并支持多因素身份验证与密码重置；其次，充值服务模块集成多支付渠道，支持一次性充值与分批充值，并通过统一的支付网关完成交易状态同步；第三，消费服务模块实现门票、项目或商品的扫码消费功能，实时扣减余额并生成消费记录；第四，余额查询与交易明细接口允许游客在移动端或自助终端随时获取当前余额与历史交易；第五，优惠券与积分管理模块支持优惠券的发放、使用与积分累积，以提升用户黏性；第六，后台监控与告警服务为运营人员提供实时客流、收入与库存数据，并在异常情况下触发告警；最后，安全与权限控制模块通过JWT鉴权、TLS加密及细粒度ACL实现对不同角色的访问限制，并记录完整的审计日志。上述功能将通过SpringBoot微服务架构实现，保证高可用、易扩展与低耦合。

七、可行性分析

经济可行性  
本系统采用开源技术栈，主要依托SpringBoot、Spring Cloud、Redis、Kafka等成熟框架，能够显著降低软件研发与运维成本；相较于传统单体应用，微服务拆分后每个模块的开发周期更短，团队协作更高效，从而缩短项目交付时间。系统上线后，可通过一次性充值与消费的自动化流程减少人工操作错误率，降低人力成本；同时，多渠道支付集成将吸引更多游客使用电子钱包，提升客单价与收入。预计在系统投入使用后一年内即可实现盈亏平衡，长期来看随着游乐场客流量的增长，系统将带来可观的经济收益。整体而言，项目的资本回报周期短、成本可控、收益前景乐观，具备良好的经济可行性。

社会可行性  
从用户体验角度看，该系统提供二维码扫码快速消费与实时余额查询功能，显著提升游客便利性与满意度；同时支持多语言界面与无障碍设计，满足不同人群的使用需求。对园区运营者而言，系统提供实时客流与收入监控，可帮助其优化资源配置、制定精准营销策略，从而提升整体服务质量。社会层面上，系统通过采用JWT鉴权与TLS加密等安全措施，保障个人信息与交易数据的隐私安全，符合国家网络安全法规；此外，系统的可持续运营将推动游乐场向数字化、智能化转型，为地方经济发展注入新活力。综上所述，该项目在社会层面具备广泛接受度与正面影响，社会可行性良好。

技术可行性  
技术层面，本项目基于Java生态的SpringBoot框架，能够与现有的企业级数据库（如MySQL、PostgreSQL）及缓存系统（Redis）无缝集成；微服务架构通过Spring Cloud Gateway实现统一路由与限流，满足高并发访问需求。分布式事务采用Saga模式与Kafka消息总线实现补偿机制，能够在不牺牲性能的前提下保证数据一致性。系统监控与日志分析采用Prometheus、Grafana及ELK栈，支持实时可视化与故障排查，进一步提升运维效率。硬件层面，容器化部署在Kubernetes集群上实现弹性伸缩，可根据业务峰谷自动调节资源；网络层面通过TLS加密与细粒度权限控制保障通信安全。基于上述技术方案的成熟度与可扩展性，本项目具备高度技术可行性。

八、功能分析

系统功能模块可划分为八大核心层面，分别为用户管理、账户充值、消费服务、余额查询与交易明细、优惠券与积分管理、门票及库存管理、支付网关集成以及监控与安全治理。用户管理模块负责游客注册与登录，支持多因素身份验证并维护个人信息档案；该模块通过JWT令牌实现无状态鉴权，并在后台提供角色与权限配置接口。账户充值模块提供一次性与分批充值功能，支持银行卡、移动支付及二维码扫码等多种支付渠道，并通过统一的支付网关服务完成交易状态回调与补偿事务。消费服务模块实现门票、项目或商品的扫码消费流程，实时扣减余额并生成消费记录，同时支持优惠券抵扣与积分兑换。余额查询与交易明细模块为游客提供实时余额查看、历史交易列表及导出功能，并支持分页查询与过滤条件。优惠券与积分管理模块负责优惠券的发行、使用规则制定以及积分累积与兑换，系统将优惠券信息缓存至Redis以提升查询效率。门票及库存管理模块维护门票种类、库存数量与价格策略，支持动态调价与限时促销，并通过消息队列实现库存变更的异步同步。支付网关集成模块聚合各支付渠道的SDK与API，提供统一的支付接口，并对异常交易进行统一回滚与补偿。监控与安全治理模块通过Prometheus采集服务指标、Grafana展示实时仪表盘，并结合ELK堆栈实现日志集中管理；安全子模块采用TLS加密传输、JWT鉴权、细粒度ACL权限控制以及审计日志记录，确保系统在高并发环境下的安全与合规。上述模块通过SpringBoot微服务架构实现，使用Spring Cloud配置中心统一管理配置，采用Docker容器化部署，并通过Kubernetes实现弹性伸缩与自愈能力。

九、数据库设计

USERS  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
user_id | 用户编号 | 36 | CHAR(36) | PK | 唯一标识  
username | 用户名 | 50 | VARCHAR(50) || 唯一索引  
password_hash | 密码哈希值 | 64 | CHAR(64) || 安全存储密码信息  
phone_number | 手机号码 | 15 | VARCHAR(15) || 联系方式  
email | 邮箱地址 | 100 | VARCHAR(100) || 通知与登录备用渠道  
created_at | 创建时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP || 记录创建时刻  
updated_at | 更新时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP || 自动更新  

ACCOUNTS  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
account_id | 账户编号 | 36 | CHAR(36) | PK | 唯一标识  
user_id | 所属用户编号 | 36 | CHAR(36) | FK → USERS.user_id || 与用户一对一关联  
balance | 当前余额 | – | DECIMAL(12,2) || 金额精确到分  
currency | 货币类型 | 3 | CHAR(3) || 如CNY、USD等  
updated_at | 更新时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP || 自动更新  

RECHARGE_TRANSACTIONS  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
recharge_id | 充值交易编号 | 36 | CHAR(36) | PK | 唯一标识  
account_id | 账户编号 | 36 | CHAR(36) | FK → ACCOUNTS.account_id || 与账户关联  
amount | 充值金额 | – | DECIMAL(12,2) || 金额精确到分  
payment_method | 支付方式 | 20 | VARCHAR(20) || 如Alipay、WeChat、CreditCard等  
transaction_status | 交易状态 | 20 | VARCHAR(20) || 如SUCCESS、FAILED、PENDING等  
transaction_time | 交易时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP || 记录交易发生时刻  
external_transaction_id | 外部支付系统交易号 | 64 | VARCHAR(64) || 用于对账  

CONSUMPTION_TRANSACTIONS  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
consumption_id | 消费交易编号 | 36 | CHAR(36) | PK | 唯一标识  
account_id | 账户编号 | 36 | CHAR(36) | FK → ACCOUNTS.account_id || 与账户关联  
ticket_type_id | 项目/门票编号 | 36 | CHAR(36) | FK → TICKET_TYPES.ticket_type_id || 消费项目类型  
amount | 消费金额 | – | DECIMAL(12,2) || 金额精确到分  
consumption_time | 消费时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP || 记录消费发生时刻  
payment_method | 支付方式 | 20 | VARCHAR(20) || 如Alipay、WeChat、Cash等  

COUPONS  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
coupon_id | 优惠券编号 | 36 | CHAR(36) | PK | 唯一标识  
code | 优惠券码 | 20 | VARCHAR(20) || 可直接扫码使用  
discount_amount | 折扣金额（若为固定金额） | – | DECIMAL(12,2) || 可为空，取决于优惠类型  
discount_rate | 折扣比例（若为百分比） | – | DECIMAL(5,2) || 如0.20代表20%折扣  
start_date | 开始生效日期 | – | DATE || 促销开始时间  
end_date | 结束失效日期 | – | DATE || 促销结束时间  
usage_limit_per_user | 单用户使用上限 | – | INT DEFAULT 1 || 防止滥用  
total_issuance | 总发行量 | – | INT DEFAULT NULL || 可为空，表示无限制  

COUPON_USAGES  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
usage_id | 使用记录编号 | 36 | CHAR(36) | PK | 唯一标识  
coupon_id | 优惠券编号 | 36 | CHAR(36) | FK → COUPONS.coupon_id || 与优惠券关联  
user_id | 使用者编号 | 36 | CHAR(36) | FK → USERS.user_id || 与用户关联  
consumption_id | 对应消费交易编号 | 36 | CHAR(36) | FK → CONSUMPTION_TRANSACTIONS.consumption_id || 记录使用场景  
used_at | 使用时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP || 记录使用时刻  

POINTS_RECORDS  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
points_record_id | 积分记录编号 | 36 | CHAR(36) | PK | 唯一标识  
user_id | 用户编号 | 36 | CHAR(36) | FK → USERS.user_id || 与用户关联  
points_change | 积分变动数值（正负） | – | INT || 记录积分增减  
reason | 变动原因说明 | 100 | VARCHAR(100) || 如RECHARGE、CONSUMPTION、REFUND等  
related_transaction_id | 关联交易编号（可为空） | 36 | CHAR(36) || 与充值或消费交易关联  
created_at | 创建时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP || 记录生成时刻  

TICKET_TYPES  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
ticket_type_id | 项目/门票编号 | 36 | CHAR(36) | PK | 唯一标识  
name | 名称 | 50 | VARCHAR(50) || 如“过山车门票”  
price | 单价 | – | DECIMAL(12,2) || 金额精确到分  
description | 描述信息 | 200 | VARCHAR(200) || 项目简介  

INVENTORY_STOCK  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
inventory_id | 库存编号 | 36 | CHAR(36) | PK | 唯一标识  
ticket_type_id | 项目/门票编号 | 36 | CHAR(36) | FK → TICKET_TYPES.ticket_type_id || 与项目关联  
quantity_available | 可售数量 | – | INT DEFAULT 0 || 当前可用库存  
updated_at | 更新时间 | – | TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP || 自动更新  

PAYMENT_GATEWAY_CONFIG  
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注  
gateway_id | 支付网关编号 | 36 | CHAR(36) | PK | 唯一标识  
name | 名称 | 50 | VARCHAR(50) || 如“Alipay”、“WeChat”  
api_key | API密钥 | 64 | VARCHAR(64) || 用于调用支付接口  
secret_key | 秘钥 | 64 | VARCHAR(64) || 用于签名验证  
endpoint_url | 接口地址 | 200 | VARCHAR(200) || 支付网关统一入口  

上述表结构遵循第一范式至第三范式，避免冗余与更新异常，满足系统在用户管理、账户充值、消费交易、优惠券与积分、门票库存以及支付配置等业务场景下的数据完整性与一致性需求。

十、建表语句

CREATE DATABASE IF NOT EXISTS playground_card CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE playground_card;

— 用户表
CREATE TABLE USERS (
  user_id CHAR(36) NOT NULL,
  username VARCHAR(50) NOT NULL,
  password_hash CHAR(64) NOT NULL,
  phone_number VARCHAR(15),
  email VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (user_id),
  UNIQUE KEY uk_username (username),
  UNIQUE KEY uk_phone_number (phone_number),
  UNIQUE KEY uk_email (email)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 账户表
CREATE TABLE ACCOUNTS (
  account_id CHAR(36) NOT NULL,
  user_id CHAR(36) NOT NULL,
  balance DECIMAL(12,2) NOT NULL DEFAULT 0.00,
  currency CHAR(3) NOT NULL DEFAULT 'CNY',
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (account_id),
  UNIQUE KEY uk_user_id (user_id),
  CONSTRAINT fk_accounts_user FOREIGN KEY (user_id) REFERENCES USERS(user_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 充值交易表
CREATE TABLE RECHARGE_TRANSACTIONS (
  recharge_id CHAR(36) NOT NULL,
  account_id CHAR(36) NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  payment_method VARCHAR(20) NOT NULL,
  transaction_status VARCHAR(20) NOT NULL DEFAULT 'PENDING',
  transaction_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  external_transaction_id VARCHAR(64),
  PRIMARY KEY (recharge_id),
  INDEX idx_account_id (account_id),
  CONSTRAINT fk_recharge_account FOREIGN KEY (account_id) REFERENCES ACCOUNTS(account_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 消费交易表
CREATE TABLE CONSUMPTION_TRANSACTIONS (
  consumption_id CHAR(36) NOT NULL,
  account_id CHAR(36) NOT NULL,
  ticket_type_id CHAR(36) NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  consumption_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  payment_method VARCHAR(20) NOT NULL,
  PRIMARY KEY (consumption_id),
  INDEX idx_account_id_ct (account_id,ticket_type_id),
  CONSTRAINT fk_consumption_account FOREIGN KEY (account_id) REFERENCES ACCOUNTS(account_id) ON DELETE CASCADE,
  CONSTRAINT fk_consumption_ticket FOREIGN KEY (ticket_type_id) REFERENCES TICKET_TYPES(ticket_type_id) ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 优惠券表
CREATE TABLE COUPONS (
  coupon_id CHAR(36) NOT NULL,
  code VARCHAR(20) NOT NULL,
  discount_amount DECIMAL(12,2),
  discount_rate DECIMAL(5,2),
  start_date DATE NOT NULL,
  end_date DATE NOT NULL,
  usage_limit_per_user INT NOT NULL DEFAULT 1,
  total_issuance INT,
  PRIMARY KEY (coupon_id),
  UNIQUE KEY uk_code (code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 优惠券使用记录表
CREATE TABLE COUPON_USAGES (
  usage_id CHAR(36) NOT NULL,
  coupon_id CHAR(36) NOT NULL,
  user_id CHAR(36) NOT NULL,
  consumption_id CHAR(36),
  used_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (usage_id),
  INDEX idx_coupon_user (coupon_id,user_id),
  CONSTRAINT fk_usage_coupon FOREIGN KEY (coupon_id) REFERENCES COUPONS(coupon_id) ON DELETE CASCADE,
  CONSTRAINT fk_usage_user FOREIGN KEY (user_id) REFERENCES USERS(user_id) ON DELETE CASCADE,
  CONSTRAINT fk_usage_consumption FOREIGN KEY (consumption_id) REFERENCES CONSUMPTION_TRANSACTIONS(consumption_id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 积分记录表
CREATE TABLE POINTS_RECORDS (
  points_record_id CHAR(36) NOT NULL,
  user_id CHAR(36) NOT NULL,
  points_change INT NOT NULL,
  reason VARCHAR(100) NOT NULL,
  related_transaction_id CHAR(36),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (points_record_id),
  INDEX idx_user_id (user_id),
  CONSTRAINT fk_points_user FOREIGN KEY (user_id) REFERENCES USERS(user_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 门票/项目类型表
CREATE TABLE TICKET_TYPES (
  ticket_type_id CHAR(36) NOT NULL,
  name VARCHAR(50) NOT NULL,
  price DECIMAL(12,2) NOT NULL,
  description VARCHAR(200),
  PRIMARY KEY (ticket_type_id),
  UNIQUE KEY uk_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 库存表
CREATE TABLE INVENTORY_STOCK (
  inventory_id CHAR(36) NOT NULL,
  ticket_type_id CHAR(36) NOT NULL,
  quantity_available INT NOT NULL DEFAULT 0,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (inventory_id),
  UNIQUE KEY uk_ticket_type (ticket_type_id),
  CONSTRAINT fk_inventory_ticket FOREIGN KEY (ticket_type_id) REFERENCES TICKET_TYPES(ticket_type_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 支付网关配置表
CREATE TABLE PAYMENT_GATEWAY_CONFIG (
  gateway_id CHAR(36) NOT NULL,
  name VARCHAR(50) NOT NULL,
  api_key VARCHAR(64) NOT NULL,
  secret_key VARCHAR(64) NOT NULL,
  endpoint_url VARCHAR(200) NOT NULL,
  PRIMARY KEY (gateway_id),
  UNIQUE KEY uk_gateway_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻