1.故事背景
今天上午我忙完手中的事情之后突然想起来我还没签到，于是赶紧打开签到页面，刚点击了签到按钮，提示“签到成功，获得25阅读额度！”，正准备退出浏览器，忽然发现签到列表有异常，居然有用户有两条签到记录！！！
难道我的代码又出Bug了？？？不可能！！！
2.查找问题
不过保险起见，还是去检查了一下代码。
代码如下：
@app.route('/api/sign', methods=['POST'])
@is_authenticated
def api_sign():
id = current_user.id
if current_user.is_sign:
return jsonify({'status':0,'message':'今日已签到,请明天8点再来签到'})
else:
pass我在用户信息上放了一个is_sign字段表示当天该用户是否有签到，然后在每天8点的时候通过linux的定时任务更新所有用户的这个字段为False，在用户签到的时候，会首先检查这个字段，如果为False就会执行签到逻辑，然后会把这个字段更新为True，我感觉这个逻辑应该没啥问题。
一时陷入僵局
遂决定先去查查nginx的log，看看请求信息，费了九牛二虎之力，终于把日志文件下载了下来，阿里云1M小水管可太慢了，然后因为前两天分了站点来归档log，忘了做日志切割，整个日志文件有17M之巨，压缩完也下了好久。
根据此用户签到时间，找到了当时的请求记录
通过日志，可以看到连续post了三条，不知道是因为浏览器卡了还是因为这个用户有点意思，先不去纠结这些细枝末节，解决问题更重要。
3.确定问题
看到这个日志我大概明白了，应该是并发没有加锁背锅。
写点代码测试一下，python有个并发库叫grequests，就拿这个测测
import grequests
import requests
if __name__ == '__main__':
urls=[
'http://192.168.48.129/api/sign',
'http://192.168.48.129/api/sign',
'http://192.168.48.129/api/sign',
'http://192.168.48.129/api/sign',
'http://192.168.48.129/api/sign',
'http://192.168.48.129/api/sign',
]
cookies = dict(session='xxxxxxx')
rs = (grequests.post(u,cookies=cookies,data=dict(card_id=1)) for u in urls)
resp = grequests.map(rs)
for r in resp:
print(r.json())果然，前四次都签到成功了！
只成功四次是因为我是用uWSGI部署得站点，然后配置了processes = 4，只有四个进程处理请求，所以轮到后两个请求得时候，is_sign已经是True了
用户签到的逻辑如下：
- 插入一条签到记录
- 修改阅读额度表，为用户增加额度
- 插入一条额度变更记录
- 提交修改
正常来说，如果是不同用户操作的，即使并发了对业务来说不会有任何问题，因为每个人都操作的是自己的数据，不会产生错误数据。
但是，今天遇到的是单用户并发了。
emmm，只能说这个老哥有点东西。
4.解决问题
不过既然发现了问题，那就得解决掉它。
orm框架我用的是Flask-SQLAlchemy，还不知道它加锁得怎么搞，先查一下资料。
函数的定义如下：
@_generative()
def with_for_update(self, read=False, nowait=False, of=None):
"""return a new :class:`.Query` with the specified options for the
``FOR UPDATE`` clause.
The behavior of this method is identical to that of
:meth:`.SelectBase.with_for_update`. When called with no arguments,
the resulting ``SELECT`` statement will have a ``FOR UPDATE`` clause
appended. When additional arguments are specified, backend-specific
options such as ``FOR UPDATE NOWAIT`` or ``LOCK IN SHARE MODE``
can take effect.
E.g.::
q = sess.query(User).with_for_update(nowait=True, of=User)
The above query on a Postgresql backend will render like::
SELECT users.id AS users_id FROM users FOR UPDATE OF users NOWAIT
.. versionadded:: 0.9.0 :meth:`.Query.with_for_update` supersedes
the :meth:`.Query.with_lockmode` method.
.. seealso::
:meth:`.GenerativeSelect.with_for_update` - Core level method with
full argument and behavioral description.
"""
read:是标识加互斥锁还是共享锁. 当为 True 时, 即 for share 的语句, 是共享锁. 多个事务可以获取共享锁, 互斥锁只能一个事务获取. 有"多个地方"都希望是"这段时间我获取的数据不能被修改, 我也不会改", 那么只能使用共享锁.
nowait:其它事务碰到锁, 是否不等待直接"报错".
of:指明上锁的表, 如果不指明, 则查询中涉及的所有表(行)都会加锁.
这里需要对用户信息表进行修改，要更新is_sign字段，所以应该使用互斥锁。
修改后代码如下：
def api_sign():
id = current_user.id
_user_info = user_info.query.filter_by(id=id).with_for_update().first()
if _user_info.is_sign:
return jsonify({'status':0,'message':'今日已签到，请明天8点再来签到！'})
else:
pass再次执行上面的并发请求代码，现在就只有第一次签到成功了。
问题成功解决！
5.心得
通过对这次问题的解决，加深了对SQLAlchemy的了解，同时对并发锁有了更直观的理解。
