开源在线教育系统的架构设计与性能优化实践

最近开源了一个轻量级在线教育系统的核心模块,GitHub上收到不少Issue反馈性能问题。这篇分享架构设计思路和优化过程,希望能给同类项目参考。

项目背景

系统定位是中小机构的轻量化方案,非企业级重平台。核心约束:

部署成本低(单机或2-3台服务器可跑)

支持直播+录播+简单教务

多端覆盖但不做过度优化

技术栈选择:Laravel(业务层)+ Vue3(前端)+ WebRTC(直播)+ MySQL + Redis。

一、数据库设计的取舍

教务系统的数据库设计容易过度复杂。我们坚持反范式优先,用空间换时间:

sql

-- 课程表冗余存储教师姓名,避免JOINCREATE TABLE courses (

id BIGINT PRIMARY KEY,

teacher_id BIGINT,

teacher_name VARCHAR(64), -- 冗余字段

title VARCHAR(128),

...);

-- 排课表用JSON存储不规则时间(支持单双周、跳周)CREATE TABLE schedules (

id BIGINT PRIMARY KEY,

course_id BIGINT,

time_rules JSON, -- {day:1, start:"19:00", end:"20:30"}, ...

timezone VARCHAR(32),

...);

争议点:JSON字段在MySQL 5.7性能一般,升级到8.0后用JSON索引解决查询问题。排课冲突检测在应用层做,而非数据库约束,灵活性更高。

二、直播模块的简化实现

没有自研SFU,基于开源方案二次开发:

信令服务:用Socket.io实现房间管理,Redis存储房间状态

媒体转发:Mediasoup(Node.js版本),单核支撑50路视频转发

录制:GStreamer管道,WebM格式直接存对象存储

关键优化:学生端上行视频默认关闭,教师端强制开启。大班课(>20人)自动切换为"教师主讲+文字互动"模式,降低Mediasoup转发压力。

三、缓存策略的分层设计

php

// 课时余额查询,三级缓存public function getBalance(KaTeX parse error: Expected '}', got 'EOF' at end of input: ...u缓存,1秒 if (cache = apcu_fetch("balance:$studentId")) {

return $cache;

}

复制代码
// L2: Redis缓存,5分钟
if ($cache = Redis::get("balance:$studentId")) {
    apcu_store("balance:$studentId", $cache, 1);
    return $cache;
}

// L3: 数据库查询
$balance = DB::table('student_balances')
    ->where('student_id', $studentId)
    ->value('balance');

Redis::setex("balance:$studentId", 300, $balance);
apcu_store("balance:$studentId", $balance, 1);
return $balance;}

坑点:APCu在FPM多进程环境下共享问题,改用文件锁做本地缓存同步,性能损失可接受。

四、多时区处理的工程实践

开源社区问最多的问题:如何支持多时区?

方案选择存储统一UTC,展示本地化:

php

// 模型自动转换class Schedule extends Model {

protected $dates = 'start_time', 'end_time';

复制代码
public function getStartTimeAttribute($value) {
    return Carbon::parse($value, 'UTC')
        ->setTimezone($this->timezone);
}

public function setStartTimeAttribute($value) {
    $this->attributes['start_time'] = Carbon::parse($value, $this->timezone)
        ->setTimezone('UTC');
}}

教师创建课程时选择本地时区,存储自动转UTC。查询时根据用户时区转换。夏令时处理依赖Carbon的IANA时区库,无需手动维护。

五、性能瓶颈的真实案例

案例1:排课冲突检测慢

早期实现:查询所有冲突时间段,PHP循环判断。教师课表量大时,3秒+响应。

优化后:用MySQL空间索引(SPATIAL INDEX)存储时间段,SQL直接判断交集:

sql

-- 时间段用LINESTRING表示(开始时间, 结束时间)SELECT * FROM schedules

WHERE MBRIntersects(

time_range,

LineString(Point(UNIX_TIMESTAMP('2024-01-01 19:00'), 0), Point(UNIX_TIMESTAMP('2024-01-01 20:30'), 0)));

案例2:直播房间列表卡顿

首页展示"正在进行"的直播房间,早期用WHERE + ORDER,数据量上万后慢查询。

优化:用物化视图(Materialized View)或定时任务刷缓存表,而非实时计算。允许1分钟延迟,换取查询性能。

六、开源维护的经验

Issue模板:强制要求提供环境信息(PHP版本、MySQL版本、是否Docker部署),减少无效沟通

性能基准:提供压测脚本(Artisan命令),用户可自行验证性能

文档优先:复杂功能(如直播配置、支付回调)必须配流程图,文字描述歧义太多

关于商业与开源的平衡

核心教务功能完全开源,但直播转码、跨境支付等模块用插件形式闭源。既保证社区能用起来,又能持续维护项目。

开源地址:

https://github.com/xueye-admin/xueye

相关推荐
Are_You_Okkk_29 分钟前
基于MonkeyCode解析AI研发新模式,根治开发低效痛点
大数据·人工智能·开源·ai编程
冬奇Lab4 小时前
每日一个开源项目(第116篇):FreeDomain - 让每个人都拥有属于自己的数字身份
开源
lauo5 小时前
从FunloomAI到ibbot:当你的手机不再是“手机”,而是你的AI副脑和生产节点
人工智能·智能手机·架构·开源·github
JacksonMx6 小时前
@Transactional 最佳实践
java·spring boot·spring·性能优化
小程故事多_807 小时前
拆解Hermes Agent技术架构,会自我迭代的开源智能体如何突破AI传统局限
人工智能·架构·开源
Hommy887 小时前
【剪映小助手】贴纸处理接口
网络·开源·github·aigc·剪映小助手·视频剪辑自动化
敲星写码9 小时前
2026远程控制软件选购指南:按人群场景预算一站式锁定,ToDesk覆盖90%用户需求
开源
QiLinkOS9 小时前
从技术到资产的跃迁:企业专利布局的深层逻辑
c语言·数据结构·c++·单片机·嵌入式硬件·算法·开源
小丶舟9 小时前
6GB显卡跑Hermes Agent!开源AI自学习编程Agent实测
人工智能·学习·开源
wasp5209 小时前
# 推荐透明桌面 Widget 生产力工具 —— 待办、便签、AI常驻桌面:忙蜂了(BitzBee Todos)
人工智能·开源·gtd