在flask框架下利用Python的threading或thread多线程库如何操作数据库？

Question

萌新在写网站的发送邮件验证，为了防止用户滥发，所以加了权限。前端简单地disable按钮一刷新就没了，纯粹视觉提示作用，所以在后端models里为user加了一个resend_right，当为True时才能重新发送，False不行。

所以在models里，user模型有一个column是这样的（SQLAlchemy）：

resend_right = db.Column(db.Boolean, default=True)

当然前端是等待60秒后可以重新发送，所以后端也计时60秒后重新赋值True给resend_right。我就想这种等待性IO/数据库读取录入等操作当然是多线程处理。

所以我写了resend_right权限重置的方法：

def async_reset(app, user):
    with app.app_context():
        time.sleep(55)
        user.resend_right = True

def resend_right_reset(user):
    app = current_app._get_current_object()
    thr = Thread(target=async_reset, args=[app, user])
    thr.start()
    return thr
    

然后在views的路由函数里面调用它：

# Resend confirmation email route, need to be protected
@auth.route('/resend_email/')
@login_required
def resend_confirmation():
    mail_host ='http://mail.' + re.split('@', current_user.email)[1]
    if not current_user.resend_right:
        flash("请不要尝试刷新页面来短时间内重复发送验证邮件，你可以在一分钟后再试")
        return render_template('auth/confirm.html',user=current_user, mail_host=mail_host)
    token = current_user.generate_confirmation_token()
.........

结果无效，所以我测试了一下，发现路由函数无问题,resend_right_reset无问题。假如我把user.rend_right=True写进resend_right_reset是能够正常运作的，但一旦用多线程来处理就始终无法重置。然后我分析，多线程这里用了current_app._get_current_object()获取全局对象，然后app.app_context()拿到了上下文导入到多线程里，应该就没问题了。但为什么不行？

求教，非常感谢！

Answer 1

이 주제와 관련 없는 아이디어를 알려주세요.
인증 코드는 Redis를 사용하여 저장하고 생존 시간을 설정할 수 있습니다. 시간이 지나면 해당 값이 Redis에서 사라집니다. 제출된 값을 얻으려면 Redis로 이동하세요. 데이터베이스 캐싱은 SQL보다 빠르며 다른 사람이 매개변수를 수정하고 제출하는 것을 방지할 수 있습니다. 개인적으로 제출된 매개변수를 직접 수정할 수 있기 때문에 타임스탬프를 추가하는 것은 적절하지 않다고 생각합니다.

Answer 2

두 가지 추측이 있습니다.

1. flask의 구현 메커니즘에서 current_app을 포함한 일부 전역 객체는 모두 프록시 객체입니다. 프록시는 로컬 스택에 해당하는 스택의 최상위 요소입니다. 스레드 로컬 변수(Threading Local)입니다. 이는 각 요청에 대해 동일한 이름을 가진 개체에 대한 참조가 다르다는 것을 의미합니다.

2. async_reset에서 커밋 코드를 보지 못했기 때문에 라우팅 코드 뒤에 있는 current_user는 사용자가 원래 업데이트한 개체가 아니라 데이터베이스에서 다시 가져와야 한다고 생각합니다(참조 다릅니다). 그럼 커밋해 보세요.

사실 이 솔루션은 이메일을 보낼 때 전송 시간을 기록한 다음 라우팅에서 현재 시간부터 마지막 ​​전송 시간까지의 간격을 결정하는 것이 가장 좋습니다. 이는 데이터베이스 쓰기 및 스레드 할당에 따른 오버헤드를 방지합니다.

@TKfeng이 지적한 바에 따르면 redis 캐시 + TTL은 성능이 좋고 이후 단계의 세분화된 서비스 분할에 적합합니다.