Flask上下文管理

Posted 2021-01-22 wdbgqq

引子：

　　在了解flask上下文管理机制之前，先来一波必知必会的知识点。

一、面向对象双下方法

　　首先，先来聊一聊面向对象中的一些特殊的双下划线方法，比如__call__、__getattr__系列、__getitem__系列。

　　__call__

　　这个方法相信大家并不陌生，在单例模式中，我们可能用到过，除此之外，还想就没有在什么特殊场景中用到了。我们往往忽视了它一个很特殊的用法：对象object+()或者类Foo()+()这种很特殊的用法。在Flask上下文管理中，入口就是使用了这种方式。

　　__getitem__系列

　　使用这个系列的方法时，我们最大的印象就是调用对象的属性可以像字典取值一样使用中括号([])。使用中括号对对象中的属性进行取值、赋值或者删除时，会自动触发对应的__getitem__、__setitem__、__delitem__方法。

__getitem__系列

　　__getattr__系列

　　使用对象取值、赋值或者删除时，会默认的调用对应的__getattr__、__setattr__、__delattr__方法。

　　对象取值时，取值的顺序为：先从__getattribute__中找，第二步从对象的属性中找，第三步从当前类中找，第四步从父类中找，第五步从__getattr__中找，如果没有，直接抛出异常。

__getattr__系列

二、偏函数

　　再来说说Python中的偏函数

　　python中有一个小工具包functools，这个包中包含了几个在很有用的小功能，比如：wraps：在使用装饰器时，使用这个方法可以保护函数的元信息。reduce：一个合并序列项为一个单一值的小方法。还有一个就是偏函数： partial  

　　一句话来总结partial的作用，固定函数中的一些参数，返回一个新的函数，方便调用

来一个复杂点的偏函数的用法

　　仿照flask来实现一个更复杂的

仿flask版

三、threading.local

　　再来说一说threading.local方法

　　在多线程中，同一个进程中的多个线程是共享一个内存地址的，多个线程操作数据时，就会造成数据的不安全，所以我们就要加锁。但是，对于一些变量，如果仅仅只在本线程中使用，怎么办？

　　方法一，可以通过全局的字典，key为当前线程的线程ID，value为具体的值。

　　方法二，使用threading.local方法

　　threading.local 在多线程操作时，为每一个线程创建一个值，使得线程之间各自操作自己 的值，互不影响。

threading.local示例

　　自定义使用threading.local的功能

自定制更细粒度的threadinglocal

　　仿照flask用栈来实现自定义threading.local的存取

 1 from greenlet import getcurrent
 2 
 3 class Local(object):
 4 
 5     def __init__(self):
 6         object.__setattr__(self,"_storage",{})
 7 
 8     def __setattr__(self, key, value):
 9 
10         # ident = threading.get_ident()
11         ident = getcurrent()   # 定制粒度更细的
12         if ident in self._storage:
13             self._storage[ident][key] = value
14         else:
15             self._storage[ident] = {key:value}
16 
17     def __getattr__(self, item):
18         # ident = threading.get_ident()
19         ident = getcurrent()
20         return self._storage[ident][item]
21 
22 
23 class LocalStack(object):
24 
25     def __init__(self):
26         self.local = Local()
27 
28     def push(self,item):
29         self.local.stack = []
30         self.local.stack.append(item)
31 
32     def pop(self):
33         return self.local.stack.pop()
34 
35     def top(self):
36         return self.local.stack[-1]
37 
38 _local_stack = LocalStack()
39 _local_stack.push(55)
40 print(_local_stack.top())  # 取栈顶元素

利用栈

　　预热完毕，来一波真正的操作，不过在正戏上演之前，先来提一嘴，flask与其他python框架比如（Django、tornado）在整个请求生命周期中对于数据的管理机制的不同。django、tornado是通过传参的形式传递数据，而flask是通过其特有的上下文管理机制来管理数据的。

　　下面进入我们今天的正题----flask的上下文管理机制。在flask中，上下文管理机制分为两个大的部分：请求上下文和应用上下文。

接下来，从以下三个大的方面分别探讨flask的两大上下文管理机制。

1.  方面一：请求进来时
2.  方面二：视图函数
3.  方面三：请求结束前

　　先来一个最简单的flask版的Hello World

Flask版Hello World

　　启动一个flask项目时，会先执行app.run()方法，这是整个项目的入口，执行run方法时，接着执行werkzeug模块中的run_simple

　　

　　werkzeug中触发调用了Flask的__call__方法

　　1.请求进来时

　　触发执行__call__方法，__call__方法的逻辑很简单，直接执行wsgi_app方法，将包含所有请求相关数据和一个响应函数传进去。

符合wsgi协议标准的函数

　　备注：__call__是一个符合wsgi标准的函数

　　执行wsgi_app方法

wsgi_app

　　第一步先执行了一个request_context的方法，将environ传进去，最后返回一个RequestContext类的对象，被ctx的变量接收（ctx=request_context(environ)）

 1 def request_context(self, environ):
 2         """Create a :class:`~flask.ctx.RequestContext` representing a
 3         WSGI environment. Use a ``with`` block to push the context,
 4         which will make :data:`request` point at this request.
 5 
 6         See :doc:`/reqcontext`.
 7 
 8         Typically you should not call this from your own code. A request
 9         context is automatically pushed by the :meth:`wsgi_app` when
10         handling a request. Use :meth:`test_request_context` to create
11         an environment and context instead of this method.
12 
13         :param environ: a WSGI environment
14         """
15         return RequestContext(self, environ)

View Code

　　这个ctx对象在初始化时，赋了两个非常有用的属性，一个是request，一个是session

def __init__(self, app, environ, request=None):
    self.app = app
    if request is None:
        request = app.request_class(environ)
    self.request = request
    self.url_adapter = app.create_url_adapter(self.request)
    self.flashes = None
    self.session = None

 　　这两个属性中request是一个Request()对象，这个对象就是我们在flask中使用的request对象，为我们提供了很多便捷的属性和方法，比如：request.method、request.form、request.args等等，另一个属性是session，初始为None。

　　紧接着执行ctx.push()方法，这个方法中，在执行请求上下文对象ctx之前先实例化了一个app_context对象，先执行了app_context的push方法，然后才执行_request_ctx_stack对象中的top和_request_ctx_stack.push(self)，最后对ctx中的session进行处理。

　　所以，flask中的应用上下文发生在请求上下文之前。

在ctx.push方法的执行逻辑

　　但是我们先说请求上下文，在处理完应用上下文的push方法后，紧接着执行了_request_ctx_stack对象的两个方法。

　　而这个_request_ctx_stack是LocalStack这个类的对象。_request_ctx_stack = LocalStack()

 　　LocalStack有没有很眼熟，没错，flask内部使用的机制就是类似于我们上文中自定义的LocalStack的机制，实例化过程中使用了面向对象中的组合概念，self._local = Local()，然后在自身又实现了push、pop、top方法，这三个方法中都是通过反射从Local类的实例化对象中对一个stack属性进行append、pop、[-1]的操作，所以，Local对象中的stack属性对应的值一定是一个类似于列表的东西。通过对列表的操作，实现一个类似于栈的存取。

　　接着聊聊这个Local类，在实例化时，会对每个对象生成一个storage的空字典。我们翻遍整个Local类的源码，发现内部并没有实现一个叫stack的方法或者属性，但是上面我们提到了LocalStack对象会对Local对象中的一个叫stack的东西进行一系列操作。找不到不会报错吗？

　　这就是flask的巧妙之处，通过类的一些魔法方法巧妙的实现了相应的处理。在前引中，提到如果对象中没有某个属性，取值时，最终会执行类中的__getattr__方法，然后再做后续的异常处理，flask将所有的对应逻辑都实现在了类的__getattr__方法中，将每一个线程存储到字典中，在请求进来时，将每一个对应的请求ctx存在一个列表中，使用时直接调用，而不是通过传参的形式，更体现出了flask框架的轻量级。

　　处理完_request_ctx_stack后，就该处理session了。

　　在flask中，处理session时，非常的巧妙，完美的遵循了开闭原则，会先执行session_interface对象的open_session方法，在这个方法中，会先从用户请求的cookie中获取sessionid，获取该用户之前设置的session值，然后将值赋值到ctx.session中。

　　处理完session后，ctx.push方法就执行完了，返回到最开始的app.wsgi_app方法中，执行完push方法后，接着执行full_dispatch_request方法，从这个名字中我们也能猜到，这个方法只要是负责请求的分发。

full_dispath_request方法

　　在full_dispatch_request方法中先执行preprocess_request方法，这个方法，会先执行所有被before_request装饰器装饰的函数，然后就通过路由的分发执行视图函数了（dispatch_request）

　　2.执行视图函数时

在执行视图函数之前，先执行了before_request，在执行我们的视图函数。

　　视图函数主要处理业务逻辑。在视图函数中可以调用request对象，进行取值，也可以调用session对象对session的存取。

　　在整个request的请求生命周期中，获取请求的数据直接调用request即可，对session进行操作直接调用session即可。request和session都是LocalProxy对象，借助偏函数的概念将对应的值传入_lookup_req_object函数。先从_request_ctx_stack（LocalStack）对象中获取ctx(请求上下文对象)，再通过反射分别获取request和session属性。整个过程中LocalStack扮演了一个全局仓库的角色，请求进来将数据存取，需要时即去即用。所以，flask实现了在整个请求的生命周期中哪儿需要就直接调用的特色。

　　request = LocalProxy(partial(_lookup_req_object, ‘request‘))
　　session = LocalProxy(partial(_lookup_req_object, ‘session‘))
　3.请求结束前

　　视图函数执行完后，dispatch_request执行结束，执行full_dispatch_request方法的返回值finalize_request方法。这个方法中，同样的，在返回响应之前，先执行所有被after_request装饰器装饰的函数。

　　---->finalize_request ------> process_response

 1  def process_response(self, response):
 2         
 3         ctx = _request_ctx_stack.top
 4         bp = ctx.request.blueprint
 5         funcs = ctx._after_request_functions
 6         if bp is not None and bp in self.after_request_funcs:
 7             funcs = chain(funcs, reversed(self.after_request_funcs[bp]))
 8         if None in self.after_request_funcs:
 9             funcs = chain(funcs, reversed(self.after_request_funcs[None]))
10         for handler in funcs:
11             response = handler(response)
12         if not self.session_interface.is_null_session(ctx.session):
13             self.session_interface.save_session(self, ctx.session, response)
14         return response

process_response

　　执行process_response过程中，执行完after_request后，然后，执行session的save_session方法。将内存中保存在ctx.session的值取到后，json.dumps()序列化后，写入响应的cookie中（set_cookie），最后返回响应。

 1 def save_session(self, app, session, response):
 2         domain = self.get_cookie_domain(app)
 3         path = self.get_cookie_path(app)
 4 
 5         # If the session is modified to be empty, remove the cookie.
 6         # If the session is empty, return without setting the cookie.
 7         if not session:
 8             if session.modified:
 9                 response.delete_cookie(
10                     app.session_cookie_name,
11                     domain=domain,
12                     path=path
13                 )
14 
15             return
16 
17         # Add a "Vary: Cookie" header if the session was accessed at all.
18         if session.accessed:
19             response.vary.add(‘Cookie‘)
20 
21         if not self.should_set_cookie(app, session):
22             return
23 
24         httponly = self.get_cookie_httponly(app)
25         secure = self.get_cookie_secure(app)
26         samesite = self.get_cookie_samesite(app)
27         expires = self.get_expiration_time(app, session)
28         val = self.get_signing_serializer(app).dumps(dict(session))
29         # set_cookie将session写入响应的cookie中
30         response.set_cookie(
31             app.session_cookie_name,
32             val,
33             expires=expires,
34             httponly=httponly,
35             domain=domain,
36             path=path,
37             secure=secure,
38             samesite=samesite
39         )

save_session

　　返回响应后，自动的调用ctx.auto_pop(error)，将Local中存储的ctx对象pop掉，整个请求结束。

　　请求上下文的执行流程：

 

 

应用上下文

 

　　与请求上下文类似，当请求进来时，先实例化一个AppContext对象app_ctx，在实例化的过程中，提供了两个有用的属性，一个是app，一个是g。self.app就是传入的全局的app对象，self.g是一个全局的存储值的对象。接着将这个app_ctx存放到LocalStack()。

class AppContext(object):
　　def __init__(self, app):
　　　　self.app = app
　　　　self.url_adapter = app.create_url_adapter(None)
　　　　self.g = app.app_ctx_globals_class()　　

　　视图函数中，我们就可以调用app对象和g对象，如果我们使用蓝图构建我们的项目时，在每一个直接引用app就会造成循环引用的异常，这时，应用上下文就会显得非常有用，我们可以直接调用current_app就可以在整个生命周期中使用我们的app对象了。比如使用我们的配置项：current_app.config

current_app = LocalProxy(_find_app)

　　最后，当视图函数执行结束后，从storage中pop掉app_ctx对象。

 1 from flask import Flask,request,session,g
 2 
 3 app = Flask(__name__)  # type:Flask
 4 
 5 @app.before_request
 6 def auth_demo():
 7     g.val = 123
 8 
 9 @app.route(‘/‘)
10 def index():
11     print(g.val)
12     return "Hello World"
13 
14 if __name__ == ‘__main__‘:
15     app.run()

g的简单实用事例

　　总结：flask中的上下文管理机制分为请求上下文和应用上下文两大方面，通过上下文的管理机制，实现了即去即用的一个特色。