简介eyoo旅游机票电商平台重构版是一份基于Ruby技术栈的在线机票销售系统学习资源适合希望掌握Ruby on Rails电商项目完整开发流程的开发者用于研究业务建模、数据库关联、接口设计与部署方案。压缩包大小约2.62MB当前标注文件总数为0份具体文件明细暂无数据可能为项目源码或文档归档。已有122人浏览学习。内容围绕平台重构所涉及的关键技术展开涵盖Rails的MVC架构、ActiveRecord对象关系映射、RESTful API设计、第三方支付集成、常见安全防护、前端交互优化以及自动化测试与CI/CD部署等知识点并结合用户、航班、订单等典型业务场景帮助读者理解从后端逻辑到上线发布的完整链路。这份资料适合作为Ruby Web开发实战的参考资料尤其对学习电商平台重构思路、模块解耦和性能优化有直接帮助。1. eyoo旅游机票电商平台Ruby重构版到底解决了什么这两年做旅游电商系统最头疼的不是功能做不出来而是业务量一上来老系统就开始闹脾气。一个用PHP堆了五年的机票预订平台查询接口平均响应800毫秒遇到节假日促销直接卡死订单状态还会偶尔错乱。eyoo这个旅游机票电商平台重构版就是用Ruby生态重新撸了一版核心交易链路把机票搜索、订单锁定、支付回调、航变通知这些关键模块彻底重写顺手还把库存并发问题给治了。这套资源不是给你看代码的是给你抄作业的——里面带完整可跑的Rails工程、数据库表结构、支付状态机定义以及重构过程中的踩坑记录。适合同样被老系统拖累的团队参考也适合想用Ruby做电商交易的开发者拿来当骨架。2. 重构技术底座为什么选Ruby生态与Rails的分层架构2.1 Ruby与Rails选型的真实理由老团队提重构方案时摆在桌面上的选项有Java、Go、Ruby。最后选了Ruby不是因为情怀而是这个重灾区业务太适合Rails的约定优于配置。机票搜索、订单、支付、会员这几个域本质上都是标准的CRUD加状态流转Rails的ActiveRecord能直接省掉一半的Mapper代码。而且这个项目的人均Ruby经验虽然只有一年但Rails脚手架一拉团队上手速度明显比Spring Boot快。Ruby 3.2版本在性能上比2.7时代好了不少尤其是JIT编译器的引入让CPU密集的报价计算任务不再那么吃力。eyoo重构版用的版本组合是Ruby 3.2.2加Rails 7.0搭配Puma作为Web服务器。数据库选了MySQL 8.0缓存用Redis 7。这个组合不算激进但胜在稳定社区里踩坑资料多出问题能搜到解决方案。2.2 目录结构与模块边界的划分逻辑重构版的核心是模块边界这个比技术栈选择更关键。老系统把所有业务逻辑塞进一个巨型Model里订单模型有两千行代码改一个航变通知功能能影响五个模块。新架构按业务域拆成了四个引擎eyoo/ ├── app/ │ ├── models/ │ │ ├── flight/ # 航班查询、舱位、运价 │ │ ├── order/ # 订单、乘客、退改签 │ │ ├── payment/ # 支付单、回调记录、对账 │ │ └── member/ # 会员、里程、优惠券 │ ├── services/ # 业务服务层 │ │ ├── flight_search.rb # 航班搜索编排 │ │ ├── order_flow.rb # 下单流程编排 │ │ └── payment_processor.rb # 支付状态机驱动 │ └── jobs/ # 异步任务 │ ├── flight_notice_job.rb # 航变通知 │ └── order_timeout_job.rb # 订单超时取消每个业务引擎内部自治对外只暴露Service接口。比如下单流程Controller只调OrderFlow.create(params)内部再把乘客校验、库存锁定、价格快照、优惠券核销这四步串起来。这样改航班逻辑不会碰订单逻辑团队并行开发不打架。参数方面Service层接收的是一个简单的Hash参数而不是直接塞Model实例。这么做的好处是接口边界清晰——外部调用方不需要知道订单模型内部有哪些字段只要传{ flight_id: 123, passengers: [{name: 张三, id_card: ...}] }就行。Rails 7的params校验用ActiveModel::Validations做白名单验证非法参数直接抛异常不落库。2.3 数据库设计与事务边界重构时把原来的大宽表拆成了第三范式的核心表加冗余快照表。订单表只存业务主键和状态价格、航段信息、乘机人信息全部放到子表。这里有个取舍——纯第三范式查询要联表所以特意加了price_snapshot_json字段下单瞬间把整个价格明细序列化存一份。这样后续对账、退款、争议处理都不用查当时的价格配置表直接读快照。事务边界的定义也是重构的重头戏。机票下单涉及库存扣减、订单创建、优惠券锁定三个写操作这三个必须在一个事务里。但支付回调确认那种操作就不能包长事务因为支付网关响应慢锁行时间长了会拖垮整个库。所以事务粒度分成两类强一致的短事务比如下单最终一致的长流程比如支付后异步更新订单状态。边界清楚了死锁和锁等待的问题少了一大半。# 下单事务库存扣减与订单创建在同一事务 def create_order(order_params) ActiveRecord::Base.transaction do # 锁定航班库存行防止并发超卖 inventory FlightInventory.lock.find_by!( flight_id: order_params[:flight_id], cabin_class: order_params[:cabin_class] ) raise OrderError, 舱位已售罄 if inventory.remaining 1 inventory.remaining - 1 inventory.save! order Order.create!(order_params) Coupon.lock.find_by!(id: order_params[:coupon_id]).mark_used! order end rescue ActiveRecord::RecordNotFound e raise OrderError, 库存或优惠券不存在: #{e.message} end这段代码有个关键点FlightInventory.lock会对库存行加排他锁直到事务结束才释放。两个并发请求同时下单时第二个请求会在这个地方阻塞等待而不是直接读到脏数据。remaining字段每次减一配合锁机制就能在数据库层面挡住超卖。save!和create!带感叹号的方法会抛异常事务回滚时库存扣减和优惠券变更也会一起回滚。这就是短事务的价值——每个操作都小锁持有时间只有几毫秒。3. 核心业务模块落地机票搜索、订单锁定与支付状态机怎么写3.1 机票搜索多条件组合查询与缓存策略机票搜索是重构版里最容易被低估的模块。表面看就是按日期和航线查航班实际上用户的筛选条件组合非常多——时间段、航司、舱位、直飞还是中转、价格区间。老系统每次请求都实时查数据库导致一有促销活动数据库连接池直接打满。新版的思路是分层缓存加索引优化。class FlightSearch CACHE_KEY_PREFIX eyoo:flight_search:v1 CACHE_TTL 5.minutes def self.search(params) cache_key build_cache_key(params) result RedisClient.get(cache_key) return JSON.parse(result) if result flights Flight.query_by_condition(params) result serialize(flights) RedisClient.setex(cache_key, CACHE_TTL, result.to_json) result end def self.build_cache_key(params) # 归并条件相同条件的查请求可命中同一缓存 #{CACHE_KEY_PREFIX}:#{params[:departure]}_#{params[:arrival]}_#{params[:date]}_#{params[:cabin]} end end这个缓存策略有几个细节要注意。缓存key里没有放价格因为价格变动频率高而航班时刻和舱位余量是一个相对静态的数据集——航司排班表一般提前三个月固定。余量数据是动态的但5分钟的过期时间对用户来说感知不强却能显著降低数据库压力。build_cache_key把所有筛选条件做了一次归一化比如时间段上午06:00-12:00那用户选07:00和选08:00查出来的结果其实是一回事归并后就能共享缓存。实际压测下来加了这层缓存后搜索接口的TP99从800毫秒降到120毫秒。这里有个排查点值得说线上如果发现缓存命中率低大概率是筛选条件组合太散需要在build_cache_key里做条件归并而不是急着加缓存容量。3.2 订单锁定与超时取消延迟队列的经典用法机票订单有个特殊业务约束——支付超时自动取消。老系统的做法是每分钟跑一个定时任务扫所有未支付订单半小时前的订单就置为取消。数据量小的时候没问题单量大了以后每次扫描要把好几万行订单拉出来判断数据库扛不住。新版改成了延迟队列方案用Redis的ZSET实现。class OrderTimeoutJob ApplicationJob QUEUE_KEY eyoo:order_timeout def perform now Time.current.to_i timeout_orders RedisClient.zrangebyscore(QUEUE_KEY, 0, now, limit: [0, 100]) timeout_orders.each do |order_id| order Order.lock.find_by(id: order_id) next unless order.pending? order.update!(status: :cancelled) # 释放库存 FlightInventory.increment_counter(:remaining, order.flight_inventory_id) RedisClient.zrem(QUEUE_KEY, order_id) end end def self.enqueue(order_id, expire_at) RedisClient.zadd(QUEUE_KEY, expire_at.to_i, order_id) end end下单成功时OrderTimeoutJob.enqueue(order.id, Time.current 30.minutes)把订单ID和期望过期时间戳写进ZSET。侧载进程每一分钟执行一次perform只取当前时间之前到期的订单ID。面试官视角这个方案的精髓在于ZSET按分数排序的特性天然支持按时间范围取数取出来一个处理一个不需要全表扫描。zrangebyscore加了limit: [0, 100]是为了控制每批处理数量防止某次积压订单太多导致进程卡死。还有一个容易忽略的点order.lock在更新前锁行防止并发场景下支付成功的请求和超时取消的请求同时操作同一个订单。没有这把锁可能订单已经支付成功超时任务又把它置为已取消库存也重复释放。3.3 支付回调与状态机幂等是最难的一环支付模块重构的最大改动是引入显式状态机替代原来的if...else散装判断。订单状态从下单到出票一共七个状态pending(待支付)、paid(已支付)、confirmed(已确认)、issued(已出票)、cancelled(已取消)、refunding(退款中)、refunded(已退款)。class Order ApplicationRecord state_machine :status, initial: :pending do event :pay do transition pending: :paid end event :confirm do transition paid: :confirmed end event :issue do transition confirmed: :issued end event :cancel do transition pending: :cancelled transition paid: :refunding end event :refund do transition refunding: :refunded end after_transition on: :pay do |order, transition| PaymentProcessor.after_paid(order) end end end状态机让非法状态流转在入口就被拦截。比如一笔已取消的订单再次收到支付成功的回调状态机直接拒绝pay事件不会像老代码那样把标为取消的订单改成已支付。after_transition钩子里可以挂后续动作比如支付成功后触发出票任务。支付回调的幂等处理是另一个重头戏。支付宝和微信的回调通知没有严格的幂等保证同一个支付结果可能推两次。如果不做处理用户付一次钱系统给发两张机票。class PaymentProcessor def self.process_callback(payment_id, status, raw_body) payment Payment.find_by(id: payment_id) return if payment.nil? # 关键回调记录表做唯一约束天然幂等 callback_log PaymentCallbackLog.create_with( status: status, raw_body: raw_body, processed: false ).find_or_create_by!(payment_id: payment.id, callback_id: raw_body[notify_id]) return if callback_log.processed? ActiveRecord::Base.transaction do payment.update!(status: status) order payment.order order.pay! if status success order.pending? callback_log.update!(processed: true) end end end幂等逻辑的核心是PaymentCallbackLog这张表给payment_id notify_id建了唯一索引。第一次回调进来find_or_create_by!能正常插入记录第二次进来同一个notify_id数据库唯一索引直接拒绝插入create_with返回已有的记录逻辑直接短路。这个方案比在代码里用redis.setnx加锁更稳因为数据库唯一索引是硬约束不存在分布式环境下锁失效的问题。payment.update!(status: status)这行看起来简单实际是防重复出票的关键。如果状态已经是success再次进入事务时callback_log.processed?会返回true后面的操作全部跳过。配合状态机的pending?判断即使回调乱序到达也不会把已确认的订单打回待支付。3.4 航变通知异步任务与消息重试的取舍航变通知是机票平台里最苦的活。航空公司改了航班时刻系统要在最短时间内通知所有受影响乘客。重构版用的是Rails自带的ActiveJob加Sidekiq。每个受影响订单创建一个通知任务任务里先更新订单的航班时刻快照再往消息队列推一个推送任务。class FlightNoticeJob ApplicationJob queue_as :urgent def perform(order_id, flight_change_info) order Order.find_by(id: order_id) return if order.nil? order.update!(flight_snapshot: flight_change_info) notification_payload { order_id: order.id, member_id: order.member_id, title: 航班时刻变更提醒, content: #{flight_change_info[:flight_no]}调整至#{flight_change_info[:new_departure_time]}起飞 } PushNotificationJob.perform_later(notification_payload) rescue StandardError e retry_job wait: 5.minutes, queue: :default if executions 3 end end这个任务的容错逻辑有一条业务红线通知失败了要重试但不能无限重试。executions 3限制重试次数三次都失败就放弃转入人工处理队列。另外PushNotificationJob和FlightNoticeJob分开跑是因为推送服务依赖外部厂商接口响应时间不可控串在一起会把航变处理的队列堵死。分离之后还有一个好处推送失败的日志能单独查排查问题不用翻一堆订单更新日志。航变通知的时效要求是5分钟之内触达70%用户这个设计上线后实际达成率是78%余下的靠短信补发。4. 重构必踩的五个坑时区、事务、幂等与缓存排查实录4.1 坑一时区混乱导致机票日期错位现象用户买6月15日的机票系统出票日期显示6月14日部分订单甚至提示航班已过期。客服后台一查同一笔订单在Web端和App端显示的起飞时间不一致。原因老系统MySQL的datetime字段不带时区信息写入时用的服务器本地时间东八区读出来用Rails默认的UTC解释直接少了8小时。重构版初期没做全局时区配置让历史数据和新数据混在一起日期计算全部错乱。解决重构启动的第一天就强制统一时区。在config/application.rb里设置config.time_zone Beijing和config.active_record.default_timezone :local同时把存量数据的datetime字段按UTC偏移量批量修正到东八区。任何新写入的数据都必须经过Time.current获取时间禁止调用Time.now。从那以后日期错位问题再没出现过。如果你们准备重构老系统第一天就要做这个事不然后面的对账、退款全都会错位。4.2 坑二库存扣减的乐观锁版本号失效现象压测时发现同一航班的余票数从5张瞬间变成-2张超卖严重。代码用的是inventory.remaining - 1加save!表面看同一时间只有一个请求能改这条记录。原因remaining - 1是读改写三步操作不是原子操作。在并发环境下两个请求同时读到remaining5各自减一后写回最终结果显示4但实际卖出了两张票。ActiveRecord自带的乐观锁加的是lock_version字段但如果代码里用了update_column、update_all或原生SQL就会绕过乐观锁校验版本号失效。解决所有库存操作统一走UPDATE ... SET remaining remaining - 1 WHERE remaining 0在数据库层面保证原子性。def deduct_inventory(flight_id, cabin_class) affected_rows FlightInventory.where( flight_id: flight_id, cabin_class: cabin_class ).where(remaining 0).update_all(remaining remaining - 1) raise OrderError, 舱位已售罄 if affected_rows.zero? endaffected_rows返回的是受影响的行数等于0说明没有可扣减库存。这个方案不需要锁也不存在版本号被绕过的问题因为数据库的行锁保证了update_all的原子性。重构后我们用并发压测工具模拟200个用户同时抢一张票最终库存只减了1没有超卖。4.3 坑三支付回调重复处理导致重复出票现象售后工单里出现同一订单出票两次的严重事故一张机票的钱出了两张机票。开发排查日志发现支付网关同一个notify_id回调了三次第一次成功处理第二次又被当成新回调执行了出票逻辑。原因最初接支付回调时只在代码里用find_or_create_by(payment_id: notify_id)做判断但先判断再插入的时序在并发下不成立。第一次回调还没插入记录时第二次回调就进来了两个请求同时通过判断各执行一次出票。修复方式是本章3.3节写的PaymentCallbackLog加数据库唯一索引从根上解决问题。解决第一为payment_callback_logs表的payment_id notify_id添加唯一索引第二在事务里更新processed字段时用条件更新update_all而不是普通的update!避免事务隔离级别问题导致状态覆盖。上线后压测模拟重复回调日志中只保留一条处理记录。4.4 坑四缓存雪崩让搜索接口一夜回到解放前现象某航司促销活动晚上8点开始8点01分数据库连接数直接打满慢查询日志里全是航班搜索语句。搜索接口设置了5分钟的缓存过期时间活动一开所有热门航线缓存同时失效流量全部穿透到数据库。原因缓存key的过期时间没做随机化统一使用CACHE_TTL 5.minutes同一时刻失效的key数量太多。另外热门航线的key失效后大量用户同时请求同一个key缓存击穿也加剧了数据库压力。解决过期时间改为固定值加随机偏移量同时给热点key增加互斥重建逻辑。CACHE_TTL_BASE 300 # 5分钟基础过期时间 CACHE_TTL_JITTER 30 # 30秒随机偏移 def self.fetch_flight_cache(key) value RedisClient.get(key) return value if value.present? # 加分布式锁防止缓存击穿 lock_key lock:#{key} lock RedisClient.setex(lock_key, 10, 1, nx: true) if lock begin value yield # 查数据库并构建缓存 RedisClient.setex(key, CACHE_TTL_BASE rand(CACHE_TTL_JITTER), value) value ensure RedisClient.del(lock_key) end else sleep 0.1 RedisClient.get(key) # 拿不到锁等待后读缓存 end end这个实现里Redis的setex带nx参数是加分布式锁的常见做法拿到锁的请求负责重建缓存拿不到的请求短暂等待后读取已有缓存。配合过期时间的抖动雪崩概率大幅下降。活动当晚监控看到数据库连接稳定在80%水位没有再打满。4.5 坑五Rails自动加载机制在重构中的玄学报错现象刚把模块拆完跑测试套件时随机报NameError: uninitialized constant有时改一行代码就报错再跑一次又正常。原因Rails的Zeitwerk自动加载器对文件名和常量名的映射有强制约定。重构时把FlightSearch类放在了app/services/flight_search.rb里但在某个模块里用了Search::Flight的命名大小写和下划线不规范导致加载器在开发环境下找得到类、生产环境下找不到行为像玄学。解决统一检查文件命名确保每个常量名在文件系统中的路径完全匹配。app/services/flight_search.rb对应FlightSearchapp/models/order/passenger.rb对应Order::Passenger同时给app/services目录加入config.eager_load_paths开启生产环境预加载。整理完命名规范后测试套件连续跑20次无报错。5. 上线前的性能体检从慢查询到并发压测的一次完整调优机票交易系统上线前我习惯做四步检查顺序不能乱每一步都能暴露出不一样的问题。第一步是开慢查询日志。MySQL的slow_query_log设置为1long_query_time设置为0.1秒。跑一遍全量回归测试凡是超过100毫秒的SQL全部捞出来看执行计划。上一次重构检查时捞出来40多条慢SQL其中一半是缺少联合索引导致的。机票搜索表最常用的查询条件是departure_city arrival_city departure_date三字段组合建了一个联合索引后查询从全表扫描的300毫秒降到索引扫描的8毫秒。第二步是检查N1查询。Rails日志里如果看到一条列表查询后面跟着几十条单条查询基本就是N1。订单列表页关联乘客表和支付表用Rails的includes(:passengers, :payment)加载关联数据SQL从30条降到3条。这一步收益最直观改动小、见效快。第三步是并发压测。用wrk或JMeter针对搜索、下单、支付回调三个核心接口做阶梯加压。我的习惯是先做200并发、持续3分钟的基准测试记录TP50、TP99和错误率再逐步加到500、800并发。下单接口在600并发时有锁等待超时错误率冲到5%把数据库连接池从默认的5调到20同时把下单事务里一次多余的SELECT语句挪到事务外锁持有时间缩短后800并发的错误率才压到1%以内。第四步是验证失败重试链路。模拟支付网关超时、第3次回调失败、航变通知推送超时这三种故障确认Sidekiq的重试机制和告警日志能正常工作。这三步做完才敢放量到真实流量。从那以后每次交付重构项目我都强制走一遍这四步检查最便宜的优化往往不在代码而在这些看起来不起眼的体检动作上。希望帮到你。本文还有配套的精品资源点击获取