1. 关于session
flask session可能很多人根本都没有使用过，倒是cookie大家可能使用得比较多。flask cookie使用起来比较简单，就两个函数，读取和设置。
具体使用方式如下：
读取cookie
from flask import request
@app.route(‘/‘)
def index():
username = request.cookies.get(‘username‘)
# 使用 cookies.get(key) 来代替 cookies[key] ，
# 以避免当 cookie 不存在时引发 KeyError 。
设置cookie
@app.route(‘/‘)
def index():
resp = make_response(render_template(...))
resp.set_cookie(‘username‘, ‘the username‘)
return resp
cookie的设置是必须在response返回时，并且是作为response的一部分给client段返回的。
其实理解了cookie的原理就大概知道为什么这么做了，cookie是为了保存用户的一些信息，而这些信息其实是保存在浏览器的缓存中的，大家平时清理浏览器的访问记录时其实就是在清除对应的cookie。
每次请求的时候，浏览器会根据所访问的网页把对应保存的用户相关的cookie信息放到request中给服务端发送过去。这样就节省了多次身份认证的过程。
关于flask cookie的详细使用方法可以参阅：http://dormousehole.readthedocs.io/en/latest/quickstart.html?highlight=cookie。这块就不细讲了。
这节主要讲的是session，具体cookie和session的区别，在网上可以查找到很多相关的资料。其实很多事情不需要刻意理解他们之间的具体差别，实际中遇到就能很好地理解他们之间的差别。
本文不会具体讲cookie和session概念上的差别，不过通过介绍完我使用的场景，想必大家就很清楚他们之间的区别了。
2 遇到的问题
自动化发布平台在用户创建工单表单的时候，需要用户指定其待发布的机器列表。这样OP在具体发布的时候根据发布所处的阶段来选择具体发布哪几台机器。因此，需要根据用户对应的业务从配置服务中拉取对应的机器列表让其选择。
并且这个机器列表是可能变化的。所以，这块单纯使用wtforms.fields.SelectField表单字段是不起作用的，因此需要使用wtforms.ext.sqlalchemy.fields的QuerySelectField字段。至于QuerySelectField的使用可以参考我的
上篇博客。
OP在发布的不同阶段，需要选定机器列表做具体的发布。具体机器列表的获取，也可以使用和创建工单的时候同样的方式，从配置服务中获取当前业务所有的机器列表。然后，让发布者从机器列表中选择机器列表中选择几台具体的机器做发布。
但是，这块会有一个问题。创建工单的时候，需要创建者从一个机器列表中选择几台期待的机器，而发布的各个阶段也都需要从同样的机器列表中选择几台机器做发布。这样就可能存在一个问题，发布者发布的时候应该是从创建工单的人选择的
机器列表中选择机器做发布，而不是从全局的机器列表中选择机器做发布。
因此，需要有种方式在创建表单的时候能够把工单的ID传递过去，这样可以从数据库中把工单的详细信息查询出来，并获取到用户选定的机器列表。
但是，这块用什么方式传递过去呢？
可能这样说不是很形象，具体用代码展示吧，发布过程中有预发布、灰度发布、以及发布。但是，这块以预发布为例，灰度发布和发布其实都一样。
@expose(‘/pre_release‘, methods = [‘GET‘, ‘POST‘])
def pre_release(self): pre_release_handle_form = PreReleaseHandleForm(request.form)
if request.method == ‘POST‘:
if helpers.validate_form_on_submit(pre_release_handle_form):
# user logic
return self.render(‘release.html‘, form = pre_release_handle_form
上面是预发布相关的逻辑，核心逻辑都去掉了，只留个大致的框架，不过这并不影响本文介绍的内容。
而PreReleaseHandleForm表结构如下：
class PreReleaseHandleForm(form.Form):
def query_factory():
return [r.task_name for r in db.session.query(Task).all()]
def get_pk(obj):
return obj
def iplist_query_factory():
# 从配置服务中获取 iplist = get_from_config_server()
return iplist
def iplist_get_pk(obj):
return obj
release_task = QuerySelectField(label=u‘发布任务‘,
validators=[validators.required()],
query_factory=query_factory,
get_pk=get_pk)
rollback_task = QuerySelectField(label=u‘回滚任务‘,
validators=[validators.required()],
query_factory=query_factory,
get_pk=get_pk)
target_machine = QuerySelectMultipleField(label=u‘目标机器‘,
validators = [validators.required()],
query_factory=iplist_query_factory,
get_pk=iplist_get_pk)
remark = fields.TextField(label=u‘备注‘, validators=[validators.required()])
此处可以看到QuerySelectMultipleField函数，其能够支持表单的多选以及能够动态获取选项列表。因此，在此处替代MultiSelectField。
上述的代码不做详细介绍，算是比较简单的使用，我们关注的核心是iplist_query_factory函数，它是本文的核心。预发布的机器列表就是由此函数产生的。
但是，由于我们在预发布的时候表单并没有上下文，我们不知道其对应哪个具体的工单，而且表单肯定是无状态的。所以，就跟此处有冲突，我们期待在表单页面显示的时候就能够
根据具体的上下文从创建的工单中获取待发布的机器列表，并展示出来。
3 解决的办法
因此，第一个想法是使用cookie，这样我们在向客户端显示表单页面的时候顺便把工单ID放个response中并给客户端返回。这样iplist_query_factory函数会根据request上下文从cookie中
取出对应的ID，并从数据库中查询对应的工单详细信息，并回去对应的待发布机器列表并给客户端展示。
不过这块需要PreReleaseHandleForm和pre_release函数都做稍微的修改，具体修改内容如下：
def iplist_query_factory():
id = request.cookie.get(‘ID‘)
job = db.session.query(Job).filter_by(id = id).first()
iplist = job.pre_release_iplist.split(‘,‘)
return iplist
@expose(‘/pre_release‘, methods = [‘GET‘, ‘POST‘])
def pre_release(self):
id = request.args.get(‘id‘, ‘‘)
pre_release_handle_form = PreReleaseHandleForm(request.form)
if request.method == ‘POST‘:
if helpers.validate_form_on_submit(pre_release_handle_form):
# user logic
resp = make_response(self.render(‘release.html‘, form = pre_release_handle_form))
resp.set_cookie(‘ID‘, id)
return resp
具体的话，大家可以关注上面加粗的地方。其实还是蛮容易理解的，在向客户端返回response的时候需要在response的cookie属性中设置对应的ID字段的值，在iplist_query_factory中从cookie中查询对应字段的值。
这块并不会因为多线程而出现问题，因为在flask中request上下文是线程安全的。
但是测试的时候发现这块有个问题，就是我第一次展示表单页面的时候IP列表是空的，必须我重新刷新一次才可以。之后的情况就是我重新打开页面，显示的机器列表确实上一次的机器列表。
后来想了想，才发现一个问题。每次的表单显示的时候其实对应的response并没有给客户端返回，因此拿到的是上次请求的cookie值，这样就存在着延后，跟真实的情况不同步。
要是任由这种情况发展还是蛮危险的。因此，只能使用另外一种方式解决了，后来发现另外一种解决方式就是session。
看了下flask admin session的具体实现，发现flask session其实是request上下文，而flask的实现其实对于每个request会分派给一个独立的线程，其实是线程安全的。
from functools import partial
from werkzeug.local import LocalStack, LocalProxy
def _lookup_req_object(name):
top = _request_ctx_stack.top
if top is None:
raise RuntimeError(‘working outside of request context‘)
return getattr(top, name)
def _lookup_app_object(name):
top = _app_ctx_stack.top
if top is None:
raise RuntimeError(‘working outside of application context‘)
return getattr(top, name)
def _find_app():
top = _app_ctx_stack.top
if top is None:
raise RuntimeError(‘working outside of application context‘)
return top.app
# context locals
_request_ctx_stack = LocalStack()
_app_ctx_stack = LocalStack()
current_app = LocalProxy(_find_app)
request = LocalProxy(partial(_lookup_req_object, ‘request‘))
session = LocalProxy(partial(_lookup_req_object, ‘session‘))
g = LocalProxy(partial(_lookup_app_object, ‘g‘))
上面是flask源代码，具体只需要看下上面加粗的代码就可以了。可以看出session其实是request上下文安全的。
因此，可以直接使用。至于fllask session的使用也是蛮简单的。具体代码如下：
def iplist_query_factory():
id = session[‘ID‘]
job = db.session.query(Job).filter_by(id = id).first()
iplist = job.pre_release_iplist.split(‘,‘)
return iplist
@expose(‘/pre_release‘, methods = [‘GET‘, ‘POST‘])
def pre_release(self):
id = request.args.get(‘id‘, ‘‘)
session[‘ID‘] = id
pre_release_handle_form = PreReleaseHandleForm(request.form)
if request.method == ‘POST‘:
if helpers.validate_form_on_submit(pre_release_handle_form):
# user logic
returnn self.render(‘release.html‘, form = pre_release_handle_form)
上面加粗的代码就是session的使用，发现没有其实session使用起来比cookie更方便。
测试发现效果完全符合预期，但是蛮不错的。
4 小结
之前关于这个问题想了好久，没有想到具体的解决方案，后来无意间想到了。所以，遇到问题不要放弃，坚持就是胜利！