我和狐狸探讨过一个问题：为何资源入库量越大速度越慢，且用户数量越多就需要部署更多容器？归根结底，是SQLite不适合高并发场景。
SQLite的单文件锁机制是核心瓶颈——高并发读写时会频繁触发锁等待，直接表现为CPU占用率飙升，入库与查询的响应速度显著变慢。
我们以“小雅”做过测试：50万条资源数据、10人同时加载的场景下，容器CPU占用率达30%，内存占用高达12GB。为此，小姨子采取了资源数量管控策略：每次新增热门资源时，同步清理无人访问的冷门资源，将总资源量控制在8万条以内；同时开放求片通道，且不限制用户的求片次数。
“资源总量控制在8万条内+按需求片” 是一套十分务实的折中方案：既规避了SQLite的高并发短板，又能通过按需添加热门资源满足用户需求，还能有效降低存储与容器的资源占用压力。
SQLite的单文件锁机制是核心瓶颈——高并发读写时会频繁触发锁等待，直接表现为CPU占用率飙升，入库与查询的响应速度显著变慢。
我们以“小雅”做过测试：50万条资源数据、10人同时加载的场景下，容器CPU占用率达30%，内存占用高达12GB。为此，小姨子采取了资源数量管控策略：每次新增热门资源时，同步清理无人访问的冷门资源，将总资源量控制在8万条以内；同时开放求片通道，且不限制用户的求片次数。
“资源总量控制在8万条内+按需求片” 是一套十分务实的折中方案：既规避了SQLite的高并发短板，又能通过按需添加热门资源满足用户需求，还能有效降低存储与容器的资源占用压力。
❤13
1月20号晚上十二点后迁移服务器，线下物理机，以后就是oss+硬盘混合，逐渐替换成全硬盘服
服务器配置：
u，2680v3*2 [核心/线程: 24核心，48线程
基础频率: 2.5 GHz*2
最大睿频: 3.0 GHz*2
缓存: 30 MB L3缓存*2]
ram 16*4=64g
hhd 4*12=48t
服务器配置：
u，2680v3*2 [核心/线程: 24核心，48线程
基础频率: 2.5 GHz*2
最大睿频: 3.0 GHz*2
缓存: 30 MB L3缓存*2]
ram 16*4=64g
hhd 4*12=48t
❤19👍2
字幕问题解决了，每天凌晨三点自动补全，然后到ai自动生成。
追新问题解决了，自动爬取115，cloud189，123网盘，获取最新集数，下载到本地上，一个月后上传到oss。
网络问题解决了，20号带宽下来了，公费带宽1500mbps，公益带宽900mbps。
起播问题解决了，因为本地有硬盘48t，足够缓存了
追新问题解决了，自动爬取115，cloud189，123网盘，获取最新集数，下载到本地上，一个月后上传到oss。
网络问题解决了，20号带宽下来了，公费带宽1500mbps，公益带宽900mbps。
起播问题解决了，因为本地有硬盘48t，足够缓存了
👍11❤5👏1