password
AI summary
type
status
date
slug
summary
tags
category
icon
Suno2openai 遇到的一些问题:
一. Cookie 并发问题
在书写Suno2openai重构项目的时候,我和另一位作者发现了一个很头疼的问题,那就是一个账号在创作的时候,最多只能请求两次,是什么意思呢?其实就是账号在创作的时候,就无法继续接受创作请求了,如果在高并发的时候,这就需要用到
条件过滤
+ 随机cookies
+ 事务锁
- 条件过滤
紧接上回,我们知道
账号在创作的时候,就无法继续接受创作请求
, 那么我就寻思着,如果每次请求的时候给他做个标记,结束创作的时候再把它的标记删掉,那么不就可以避免同一时间访问请求到同一个 cookie
,这就是条件过滤的内容。- 随机cookies
为什么要随机cookies呢,当我们在上一个过程条件筛选之后,我们会拿到许多的cookie,但是在高并发的情况下,如果cookie太少的话,就很容易造成同一时间拿到同一个cookie的情况,于是,随机cookies的重要性就出来了!
- Mysql事务锁
为什么要加上锁呢? 根据条件过滤的原理,其实我们是清楚,我们必须要先拿到cookie,之后立马给他做上标记的,只有这样,我们的
cookie
才不会因为高并发,而拿去到相同的cookie, 并一起请求。但是其实这个并不简单,因为在高并发的情况下,一次性几百个请求过来,随机cookies也是很有可能会拿到相同的 cookie
的,如果两个一起修改,那么也是不会有效果的,也会一起请求。 所以这个时候,就要用到锁了,有两个可以选,一个
乐观锁
,一个悲观锁
,由于少修改项目源码,并且最大可能的适配另一个作者的版本,我选择了 悲观锁
(1) 先随机查询一个不被锁定的且满足条件的cookie
(2) 第二个查询,先判断是否满足要求,满足要求就锁定获取的cookie (这样可以防止等待解锁的操作,虽然Mysql 8.0 之后更新
SKIP LOCKED
用于查询跳过被锁定的行,但是显然多了这一步操作能适配更多Mysql版本)(3) 更新选中的cookie
(4) 悲观锁的重试机制,根据wait的随机事件进行重试,也降低了并发冲突
总的来说,一套流程下来,对于一般的高并发查询数据,是够用了,同时也适配了绝大多数的Mysql版本 (Azure的学生免费服务器,装Mysql 5.7以上的版本,内存还是吃的蛮多的😭)
2. 有时候在finally代码块内直接await,并没有等待执行相应的异步函数
猜测估计是finally之前的代码一直没有运行完,导致后面卡死,不执行这个任务

于是我开始尝试,首先是包装进一个异步函数里面,里面定义了`loop`, 希望能查看整个事件循环运行状态并采取不同的措施,运行初始化cookie的songID操作

尝试了很多次后,发现在服务器上面,仍然会出现没有运行完finally里的函数,并不能初始化cookie的songID,所以我尝试询问ChatGPT,GPT在我的不断地引导下,给出了下面代码。

这个代码先查看了事件循环是否运行,如果事件循环正在运行的话,这新建一个协程,来运行初始化cookie的songID的任务,如果不在运行的话,则直接运行任务
总结
通过解决上述问题,我们能够更有效地处理Suno2openai项目中的高并发请求,并保证在各种MySQL版本中保持良好的兼容性。此外,通过改进异步函数的执行方式,确保了所有必要的清理工作都能顺利完成,从而提高了系统的稳定性和可靠性。
- 作者:Clivia
- 链接:Clivia的博客/learning/questions_suno2openai
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章