关键词：热更新 | 热重载 | 定时更新 | 即时更新 | 缓存 | functools | cachetools | LRU | TTL
假设应用需要加载一个配置文件config.txt，一般的做法类似于：
with open('config.txt') as f:
parameters = f.read()
接下来parameters中存储的数据就可以被其他代码使用，但是这样写的话程序每次启动后，数据是固定死的，无法动态地自我更新，每次要修改配置/模型只能重启整个应用。
本文中热更新的意思是在应用运行时内，从外部（如文件、数据库、REST API）中获得数据并更新应用内的Python对象。应用场景一般是应用作为服务（有对外的API），需要在不重启的前提下更新自己的配置参数或者算法模型。
热更新可以分为两种：定时更新（periodic update）和即时更新（on-call update），前者周期性地、主动地执行更新，后者则是被动地等待，直到接收到某种来自应用外部的信号才会执行更新。本文将通过内存缓存（Memory Cache）和装饰器（Decorator）技术来实现两种热更新。
内存缓存
先来说明一下内存缓存。缓存中的数据一般以键值对（key-value pair）的形式存在，value中放数据本身，key中放数据的某种描述名。缓存的容量决定了其最大可容纳的数据条数，当容量已满时再向缓存中存入新的数据，缓存就会采取开始清理行为：清除掉已存的部分数据，从而为新数据腾地方。清理的策略（判定何时需要清理、具体如何清理数据）有很多种，决定了缓存的不同类型。
Python中缓存常被写成装饰器的形式，缓存数据的key里放的是被装饰原函数的参数值组合（key的生成方法可以不同，后面还会提到），value里放的则是原函数的返回值。这样当函数被调用时，程序会先去缓存数据里找是不是已经有相同的参数值，如果有就直接返回已缓存的返回值，不重复进行原函数内的计算。
注意缓存的使用有一个隐含前提：函数本身是无状态的。假如函数内引用了全局变量，或者存在闭包，那同样的参数值不一定必然计算出相同的返回值。这样缓存的返回值和实际期望的返回值就不一定一致了。
定时热更新
定时更新的实现使用了来源于第三方库cachetools的TTLCache，TTL（Time-to-Live）指存在时长策略。这种缓存为每一条存入的数据记录其存在的时长。每次调用都会检查是否存在超过某个设定时长阈值的数据，如果有就会开始清理行为：所有超时数据都会被清除掉；如果没有超时数据，缓存将会换用LRU策略，使缓存不超出容量大小（下一部分会提到LRU的具体策略）。
当我们将TTL缓存的容量设为1时、且用于加载数据的原函数参数不变的情况下，逻辑就变成了定时更新：
- 未超过时长：缓存保留，每次调用都使用缓存数据
- 超过时长，缓存清空（只有一条数据），程序重新计算（在这里即重新加载数据）
示例代码如下（运行需要安装cachetools，并在文首链接里下载完整的项目）：
import time
import cachetools
from utils import change_conf_file
ROTATE = 5
@cachetools.cached(cachetools.TTLCache(1, ROTATE))
def reload():
print('Cache cleared, reloading config...')
with open('config.txt') as f:
parameters = f.read()
return parameters
class Model():
def log(self):
self.model = reload()
print(self.model)
if __name__ == '__main__':
# Reload automatically every [ROTATE] seconds
model = Model()
while True:
time.sleep(2)
change_conf_file() # change data
model.log()
即时热更新
即时更新的实现使用了来源于Python内置库functools的lru_cache，LRU（Least Recently Used）指最少使用策略。这种缓存为每一条存入的数据记录其被使用的次数，每次调用都会检查缓存大小是否超出容量，如超出就会开始清理行为：会从使用次数最少的数据开始清理，直到缓存大小处于容量以内。
当我们将LRU缓存的容量设为1、且用于加载数据的原函数参数不变的情况下，原函数只有在第一次被调用时才会发生计算，之后调用都会直接返回缓存中的数据，到这里与一般的读取效果上并无区别。当我们需要热更新数据的时候，只需要主动清空缓存。如下例中Getter.getModel.cache_clear()。其中Getter.getModel是装饰后的函数，其中带有用于清理缓存的函数cache_clear()。有了这个扳机，我们只需要额外开发一个API（比如REST下的GET）来触发它，这样通过外部即时call API就可以进行热更新了。
示例代码如下（运行需要在文首链接里下载完整的项目）：
import time
from functools import lru_cache
from utils import change_conf_file
class Getter:
@staticmethod
@lru_cache(1)
def getModel():
with open('config.txt') as f:
model = f.read()
return model
class Model():
def log(self):
self.model = Getter.getModel()
print(self.model)
if __name__ == '__main__':
# Reload only when cache_clear() is called
model = Model()
while True:
model.log()
time.sleep(2)
change_conf_file() # change data
Getter.getModel.cache_clear()
print('Cache cleared, reloading config...')
model.log()
这里补充一个细节，上面的示例中被缓存装饰器装饰的原函数getModel是一个无参数的函数，这种情况下lru_cache是如何运作的呢？lru_cache的实现中使用函数functools._make_key来生成缓存的key。在Python中，当原函数无参数时，默认参数args可认为是空元组()，可选参数可认为是空字典{}，在这种情况下生成的key将会是空列表[]（注意列表是不可hash的，不可直接作为字典的key，functools里的实际数据结构较为复杂，这里没有深入）。上一部分提到的第三方库cachetools实现了类似的方法keys.typedkey，两者生成的key存在区别，但是结合其他方法，行为在大部分情况是一样的，包括本文中的无参数函数情况。
import time
from functools import _make_key
from cachetools.keys import typedkey
if __name__ == '__main__':
print(_make_key((), {}, False)) # []
print(typedkey((), {}, False)) # ((), {}, <class 'tuple'>, <class 'dict'>)
扩展问题
-
多线程情况：本文的热更新方法均基于缓存，而由于缓存涉及到读写操作，在多线程环境下我们需要考虑其正确性。
functools.lru_cache和cachetools.TTLCache里均有使用到锁的机制，再考虑到Python的GIL锁，本文所述的热更新在线程安全上应该算是有保障的，但目前未经试验无法完全下断言。functools.lru_cache的文档中提到多线程环境下hit和miss的计数只是近似值，而Cachetool的文档中则明确提到cachetools.TTLCache这样的类是非线程安全的，需要额外提供锁以实现同步。最开始写这篇文章的时候我对GIL的理解有误，按我现在的理解，GIL宽泛地讲只会阻止多线程调用多个CPU，但同一个CPU下的多线程仍然是有效的（不然还要多线程干嘛），所以同步的问题还是要考虑清除。 -
import：假如我们在一个模块（module）里更新model，而另一个模块
import这个model，那么当原模块的model热更新后，import得到的model并不会更新，这种行为可能与Python自身的module cache有关。要实现所有module的热更新，能考虑的一个办法是让数据自己成为一个模块，使其变得可以在模块之间共享。
吐槽：这篇写得我浑身无力啊，本来觉得很简单，就平时用的小东西拿来拎拎清，没想到越拎越深...很多时候我们很happy是因为我们站在冰山的最上面，不用面对水下的魔鬼细节...作为搞技术的，我们还是不能光看脸，也要多盯裆(≖＿≖)✧
