这篇文章来自于review pr时，发现owner对一个简单需求进行了有些复杂的抽象。review完后在想怎么和他讲这个事情：直觉告诉我不太OK，我也知道怎么改合适。但是我不知道怎么能让他未来遇到其它问题时能够进行恰当的抽象。于是就开始思考，有没有什么系统化的方法论，来指导确定一个设计需要进一步抽象，而不是靠直觉。

结论是，可以用两个问题帮助自己确认是否要进行抽象：

• 为什么直接写不可以？
• 抽象的代价是什么？

问题 1：为什么直接写不可以？

—— 说不上来往往是可以直接写。

 可以接受的常见答案：

1. 修改面不可控：直接写会导致未来新增/变更需要改 N 处（N 明显大于 2 或者分散在多模块），且容易漏改。
2. 不变式无法集中表达：直接写会让关键不变式（安全/风控/状态一致性/资源释放）散落在各处，难以审计和测试。
3. 边界无法建立：直接写会导致调用方必须知道内部细节才能正确使用（例如：必须按特定顺序调用、必须手动对齐某些时序/锁），这说明缺少“语义边界”。
4. 性能或资源目标达不到：直接写会导致无法满足 O(Δn)/延迟/内存上限/并发安全等硬指标，而抽象可以把这些约束固化成结构。
5. 可观测/运营不可持续：直接写会导致指标口径不一致、排障路径不统一，无法在团队规模下稳定运行。

如果回答不落在以上之一，默认结论通常是：可以直接写。

问题 2：抽象的代价是什么？

—— 抽象不是免费午餐

四类税：

1. 概念税：引入了几个新概念/新类型/新协议？新人理解需要多长路径？是否需要读多个文件才能理解？
2. 耦合税：抽象把哪些东西绑定死了？未来替换实现是否更难？抽象边界是否泄漏（调用方仍需理解内部细节）？
3. 性能税：从 O(Δn) 变 O(n) 了吗？多了分配/拷贝/解码/unique/sort 吗？热路径是否可证明不退化？
4. 演进税：为了适配一个新需求，需要改抽象本身吗？如果要改抽象，会不会影响所有调用方？

恰当进行抽象时，上述四个代价应当是想清楚的，如果答不出来，说明是凭感觉抽象，不可取。

补充一问：核心不变量是什么？

—— 可能的回击：未来可能会拓展

针对这种潜在需求，要求写出未来可能出现的两个扩展示例，并说明它们如何落在同一契约下。写不出来，就说明抽象是预支。

总结

这次 code review 让我意识到：判断是否需要抽象，不能只靠“直觉觉得不对”，而应当有一套可复用的决策流程。抽象的价值在于建立稳定语义边界、集中不变式并隔离变化，但它永远伴随成本，因此必须先问清楚两件事：为什么不能直接写、抽象要付出什么代价。若“不能直接写”的理由无法落在修改面不可控、不变式无法集中、边界无法建立、性能/资源目标达不到、可观测/运营不可持续这类硬约束上，默认就应该直接写；而一旦选择抽象，就必须显式核算概念税、耦合税、性能税、演进税，答不出来往往意味着抽象是凭感觉而非证据驱动。最后，为了防止用“未来可能扩展”合理化过度设计，还需要补充追问核心不变量与变化轴：要求给出至少两个具体扩展示例，并证明它们确实落在同一契约之下，否则就是在预支复杂度。通过这套问题集，抽象从审美与习惯变成可审计的工程决策，也更容易在团队内形成一致的代码风格与演进路径。

我们在做风控层的时候有个需求，就是实现一条一条的风控规则，对每个规则，都有自己需要维护的状态，比如关注盘口的需要读books5，关注资金的需要读fund，关注nav的需要读nav_update。之前为了复用逻辑，直接让风控规则的基类借用了Executor，让风控规则去override+subscribe Executor的各类事件回调。这是当时设计风控层时很自然的做法，但是今天梳理时发现会有些恶心的问题：

• 调用复杂度上升：一个事件过来后需要知道这是哪类事件，哪些规则订阅了这个事件，再逐个去调用订阅了这个事件的规则对应的回调函数，对我们海量的事件来说，每处理一个事件都需要反复查字典反复去调各种不同的函数，是不小的性能开销
• 可维护性下降：Executor接口定义可能常改，改一次都要调整一大堆风控规则
• 思维上比较“重”：每个风控规则其实都是一个小执行策略Executor，几十条规则就是同时跑几十个Executor，不对劲

思考了两个小时后发现其实是内部系统和用户接口的边界没有梳理清楚，正确的做法是直接在风控层用更底层的on_event函数，而不是一堆为了方便用户顾名思义的不同的回调函数。区分几个概念：

• 系统：提供一系列功能的复杂代码逻辑
• 用户：对系统不了解的使用者，在我们的语境下可以是策略研究员
• 工程师：对系统内部实现非常了解的开发者，就是我们
• 用户接口：系统的用户和系统内部逻辑进行交互的入口

Executor的API set设计是面向用户的一种易用用户接口，使得用户不感知执行引擎、ctx中的事件循环和分发逻辑，保证了可读性、易用性、防呆设计。但是风控层本身是系统的一部分，这部分逻辑不面向用户而是面向工程师，之前图方便直接借用了Executor的API set，但是实际上风控层根本用不着这么上层的API：我们知道每个可以override的callback背后都是一个个的event，那么不用绕一圈去屏蔽event概念，直接定义个on_event函数就完事了，里面让规则自己去match event。

面向用户的接口要减少概念；面向系统的接口要暴露事实。把系统部件建立在用户接口之上，迟早会被用户接口的演进拖累。

小小的工程哲学：抽象给用户，底层给系统。顺手记一下。

2024年4月之前腾讯云可以申请一年有效期的免费单域名SSL证书，政策更新后免费证书只能申请3个月有效期的单域名证书，考虑到我有众多HTTPS服务，并且更新博客源站证书需要同步更新CDN证书配置，频繁替换证书为网站/服务运维造成巨大的时间与精力成本（看到政策更新的内容后一口老血吐了出来）。

于是开始寻找一种自动化部署与更新方案，恰好发现著名免费SSL证书机构Let's Encrypt有泛域名证书提供，有效期三个月，之前只是用过Let's Encrypt单域名证书，计划依赖该机构实现自动化源站证书与CDN证书更新。

本文将使用acme.sh客户端+腾讯云API(TCCLI)实现该需求，下面简要介绍涉及到的工具和概念：

acme.sh：acme协议客户端，用于向机构（Let's Encrypt）申请证书，在申请过程中完成发起证书申请和验证域名所有权功能。github repo：https://github.com/acmesh-official/acme.sh

涉及到的腾讯云API：

• UploadCertificate：上传证书加入托管列表
• ModifyDomainConfig：修改证书为已托管的证书（ref-示例4 更新 HTTPS 服务器证书 ID）

API调用使用TCCLI完成：TCCLI简介 https://cloud.tencent.com/document/product/440/6176

搭建步骤

基本方案：

• 证书签发/维护：用acme.sh申请Let's Encrypt的泛域名证书，申请一个证书全家域名可用，并且通过acme.sh提供的renew hook功能触发CDN证书部署和宝塔(Nginx)证书更新替换
• CDN部署：腾讯给的TCCLI几乎支持100%的控制台功能，支持查询启用CDN域名，上传和替换CDN设置的证书

1. Prerequisite
   1. 一台服务器
   2. 一个域名
   3. BT面板(optional)/Nginx部署
      1. 需要先有个网站，需要知道怎么用Nginx配置SSL，这个此处不展开讲，不用宝塔面板也可以，我主要是懒，用UI配置方便不动脑
      2. 后面的Nginx SSL配置路径替换宝塔的，给出的脚本仅供参考，脚本的功能本身是Nginx证书更新+Tencent CDN部署的超集，参考脚本稍作修改即可自己完成定制化部署
   4. CDN已部署
      1. 这里使用腾讯的CDN，12块钱100GB/yr的流量包
   5. 科学上网
      1. 安装acme.sh需要从被墙的raw.githubusercontent获取
   6. 对web服务器运维技术有基本了解
2. 安装acme.sh
   1. 参考acme.sh中文Wiki https://github.com/acmesh-official/acme.sh/wiki/说明
   2. 服务器无法连接GitHub可以下载Release压缩包离线安装
3. 安装TCCLI：https://cloud.tencent.com/document/product/440/34011
   1. 按照文档配置，需要去控制台创建腾讯云API Token
4. 创建DNSPod API Token：去DNSPod后台创建，记住Secret Key，以后看不到了
5. 证书签发：example.com替换成自己的主域名，使用acme.sh --issue指令配合--dns dns_dp指定DNSPod作为解析服务商，acme.sh会向CA申请证书，再用API在DNSPod解析记录里添加一个验证用记录，并且启用定时任务按时续期，将续期时的hook脚本设置成/path/to/on/renew/hook.sh

DP_Id=<DNSPodTokenId> DP_Key=<DNSPodTokenSecret> acme.sh --issue --dns dns_dp -d example.com -d '*.example.com' \
  --renew-hook "/path/to/on/renew/hook.sh"

还没创建回调的hook.sh，后面再创建，自己给一个喜欢的路径就好

注意：renew-hook只会在issue的时候设置，后面acme指令再加这个参数就不会有预期的效果，如果需要调整，修改~/.acme.sh/example.com(_ecc)/example.conf即可

6. 确定证书安装位置：搞一个路径，比如我用的/root/cert，里面存Nginx需要的证书文件，fullchain.pem和privkey.pem，证书文件和私钥文件，Nginx config里也配置为这个路径。另外还存个cert.cer，用来读取证书信息生成bt需要的info.json
7. 安装证书，使用acme.sh的--install-cert命令

acme.sh --install-cert -d jnn.icu \
  --key-file       /root/cert/privkey.pem  \
  --fullchain-file /root/cert/fullchain.pem \
  --cert-file      /root/cert/cert.cer \
  --reloadcmd      "service nginx force-reload"  # 这一行可选，如果你没有bt面板之类的，直接安装到nginx，更新完证书文件让Nginx reload一下就完事了，后面更新bt的步骤都不需要管了

这一步的指令会被acme.sh保存，后面acme.sh自动renew证书的时候会触发这个指令，把/root/cert里的文件更新为最新

8. renew_hook.sh内容，需要chmod +x renew_hook.sh

几分钟随手搓了个shell脚本，比较糙，但是能用🙈

echo on_renew_cert hook invoked
# env
export main_domain=<example.com>   # EDITME
export DP_Id=<DNSPodTokenId>       # EDITME
export DP_Key=<DNSPodTokenSecret>  # EDITME

# extract cert info
openssl x509 -text -noout -in /root/cert.cer 2>$1 > cert_info.txt
cn=$(cat cert_info.txt | grep -E 'Issuer.*CN' | sed -E 's/.*CN = (.*)/\1/' | tr -d '\n')
not_bef=$(cat cert_info.txt | grep -E 'Not Before' | sed -E 's/.*: (.*)/\1/' | tr -d '\n')
not_aft=$(cat cert_info.txt | grep -E 'Not After' | sed -E 's/.*: (.*)/\1/' | tr -d '\n')
subject=$(cat cert_info.txt | grep 'Subject: CN = ' | sed -E 's/.*CN = (.*)/\1/' | tr -d '\n')
dnss=$(cat cert_info.txt | grep 'DNS:' | tr -d ' ' | tr -d '\n' | sed -E 's/DNS:([^,]+)/"\1"/g')

# write bt info.json
echo \{\"issuer\": \"$cn\", \"notAfter\": \"$(date -d "$not_aft" +'%Y-%m-%d')\", \"notBefore\": \"$(date -d "$not_bef" +'%Y-%m-%d')\", \"dns\": \[$dnss\], \"subject\": \"$subject\", \"endtime\": $((($(date +%s -d "$not_aft") - $(date +%s -d "$not_bef")) / 86400 - 1))\} > info.json

# deploy cert to sites
for site in $(ls /www/server/panel/vhost/cert); do
  if [[ $site == *$subject ]]; then
    echo updating nginx $site cert
    # cp certs and info.json to bt cert/ssl path
    cp /root/cert/privkey.pem /root/cert/fullchain.pem info.json /www/server/panel/vhost/cert/$site/
    cp /root/cert/privkey.pem /root/cert/fullchain.pem info.json /www/server/panel/vhost/ssl/$site/
  fi
done

# reload nginx
echo reload nginx
service nginx force-reload

# upload cert to tencent cloud
resp=$(tccli ssl UploadCertificate --cli-unfold-argument --CertificatePublicKey "$(cat /root/cert/fullchain.pem)" --CertificatePrivateKey "$(cat /root/cert/privkey.pem)")
echo $resp
cert_id=$(echo $resp | grep CertificateId | sed -E 's/.*CertificateId.*:.*"(.*)".*/\1/' | tr -d '\n')

# deploy cdn cert
# grep online domain cdn deployments
for domain in $(tccli cdn DescribeDomains --cli-unfold-argument --endpoint cdn.ap-beijing.tencentcloudapi.com --Filters.0.Name status --Filters.0.Value online | grep \"Domain\" | sed -E 's/.*:.*\"(.*)\".*/\1/' | tr '\n' ' '); do
  if [[ $domain == *$subject ]]; then
    echo update online cdn domain deployment $domain
    tccli cdn ModifyDomainConfig --cli-unfold-argument --Domain "$domain" --Route 'Https.CertInfo.CertId' --Value "{\"update\":\"$cert_id\"}"
  fi
done
echo done

脚本流程：

1. 使用openssl导出证书信息（用来搓宝塔的证书信息JSON）
   1. PS：不用像我这样全用sed正则提取，openssl解析证书有很多参数，可以提取出需要的信息
2. 生成宝塔面板需要的info.json
3. 将证书拷贝到所有通过宝塔面板部署的网站配置目录
4. nginx重新加载配置文件，更新证书部署
5. TCCLI上传证书到腾讯云托管
6. TCCLI获取可应用本证书的CDN部署
7. 更新CDN证书配置为上传的托管证书

总结

这篇文章记录了一个highly customized方案，对大部分人来说是没法直接使用的。但是相信SSL免费证书有效期从1年缩短为3月后，应该很多人都会有申请免费泛域名证书并自动更新的需求，所以本文记录的方案应该有较大的参考价值，希望可以帮到一些被证书反复部署烦恼到的读者。

Numba是一个复杂的高性能解决方案，由于我工作的特点，会经常（被迫）需要使用Python完成一些对性能要求极高的数据处理工具，导致我经常与Numba斗智斗勇。Numba能够提供极大的性能提升，在Python里快速开发具有C性能的数据处理逻辑，但同样的，Numba也是一个复杂且坑点重重的解决方案。

np.dtype的类型签名

Numba对Numpy ufunc和数据类型有良好的兼容，直接将ndarray对象传入jitted func，Numba可以自动识别类型签名。但是某些时候，我们需要显式指定这些ndarray的签名，比如：定义有ndarray成员的jitclass，定义empty typed list等需要立即而非Lazy确定数据类型签名的场景。

使用内置dtype的ndarray

import numpy as np
from numba import experimental as nbe

@nbe.jitclass([('arr', nb.types.float64[:])])
class JITClass:
    def __init__(self):
        self.arr = np.zeros(100, dtype=np.float64)

Numba的基本数据类型和Numpy存在映射关系，nb.float64和np.float64编译后是同一种数据类型，在装饰器的spec参数里填写参数列表的类型，np.float64数组就是nb.types.float64[:]。

使用自定义dtype的ndarray

这里需要用到Numba提供的工具函数nb.from_dtype，可以将定义好的dtype对象转换为Numba可识别的类型签名。

import numpy as np
import numba as nb

my_type = np.dtype([('a', np.int32), ('b', np.float64)])
print(nb.from_dtype(my_type))

执行这个脚本，可以打印出这个dtype的Numba类型签名Record(a[type=int32;offset=0],b[type=float64;offset=4];12;False)

如果要定义一个ndarray，需要使用nb.from_dtype(my_type)[:]，因为返回的Record是“一行”（也就是标量）的类型。但是特殊地，Numba似乎也不支持将Numpy标量作为jitclass的成员，至少也得用ndarray包成向量Numba才能接受。

举个例子：

import numpy as np
from numba import experimental as nbe

# DTYPE_TRADE_EVENT 是我自定义的dtype

@nbe.jitclass([('_event', nb.from_dtype(DTYPE_TRADE_EVENT)[:])])
class EventWrapper:

    def __init__(self, event: np.ndarray):
        self._event = event

    @property
    def event(self) -> np.ndarray:
        return self._event[0]

我为了在一个JIT队列里面传递DTYPE_TRADE_EVENT类型的标量，设计了一个wrapper class，用一个一维向量保存这个标量（当然这个class还有其他的参数和功能，比如当作排序容器，没有展示在这里）。

提前编译

出于各种考量，可能是测量性能，也可能是定位性能问题，我们不希望需要JIT的函数在首次调用时才Lazy地进行编译，而是执行时函数已经就绪。一般来说，有三种方案可以解决这个问题：

• AOT（Ahead of Time）：提前编译，可以打成外部库，性能最强，限制最多
• Dummy Call：import模块的时候用一组伪调用提前调用要JIT的函数，并且按未来实际使用的类型提供参数
• Eager Compilation：在@jit修饰时就指定函数签名，定义时立刻编译，调用时不再支持其它类型的参数

何处发生了编译

用Numba进行加速时，总是需要反复进行测量，观察运行时间，然而Numba的编译并不算快，并不复杂的函数即时编译需要以秒计时，这可能导致对代码段运行效率的评估有错误的结论。这就导致我需要知道何处发生了预期外的编译。

Numba提供了编译函数的重载功能，我们可以把它拦截下来，打印栈信息，用这种方式可以快速定位到发生JIT的函数。可以理解为一个numba编译hook函数。

import traceback
import numba as nb

compile = nb.core.registry.CPUDispatcher.compile
def jit_probe(*args, **kwargs):
    print(f"------\ncompile {args[0]}:\n{''.join(traceback.format_stack())}------")
    return compile(*args, **kwargs)

nb.core.registry.CPUDispatcher.compile = jit_probe

效果：

$ python3.8 testnb.py 
------
compile CPUDispatcher(<function test at 0x7fa4b466a280>):
  File "testnb.py", line 22, in <module>
    test()
  File "/home/kino/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "testnb.py", line 11, in jit_probe
    print(f"------\ncompile {args[0]}:\n{''.join(traceback.format_stack())}------")
------
$

下面一个问题强化了这个函数的功能，可以打印新增的函数签名，可以继续往下看。

是什么导致了重新编译

进行Numba+Numpy的高性能开发时，会遇到一些难以定位的问题，这些问题会导致已经被编译的函数再次被编译，比如传入函数的参数类型由np.int32变成了np.int64。

这里需要使用.signatures 函数，这个函数可以获取已编译函数的所有签名组合。

Note：Numba在编译函数对象后，会为新的函数对象提供一些函数，因为没有签名，VSCode给jitted func后面加个'.'dot意图访问是不会有语法高亮和联想的。

略微修改一下上面的hook，可以得到个加强版的probe：

import traceback
import numba as nb

compile = nb.core.registry.CPUDispatcher.compile

def jit_probe(*args, **kwargs):
    r = compile(*args, **kwargs)
    print("------")
    print(f"compile {args[0]}:\n{''.join(traceback.format_stack())}")
    print(f"signature: {args[0].signatures[-1]}")
    print("------")
    return r

nb.core.registry.CPUDispatcher.compile = jit_probe

@nb.njit
def test(a):
    pass

test(1)
test(1.0)

效果：

$ python3.8 testnb.py 
------
compile CPUDispatcher(<function test at 0x7f660f191280>):
  File "testnb.py", line 23, in <module>
    test(1)
  File "/home/nji/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "testnb.py", line 9, in jit_probe
    print(f"compile {args[0]}:\n{''.join(traceback.format_stack())}")

added signature: (int64,)
------
------
compile CPUDispatcher(<function test at 0x7f660f191280>):
  File "testnb.py", line 24, in <module>
    test(1.0)
  File "/home/nji/.local/lib/python3.8/site-packages/numba/core/dispatcher.py", line 420, in _compile_for_args
    return_val = self.compile(tuple(argtypes))
  File "testnb.py", line 9, in jit_probe
    print(f"compile {args[0]}:\n{''.join(traceback.format_stack())}")

added signature: (float64,)
------
$ 

Numba并没有提供专门的工具函数完成这个需求。但是，hook它的编译函数，用这种稍有些tricky的方式，可以很简单地拿到编译发生的位置，以及造成编译的参数签名列表。

这篇文章会继续完善，如果有什么需要补充的地方，可以在评论区留言。

前言

一个段好的代码应该是优雅的，拥有强可维护性、强稳健性、高简洁性，而且还要实现复用。前两点，通过精心的设计和对情况的详尽考虑，是很容易实现的，但是要实现强稳健性，很可能需要牺牲简洁性（下面有个例子讲为什么），于是如何保证简洁性便成为了影响编写优雅代码的关键问题。

我在写后端时经常会有这么一个需求：我定义的某个接口收到了一些请求，这些请求的来源无法保证，内容无法保证，格式无法保证，我要让处理这些请求的流程保持有效，能够对各类异常和非法的请求进行识别和响应。现在，让我展示一下新手（刚开始接触这类开发时的我）会怎么实现这个需求。

一些原始方案

比初学时的我还新的新手

def request_handler(req: HttpRequest) -> JsonResponse:
    try:
        # do some preprocessing...
    except Exception:
        return JsonResponse({
            'code': 1,
            'msg': "internal error"
        })
    # do something...
    return JsonResponse({
        'code': 0,
        'msg': "success"
    })

看起来解决了问题，实际上产生了很多别的问题。首先，try-catch会隐藏逻辑错误，你只知道它出问题了，但是不知道出了什么问题。也许你会在日志里打印异常信息，但是不可否认的是很多异常信息是低可读性的，你并不能通过阅读日志立刻了解是哪里出了问题。这样的处理方式有可能会让程序产生一些不可控因素（鬼知道非法输入在try-catch里面干了什么事情）

初学时的我

这是我做大创项目时的一段代码

def queryCardPage(request: HttpRequest) -> JsonResponse:
    # 预先定义基础的返回 Json
    respj = {
        'code': None,
        'message': None,
        'data': {}
    }
    data = respj['data']

    # 检查请求类型
    if request.method != 'GET':
        respj['code'] = 0
        respj['message'] = "bad request"
        return JsonResponse(respj)

    courtId = request.GET.get('court')
    pageSize = request.GET.get('size')
    pageAt = request.GET.get('page')
    cardType = request.GET.get('type')
    targetType = request.GET.get('target')
    searchText = request.GET.get('name')
    normal = request.GET.get('normal')
    student = request.GET.get('student')
    faculty = request.GET.get('faculty')

    # 参数合法性校验
    if courtId is None or pageSize is None or pageAt is None \
       or not v.integerValidate(courtId) \
       or not v.integerValidate(pageSize, positive=True) \
       or not v.integerValidate(pageAt, positive=True) \
       or (normal is not None and not v.integerValidate(normal)) \
       or (student is not None and not v.integerValidate(student)) \
       or (faculty is not None and not v.integerValidate(faculty)) \
       or (cardType is not None and not v.integerValidate(cardType, positive=True)) \
       or (targetType is not None and not v.integerValidate(targetType, positive=True)):
        respj['code'] = 0
        respj['message'] = "bad request"
        return JsonResponse(respj)

    # do something HERE...

    respj['code'] = 0
    respj['message'] = "success"
    respj['data'] = '...'
    return JsonResponse(respj)

好的！我成功完成了这个需求，为do something HERE...保证了输入的合法性！就是…这段处理又臭又长🤮

对，这个原始的方案非常的麻烦、繁琐，可维护性和可读性也不高，下面看看有什么更优雅的方案

更优雅的解决方案

2021年9月19日，我又开始写后端，这次因为有了一些经验，便开始思考有没有更合理的方式处理这个问题

一些思考

能不能用一个函数去完成验证？稍微思考了一下，一个函数想给所有接口用，这不是扯淡吗？每个接口要求的字段都不一样，还有对字段内容更细粒度的要求，pass

运用一下自动机的思维？编写一个人类可读的语法定义式，为每个接口单独写一个对输入的语法定义，然后去构建这个语法定义的自动机，在请求发过来时，用自动机去匹配这个请求？感觉可行，拥有通用的合法性判断能力。来找找有没有轮子可以用！

JSON Schema

JSON Schema是一个开放的标准格式，它用于描述一个“合法的JSON文档”的格式，其中一个重要用途就是实例验证，下面来看一个例子：

{
    "type": "object",
    "required": ["title"],
    "properties": {
        "title": {"type": "string"},
        "tag": {
            "type": "array",
            "items": {
                "type": "string",
                "minLength": 1
            }
        },
        "author": {"type": "string", "minLength": 1},
        "gallery": {"type": "string", "minLength": 1},
        "minRating": {"type": "number", "minimum": 0, "maximum": 10}
    }
}

这个JSON Schema文档（下面称Pattern）定义了一个合法输入的格式，要求输入的JSON文档（下面称这个文档为A）满足它定义的要求：A中一定要出现”title”字段，其余字段可选，并且，A中只要出现了在Pattern的properties中定义的字段，该字段就必须满足properties中对它的限制条件。

光有这个Pattern还做不了对JSON的验证，我们还需要拥有对JSON Schema验证器的实现（轮子）

下面的连接指向一个开源项目库，里面列举了用不同语言实现JSON Schema校验的开源项目

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.
JSON Schema | The home of JSON Schema (json-schema.org)

这里我们以Python的 jsonschema 为例，这个第三方开源包实现了一个JSON Schema validator，直接用Python的字典表示JSON Schema即可

import json
import jsonschema

schema = {
    'type': 'object',
    'required': ['...'],
    'properties': {
        '...': {'type': '...'}
    }
}

def request_handler(http_req: HttpRequest) -> JsonResponse:
    if http_req.method == 'GET':
        return JsonResponse({
            'code': 1,
            'msg': "not post"
        })
    try:
        req = json.loads(http_req.body)
        jsonschema.validate(req, schema=schema)
    except JSONDecodeError:
        return JsonResponse({
            'code': 1,
            'msg': 'not json format'
        })
    except ValidationError as e:
        return JsonResponse({
            'code': 1,
            'msg': f"bad request format: {e.message}"
        })

    # do something HERE...

    return JsonResponse({
        'code': 0,
        'msg': "success",
        'response': '...'
    })

运行到do something HERE...的时候，就能确保req是一个合法的JSON（字典）请求了

这里还可以进行进一步抽象，可以把do something HERE...抽象出来，放到service层内，于是这里的request_handler变成为了纯粹的controller组件

👆通过这种方式，可以实现业务层与控制层的完全分离，逻辑上也会清晰很多，分离后业务层的代码也可以被其他控制层函数复用，可以消灭一大堆冗余代码

结语

最佳实践需要有一定的开发经验才可以理解，这篇文章中也体现了我一些曲曲折折的尝试路径，希望本篇笔记可以帮助一些人少走一点点弯路~

2021年9月22日

北京公积金租房提取有两种方式：

• 无发票提取
• 租住商品房提取

无发票提取

无发票提取方式一个月最多可以提取2000人民币，只需要承诺租住信息真实，不需要提供额外证明材料。

打开支付宝京通小程序，选择租房公积金提取，页面填写基本信息选择无发票提取方式，没有特别注意事项。但是这里需要提醒一下，如果实际并没有租房只是想提取公积金的话，需要承担欺诈行为被发现的潜在处罚风险，即禁止一段时间的公积金提取。

提取申请页面需要填写约定提取日期，建议选择每月3号及以后，1号2号提取量大，到账时间可能不准确，3号以后基本就是约定哪天哪天到账。

有发票提取

目前网上几乎没有任何关于开租房发票的详细资料，我在研究的时候打了无数咨询电话，每个单位都不知道租房发票提取公积金的完整流程，算是自己探索出来的😓。

• 好处：租金多少最多提多少
• 坏处：流程麻烦，开发票需要交2.5%左右的税

提取流程：

1. 电话咨询街道办，询问去哪里代开租房发票，找到负责街道的政务办公厅位置
2. 准备材料：和中介或房东联系，获取租房备案号（如：ZL2023海112***号），获取房东身份证复印件，准备好房东的手机号码，打印租房合同，打印自己的身份证复印件，准备好自己的身份证原件
3. 电话咨询政务办确认资料齐全，确认工作时间，一般来说，每月24号之前可以开具租房发票，24号后需要等待到下个月1号
4. 线下前往政务办开具发票，需要缴纳月租x缴纳月数x2.5%左右的个税，需要按合同租约时间和办事员确认你需要开具的月数，12个月租约可以多次开具也可以一次性开具，交的税是不变的，看需求开具
5. 打开支付宝京通小程序，选择租房提取公积金，类型选择租住商品房，备案号填写后大部分信息会自动填写，上传所需的全部材料，选择约定提取日期

北京租房提取公积金流程大致如上，如果有什么疑问可以发表在评论区，我会尽可能完善本文章。

基础概念

HTTP的工作模式

完整的HTTP请求是一段连续的数据，前段是header，后段是body，header内一般是HTTP标准指定的信息，body为数据体，包含通讯中的数据

请求之后HTTP服务器会回复一个响应（包含状态码和回复内容）

上面两个过程之后一次HTTP通讯就结束了（成为历史，所谓的无状态性）

GET和POST

GET请求是没有body的HTTP请求，用于“获取”数据，比如 GET http://example.com/time从服务器获取时间

GET请求可以在URL中附带参数，比如GET http://example.com/time?p=earth&zone=beijing 从服务器获取 地球 上 北京 时区的时间

POST请求是包含body的HTTP请求，数据体body中储存客户端和服务端约定的信息，一般会使用 Webform 或者 JSON 作为通讯格式

POST请求的应用场景是上传文件或者提交表单，以及调用API时的信息传递

注意 POST请求的URL也可以附带参数

了解 header，body

header内一般是HTTP标准指定的信息

header是可以自定义的，但是有很多保留key，比如一次百度搜索的请求

GET https://www.baidu.com/s?ie=utf-8&wd=搜索内容 HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 Edg/88.0.705.49
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://www.baidu.com/s?wd=linux%20%E8%BF%85%E9%9B%B7%E5%BF%AB%E9%B8%9F&rsv_spt=1&rsv_iqid=0x95c7e05c000bda09&issp=1&f=8&rsv_bp=1&rsv_idx=2&ie=utf-8&tn=baiduhome_pg&rsv_enter=1&rsv_dl=tb&rsv_sug3=25&rsv_sug1=29&rsv_sug7=100&rsv_sug2=0&rsv_btype=i&inputT=6580&rsv_sug4=6580
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,zh-TW;q=0.5
Cookie: A=这里是Cookie; B=HTTP请求中Cookie会被添加在header中; Cookie的内容是服务器决定的，比如sessionid会储存在Cookie

这里面的key都是HTTP请求标准保留的

body内容完全是开发者来自定的，不写例子了

Cookie

Cookie是储存在本地的，大小限制为4k的文本文件，里面包含一些由服务器决定的信息

比如你在example.com登陆了账号，那么example.com的服务器会给你分发一个sessionid，它会储存在你的Cookie里，服务器上也会储存一个sessionid，每次HTTP请求时，header中都会附上sessionid（其实就是附上Cookie），服务器可以在自己的cache中寻找你的sessionid，找到了就说明你登陆了，没找到就是没登陆

Cookie并不安全，如果在服务器从cache中移除你的sessionid前（登陆过期之前），有人偷走了你的Cookie（比如看雪爆出来的，QQ一直在干这事，简直是木马程序），那么他在这段时间就可以通过向header中加你的sessionid冒充你干任何事情

别的一些信息也可以储存在Cookie中，这就完全取决于开发者了（其实上面的session也只是一种模型，只不过大部分人实现的session模式都是差不多的）

Response

服务器收到GET和POST请求之后，处理完毕，会发送一个Response给客户端

JSON

JSON一定要掌握，通讯的时候经常会用到，也有一些开发环境把它当作配置文件（不过因为不允许注释，所以并不推荐）

JSON本身很简单，去W3C之类的地方稍微了解一下就可以了

附个链接 http://www.json.org.cn/

HTTP服务器

顾名思义，用来处理HTTP请求的服务器，客户端发过来HTTP请求，在HTTP服务器受理、完成、获得响应

后端

后端是一个抽象化的概念。用户在前端做了些事情，前端把业务信息传递给后端，后端去完成操作，再把结果告诉前端，前端再把结果以可视化的方式反馈给用户

注：前端是在用户使用软件的时候由服务器整体发送过去的，就好像发了个exe过去，这个exe在本地干活，时不时联系下服务器（后端）

下图是传统的三层架构（前后端分离模式中，这里的用户界面在前端），从左到右第一个箭头可以看作网络通讯，最后一个箭头表示数据访问的目标是数据库（持久化层），其实可以看作四层架构吧（逃

一般的开发人员都会以这个为基础进行后端的开发

后端开发者的任务是设计后三坨东西

后端框架

要手动去做一个HTTP服务器很麻烦（再造轮子），所以开发者们开发了很多现成的框架，用于简化构建HTTP服务器的流程

后端框架会为开发人员实现大量底层操作。利用框架，开发人员可以把大部分精力集中在功能上，而不是大量繁琐的底层操作

什么是框架？（前端和后端）

数据库

基于文件系统储存信息，持久化保存数据，具有查询、新增、修改数据的功能

SQL(结构化查询语言)教程

关系数据库与非关系数据库

大二还没上数据库的课，理论知识不充分，不详细解释了（逃

平时使用的MySQL等数据库就是关系型数据库

非关系型就比如利用Key-Value键值对储存的Redis（可以当cache用）

这些稍微有个概念就可以了

ORM

开发过程直接在业务逻辑中使用SQL语句会使程序不易理解、难以维护，同时会对迭代更新造成巨大麻烦（牵一发而动全身），所以在架构设计中独立出了数据访问层（DAO层，数据访问对象），数据访问层设计以为业务逻辑层提供统一的数据访问接口，使业务逻辑层不必将精力用于处理复杂的数据库关系与SQL语句。

ORM 指对象-关系映射。将数据库中的元素抽象为程序中的对象，例如：

数据库中有 user 表，此时我们可以从表中抽象出 User 对象，对 user 表的操作视为对一组 User 对象的操作。这样，我们在业务逻辑层，处理的都是 User 对象，对 User 的修改等价于对 user 表数据元素的修改，user 表数据元素的变更也会同步到 User 对象上。

后端框架大多会提供简化 ORM 建立的方法

学习后端框架

配置 Django 开发环境

强烈建议使用 VSCode，太香了，很方便

Django 使用 VSCode 配置开发环境 调试

Django Tutorial in Visual Studio Code

一定要看文档

Django 官方中文文档

快速入门一定要看，如果有时间下面的各种模式、模型也要看看，里面有很多 best practice

CORS 策略配置 (不配置好会 bad request)

两种常用用户系统认证方案

后面的内容会随本次大创项目的推进逐步完善🤞😆

2024-05-18 大概是因为大模型爆火，发现最近这篇文章的点击量在快速上升。说明一下，pyverbs是我23年初在灵均投资实习做RDMA的数据传输时学习的，当时发现pyverbs有一些难以排查的bug，可能和当时使用的IB卡型号和驱动有关，不清楚一年以后有没有改善，如果有顾虑可以选择rdma-core的C-API进行开发。不过通过本文了解Pyverbs的基本概念和用法是足够的。

Pyverbs

Pyverbs 是 Mellanox 开源的 rdma-core 接口封装，提供了一套简单易懂的服务原语。

打开设备

from pyverbs import device


ctx = device.Context(name='mlx5_0')

使用device模块的Context类初始化一个设备上下文，name参数指定设备名称。ctx创建后，即可通过ctx访问设备。

查询设备信息

from pyverbs import device


with device.Context(name='mlx5_0') as ctx:
    attr = ctx.query_device()

这段代码会打印出设备的信息。

查询GID

from pyverbs import device


with device.Context(name='mlx5_0') as ctx:
    gid = ctx.query_gid(port_num=1, index=3)
    print(gid)

这段代码会打印指定端口及index的GID。在基于IB的RDMA概念中，Node及Node的端口都有各自的GID，并且端口可以通过GID表维护多个GID。

查询端口

from pyverbs import device


with device.Context(name='mlx5_0') as ctx:
    port_attr = ctx.query_port(1)

这段代码会打印端口1的信息。

创建RDMA相关对象

Protection Domain

from pyverbs import device
from pyverbs.pd import PD


with device.Context(name='mlx5_0') as ctx:
    pd = PD(ctx)

这段代码创建了一个PD。

Protection Domain是一种集合，内部元素只能与内部元素交互，这些元素可以是AH,QP,MR,SRQ。相当于提供一个RDMA工作的容器。

Memory Region

from pyverbs import device
from pyverbs.pd import PD


with device.Context(name='mlx5_0') as ctx:
    with PD(ctx) as pd:
        flags = e.IBV_ACCESS_LOCAL_WRITE
        mr = MR(pd, mr_len, flags)

这段代码为该设备mlx5_0创建了一个MR。

Memory Region是用于为RDMA存放收发数据的内存区域，MR需要绑定到PD并被注册以供RDMA网卡进行DMA访问。

Memory Window

from pyverbs import enums, device
from pyverbs.pd import PD
from pyverbs.mr import MW


with device.Context(name='mlx5_0') as ctx:
    with PD(ctx) as pd:
        mw = MW(pd, enums.IBV_MW_TYPE_1)

这段代码创建了一个MW。

Memory Window从MR中内存空间分配的内存空间，MW在创建的时候会被绑定到一个已注册的MR上，MW是MR的子集，提供更加灵活的权限控制。

Device Memory

from pyverbs import device
from pyverbs.device import DM, AllocDmAttr


with device.Context(name='mlx5_0') as ctx:
    attr = ctx.query_device_ex()
    if attr.max_dm_size != 0:
        dm_len = random.randint(4, attr.max_dm_size)
        dm_attrs = AllocDmAttr(dm_len)
        dm = DM(ctx, dm_attrs)

这段代码创建了一个DM，使用设备内存。

Device Memory是位于RDMA网卡上的内存，使用DM和使用Host Memory在使用上没有太大区别，使用DM最大的优势是显著降低了包的传输延迟。

Device Memory Memory Region

import random

from pyverbs import enums, device
from pyverbs.device import DM, AllocDmAttr
from pyverbs.mr import DMMR
from pyverbs.pd import PD


with device.Context(name='mlx5_0') as ctx:
    attr = ctx.query_device_ex()
    if attr.max_dm_size != 0:
        dm_len = random.randint(4, attr.max_dm_size)
        dm_attrs = AllocDmAttr(dm_len)
        dm_mr_len = random.randint(4, dm_len)
        with DM(ctx, dm_attrs) as dm:
            with PD(ctx) as pd:
                dm_mr = DMMR(pd, dm_mr_len, enums.IBV_ACCESS_ZERO_BASED, dm=dm,
                             offset=0)

本段代码在设备上创建了一个DMMR。

DMMR与MR是同一级别的概念。区别是MR空间在主机内存中，DMMR空间在RDMA网卡内存中。

Completion Queue

import random

from pyverbs.cq import CompChannel, CQ
from pyverbs as device


with device.Context(name='mlx5_0') as ctx:
    num_cqes = random.randint(0, 200) # Just arbitrary values. Max value can be
                                      # found in device attributes
    comp_vector = 0 # An arbitrary value. comp_vector is limited by the
                    # context's num_comp_vectors
    if random.choice([True, False]):
        with CompChannel(ctx) as cc:
            cq = CQ(ctx, num_cqes, None, cc, comp_vector)
    else:
        cq = CQ(ctx, num_cqes, None, None, comp_vector)
    print(cq)

这段代码创建了一个CQ。

Completion Queue用于接收硬件传输来的CQE，用于从硬件向应用层传递某个WEQ/WR的完成情况。

Addressing related objects

地址与路由相关概念与接口的分析推迟到完成demo后继续补充。

Queue Pair

from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
from pyverbs.addr import GlobalRoute
from pyverbs.addr import AH, AHAttr
from pyverbs import enums, device
from pyverbs.pd import PD
from pyverbs.cq import CQ
import pyverbs.wr as pwr


ctx = device.Context(name='mlx5_0')
pd = PD(ctx)
cq = CQ(ctx, 100, None, None, 0)
cap = QPCap(100, 10, 1, 1, 0)
qia = QPInitAttr(cap=cap, qp_type = enums.IBV_QPT_UD, scq=cq, rcq=cq)
# A UD QP will be in RTS if a QPAttr object is provided
udqp = QP(pd, qia, QPAttr())
port_num = 1
gid_index = 3 # Hard-coded for RoCE v2 interface
gid = ctx.query_gid(port_num, gid_index)
gr = GlobalRoute(dgid=gid, sgid_index=gid_index)
ah_attr = AHAttr(gr=gr, is_global=1, port_num=port_num)
ah = AH(pd, ah_attr)
wr = pwr.SendWR()
wr.set_wr_ud(ah, 0x1101, 0) # in real life, use real values
udqp.post_send(wr)

这段代码创建了一个QP，并且使用post_send原语发送了一个wr。

Queue Pair包含Send Queue和Receive Queue，应用层访问下层的重要接口。

Extended Reliable Connection

拓展可靠连接域，高级特性先不分析

Extended Reliable Connection Domain

拓展可靠连接域，高级特性先不分析

Shared Receive Queue

共享接收队列，高级特性先不分析

上班好忙，好久没写blog了，这周末难得清闲，但发现自己已经电子游戏阳痿了，不如来写写博客吧~

在正定私募工作的这半年，学到了很多金融知识，也积累了很多技术实践，这次就来讲讲我花了大笔时间研究的东西——计算图调度与优化。

背景是这边有计算大量表达式的需求，表达式先被解析为为AST，而且这些表达式可能有公共子表达式（AST节点复用），子表达式又有子表达式层层嵌套（依赖关系与计算次序），所以表达式计算任务可以被表示为DAG。

说来有趣，当时乾象投资面试的时候（挂了），直接给我来了道计算图调度的题目。我之前做后端做性能优化，但是真没做过任何计算图的相关方向，当时费老大劲还被提示好几次才做出来。也正是因为这次经历，痛定思痛，对计算图有了更多的认知，也有了深入思考的动力。

写在前面

这篇文章并不是一篇算法或数据结构的科普文章，而是对计算图在工程上应用的思考与总结。如果有可能，希望这篇文章能尽可能地拓展读者的思路～内容专门做过脱敏，所以缺少例子，可能不那么容易读懂。

计算图有特别特别多的优化策略，还没有很细的研究，以后如果有需求会慢慢补充。

基本概念

首先弄明白计算图是啥，这里有个表达式 X=MAX((A+B)*C, C*D) ，翻译成计算图就是下面这个，按计算次序表明了表达式和子表达式的依赖关系的DAG。这里这个和AST就比较像，因为没有别的表达式，有别的表达式的话节点之间可能会复用，从而连接成一个图，AST就表示不了这个任务啦。

这里的概念其实我根据业务里具体的任务做的抽象，可能不是很通用🤷，看看就完了：

• 任务：业务中真正的计算任务
• 节点：计算图中的调度单元，一个节点可能包括多个任务
• 执行线程：用于进行节点的计算，执行节点内的任务
• 调度器：负责规划节点的执行，分配计算任务

计算图调度的任务本质上是从无入度节点开始遍历计算图，所有节点被遍历完成就是计算任务全部完成。

建图

我这里的需求在建图的时候已经拿到了经过拓扑排序的任务序列，节点也有上游依赖信息，这里就很简单了。先简单扫描一遍，把任务封装进节点，拿到任务和节点的映射，再反向扫描一遍，把任务的节点加入到上游任务的节点的下游列表中，一个简单的基于链表的图就建好了。当然，用邻接表什么的也行，视需求选用数据结构，毕竟数据结构不是重点。

调度

我这里有一个调度器线程去分配任务，而不是使用相对常见且简单的生产消费者模式，这是因为生产消费者模式并不能很好fit任务需求。消费者去竞争队列，往往会增加平均等待时间，更何况我的目标是使用100甚至200个CPU核心去加速计算任务，竞争可能会非常明显，哪怕用CAS也可能会有较大的失败率。更何况，任务是有优先级的，在执行时我们总是希望那一瞬间是高优而非低优任务被执行。而生产者队列中高优的任务可能会晚于低优任务被添加，不便于按优先级完成任务（如果把队列做成优先队列那平均等待时间就爆了）。后面会提到是如何使用调度器+执行器的模型解决这些问题的。

这里还有一个问题，那为什么不用GPU呢？1. 因为显存真不够，这个调度器一分钟调用一次，耗时要控制在100ms，而且每次调用需要计算一遍整个计算图，需要使用高至500GB的内存（后面的大型计算任务甚至要2TB内存）。如果用GPU，需要分布式计算，而且得把显存凑够，否则还得按需从内存拷贝到显存再按需释放，实现麻烦程度就大了去了；2. 算子很复杂，可以确定的是没有算子库可以用，大部分算子需要写CUDA去实现，学习成本和维护成本不太能接受。大概就这两个原因了。

节点的开销

节点的开销对调度器是很重要的，虽然真实的时间开销需要实际执行后才能知道，但是可以基于节点内任务的复杂度去估计节点的时间开销，每个节点都需要保存自己的开销信息。

节点优先级

节点优先级，或者称为权重，总希望当前可用任务中权重最高的节点先被执行。我这里权重的定义是对节点从该节点出发直到终止节点所经过节点的开销总和的最大值。这样的定义的目的是让开销最重的链路（因为依赖关系导致不能并行加速）最先被执行，从而尽可能缩短完成整个计算图的耗时，这是优先级定义的首要考量。

执行器流程

1. 尝试从固定地址轮询获取节点
2. 执行节点内任务
3. 向通知队列发送完成信息

调度流程

维护一个基于权重的大根堆，首先把开始节点（无入度）全部放进去。流程：

1. 启动循环
2. 判断是否大根堆为空且没有节点在执行器内执行，是则终止循环，否则继续
3. 循环从大根堆中取出权重最大节点并交给空闲执行器，直到大根堆为空或无空闲执行器
4. 尝试从通知队列中获取，如果失败，回到步骤2
5. 更新完成节点所有孩子节点的等待情况
6. 获取所有上游就绪的孩子节点，如果没有，回到步骤2
7. 讲获取到的孩子节点放入大根堆中，回到步骤2

这里还有一些优化方案会改变这个流程，下面会讲。

优化

这里的优化策略和我们具体的业务是息息相关的，所以大概读读，如果有启发最好。但是具体的业务内容那肯定是不能讲，只能写在内网的wiki上啦~

剪枝

我们这里业务需求中的计算图是要被多次计算的，并且每次计算时会有不同的参数，这些参数会决定本次计算有哪些表达式需要被计算，在计算图调度的语境下，就是有一些节点不需要被计算。

剪枝操作不是必要的，因为我们业务中的任务会自动跳过不需要执行的参数。但是为了降低调度开销，剪枝又是很重要的。这里的剪枝需要进行预处理。预处理会在建图之后反向扫描节点拓扑序列，计算每个节点及其后续所有节点计算条件的并集，调度时只需要判断参数是否满足条件集合，即可确认子图是否不需要被计算，从而完成剪枝。

需要修改调度流程，将7修改为：

7. 获取所有上游就绪且满足计算条件的孩子节点，如果没有，回到步骤2

节点内加速

对于计算图调度来说，每一个节点的执行效率都直接影响到整体的性能。尤其在金融领域，每一毫秒的时间都可能与大量的资金流转息息相关。因此，提高单个节点的执行速度变得至关重要。因为单个节点的加速，可以降低这个节点的时间开销，从而缩短计算图中的最长链路，缩短计算图内节点的平均权重。

这里的方案是为每个节点添加了一个拆分属性breakdown，并且用一个进度变量node_progress表示这个节点的完成情况。向执行器分配任务时，breakdown为10的节点就会被拆成10个任务去分发，调度器拿到的完成反馈也是10次，每次去更新下计数器，调度器发现进度满了就触发节点完成的处理逻辑。

另外也为了节点内加速设计了一套拆分逻辑，因为有些任务并不能完全并行完成，任务内可能包含一些步骤是必须串行处理的。最终的方案是把节点按任务的步骤拆分成并行节点和串行节点，这一步在建图计算breakdown的时候就完成。

需要修改调度流程，在4后面添加4.5：

4.5 更新节点的完成情况，如果breakdown未全部完成，则回到步骤2

节点合并

有一类表达式，比如 X=((A+B)*C)/D，每个计算都仅仅依赖上次的结果（ABC是变量，不是计算节点），这样的表达式在计算图中（如果子表达式没有被其它表达式复用）就是一个节点的链条。这样的链条必须串行执行，这就导致与其依次计算X的这些节点，不如把这些节点合并成一个节点，一次性调度和完成，消除调度带来的平均等待时间提升。

需要注意的是，进行了节点内加速（要求节点只有一个任务）的节点不能与其它节点进行合并。

不需要修改调度流程。

批量处理

为执行器队列设置一个有容量限制的队列，允许执行器队列内的任务一次性取出，然后按权重排序，按顺序一次性完成，而不是取一个做一个，降低队列竞争带来的开销。这里依赖了一个开源的ConcurrentQueue实现，支持bulk enqueue和dequeue。

这里其实是权衡了高优任务的平均等待时间与调度开销，在保证调度开销尽可能低的前提下高优任务尽可能先地被执行。队列容量越小，调度开销越大，但是高优任务的平均等待时间越低，所以需要把队列容量设置为一个合适的值。

需要修改执行流程，修改1和2：

1. 尝试轮询执行器队列，如果有节点元素，一次性全部取出

2. 遍历取出的所有节点，执行每个节点内的任务

需要修改调度流程，将3修改为：

3. 循环从大根堆中取出权重最大节点并交给空闲执行器，直到大根堆为空或不存在还有可用空间的执行器队列

流水线加速

这个和业务强相关，可以允许这次参数计算的图的计算完且不再被依赖的节点，计算下一次参数计算的任务。大幅扩大可用节点池，让执行器全程不闲下来。

比较敏感，由于保密原因不展开讲了

今天是2023年4月19日，还有两个月我就毕业了。北京邮电大学——虽然说不上是什么很好的学校，但至少二十年前在信息技术方向还是能干一干北大的哈哈（看看今天都什么样了）。以后就不读书辣！所以也想稍微总结一下自己读书的这些年。

关于为什么不读研：我左看右看前看后看都感觉国内的研究生实在没什么读的必要…反正读不读研对我职业发展都没啥影响，我对科研没啥兴趣，所以读三年研究生，能不能让我能力上一个新台阶，真的要打个问号，毕竟我大学四年教室都没进过几次（逃。

留学的话，一方面北美就业市场一坨屎，另一方面确实10043了，去不了心心念念的某🇺🇸大学，最后还有个原因就是👴被女人拐走啦！（全部准备好结果申请季不想润了）

去向的话，误打误撞进入了量化行业，身边都是世界上最聪明、学历最炸裂的一批人（北邮本科都称不上上过大学），薪资很高很高，管理扁平化，也没有互联网的那种浮躁与内卷。大概就是我的归宿了～最后在灵均infra实习转正与正定私募量开之间抉择了一下，选择了正定私募。

对行业有一定了解的同学一定会好奇，为什么不选择在灵均工作。头部百亿私募，顶级薪资待遇，超高的社招bar，多棒啊不是吗。主要是因为，另一边的岗位工作内容是从零开始搭建T0股票交易及回测系统，对于我，方才毕业，想深度进入量化行业的无基础本科生，我认为是更好的选择。灵均的话一方面是做infra，刚毕业就去量化做infra，我真的不知道是不是一个好的选择，毕竟做infra，互联网大厂才是历练的好选择不是吗？但是2023年的互联网更得打个问号了…

还有就是，正定那边带我这个组的leader是他们CTO——莫队，高中打信息竞赛刷洛谷的时候就经常听说，也算追星了吧（bushi。

言归正传，不聊将来了，聊聊过去。我个人经历还是比较有意思的，小时候一直在学美术，美术特长生考的初中，科技特长生（中考分数够了没占资格）考的高中，高中跑去打信息竞赛（打得很烂，学了俩月NOIP打了20分哈哈哈哈哈）和VEX机器人比赛，两年没上课，最后两学期从高二下期末朝阳区rank 600硬生生干到一模rank 30，参加了清华的领军计划，然后高考烂了（主要是语文烂了），去了北邮。

说真的我好喜欢我的初高中——北京市第八十中学。学校的氛围很开放，允许我高中两年不上课去做自己喜欢的事情，也为我提供了向各种方向发展的土壤。画堂春美术社，滑板社，迪恩卡门机器人社，承载了我太多太多的回忆。还记得高二每天早上七点到机器人社，晚上十点才回家，在社团狠狠敲一天代码，别的任何事情都不需要考虑，真的特别特别开心。我绝对是最开心的高中生。

总之不能算成功，也不能算失败，用精彩来评价我觉得是比较中肯的。这些经历给我带来最大的优势是，让我对新事物的观念比较open，愿意去挑战完全没有接触过的事情。当然也可能带来了一些缺点，比如不太愿意深钻进某一个细分领域。也许这也注定了我的归宿是startup公司，去做一些对技术广度与思维广度要求比较高的事情，而不是去大厂成为某方向的技术专家。

先写到这儿，有新想法再继续写😌～

在数据中心领域，远程直接内存访问（英語：remote direct memory access，RDMA）是一种绕过远程主机操作系统内核访问其内存中数据的技术，由于不经过操作系统，不仅节省了大量CPU资源，同样也提高了系统吞吐量、降低了系统的网络通信延迟，尤其适合在大规模并行计算机集群中有广泛应用。在基于NVMe over Fabric的数据中心中，RDMA可以配合高性能的NVMe SSD构建高性能、低延迟的存储网络。

从 DMA 到 RDMA

在理解 RDMA 之前，我们先要回顾一下 DMA。

DMA，直接内存访问，是电脑科学中的一种内存访问技术。它允许某些电脑内部的硬件子系统（电脑外设），可以独立地直接读写系统内存，而不需中央处理器（CPU）介入处理 。在同等程度的处理器负担下，DMA是一种快速的数据传送方式。很多硬件的系统会使用DMA，包含硬盘控制器、绘图显卡、网卡和声卡。

在 DMA 出现之前，读取 IO 设备的数据需要完全依赖 CPU，IO 设备在有数据可读的时候，会触发一个硬件中断，CPU 放下手头的工作，保存工作场景的上下文，进入中断处理程序，且 IO 设备占用总线，CPU 读取总线，中断处理完成后再恢复之前正在执行的任务的上下文。DMA 其实就是引入了一个 DMA 控制器，让 IO 设备经过控制器直接向内存写入数据，不需要让 CPU 处理中断，消除了 CPU 处理中断的开销，节约了 CPU 宝贵的时钟周期。

RDMA 顾名思义，是远程 DMA，但是 DMA 是 IO 设备访问内存，RDMA 的两个主要对象不再是通过总线相连，并且也不是 IO 设备。RDMA 是一台计算机访问另一台计算机的内存。

简单对比一下 DMA 与 RDMA 的过程。

• DMA：IO 设备 -> DMA 控制器 -> 内存
• RDMA：远端计算机某操作 -> 远端计算机网卡 -> 某网络 -> 本地计算机网卡 -> DMA 控制器 -> 内存

可以看出，可以把远端计算机到本机网卡一体化视作一台 IO 设备，再通过 DMA 的方式写入本机内存，不需要本机的 CPU 参与这个过程。

RDMA How to

RDMA 恰恰是 InfiniBand 的一个重要应用。

很明显，RDMA 的过程有网卡参与，并且这些网卡需要一些专用的控制逻辑，无法不依赖专用网卡就很轻松地实现。这时候就引入了 InfiniBand 架构。

Mellanox 提供了基于 IB 开源的 rdma 内核拓展 rdma-core，并且封装了各语言可用的库。可以使用该拓展实现基于 IB 的 RDMA 通讯。

下面会尝试基于 rdma-core 的 python 封装在 IB 网络上实现一个 RDMA demo。

InfiniBand 其实本质上就是一个协议栈，主要关注网络层、物理层与数据链路层，并且支持数种可靠性等级。InfiniBand 的最大特点是超高带宽，并且支持保证可靠且无损的传输。
如果对 OSI 七层模型比较了解，会发现 InfiniBand 和 OSI 七层模型的学习思路是一致的。InfiniBand 网络不是一种具体的网络。基于InfiniBand规范所搭建的网络均为 InfiniBand 网络，正如按照以太网规范建立的网络是以太网一样。这种架构规定了传输介质以及连接方式和传输规则（校验、包格式、错误检测等）。
但是与 OSI 七层模型不同，IB 主要将注意力集中在下三层（更多的精巧设计集中在下两层），提供了超高带宽和无损数据传输。
阅读 InfiniBand 的介绍可以发现，InfiniBand 其实是对传统网络架构的优化、创新与继承，特化了数据中心集群场景下的通讯功能，延用了很多传统网络架构的概念，而非颠覆性地引入信的概念。例如 MAC 、子网等概念的含义在 InfiniBand 架构中与传统架构中相同。
由于分层明确，提供了完整的服务原语，传统的上层协议依然可以运行在 IB 上（虽然可能需要一些 adapter），如 UDP、TCP与HTTP等上层协议。但是有一个问题是需要被关注的，IB 的下层协议已经确保了数据的无损传输，而传统的上层协议为了解决下层不可靠数据传输的问题，加入了大量对于基于 IB 的上层应用不必要的逻辑，无法释放 IB 的全部潜力。
为了解决这个问题，有一系列基于 IB 特性，为 IB 量身定制的一些协议，如 RDMA。

Django CORS 策略配置

CORS: Cross-origin resource sharing 跨域资源共享

比如不同域名或者不同端口，都会或多或少遇到CORS的情况，Django 默认是不允许 CORS 的，需要用模块去配置策略

比较主流的方案是使用 django-cors-headers 模块

安装 django-cors-headers 模块

pip install django-cors-headers

修改 settings.py

# 安装模块
INSTALLED_APPS = [
    ...
    'corsheaders',
    ...
]

#添加中间件
MIDDLEWARE = [
    ...
    'django.middleware.common.CommonMiddleware',
    'corsheaders.middleware.CorsMiddleware',
    # 我的配置下下面这个开了会403 还没研究 反正部署的时候记得去注释
    #'django.middleware.csrf.CsrfViewMiddleware',
    ...
]

配置 CORS 策略

django-cors-headers 模块提供了以下三个配置项

• ①CORS_ALLOWED_ORIGINS
• ②CORS_ALLOWED_ORIGIN_REGEXES
• ③CORS_ALLOW_ALL_ORIGINS

① 白名单

允许的来源，参考如下填写

CORS_ALLOWED_ORIGINS = [
    "https://example.com",
    "https://sub.example.com",
    "http://localhost:8080",
    "http://127.0.0.1:9000"
]

② 正则匹配来源

使用正则匹配来源 URI，匹配成功则允许 CORS，参考如下填写

CORS_ALLOWED_ORIGIN_REGEXES = [
    r"^https://\w+\.example\.com$",
]

③ 允许全部来源⭐

允许所有来源，生产环境千万不要开启，默认值为 False

开发环境可以打开，配置如下

CORS_ALLOW_ALL_ORIGINS = True # 这是开发环境 生产环境请填 False

1.Raw String: r’some content here’

string前面加‘r’， 告诉解释器这个string是个raw string，不要转义。 例如，\n 在raw string中，是两个字符，\和n， 而不会转意为换行符。由于正则表达式和 \ 会有冲突，因此，当一个字符串使用了正则表达式后，最好在前面加上’r’。

这就是为什么很多 Intellisense 会把加r的string标记成正则模式串

print(r'hello world\n')
# > hello world\n

2. Format String: f’some content here’

意为嵌套变量，格式化，比如

name = 'Jimmy'
f'Hello {name}!'
# > Hello Jimmy!

等价于

'Hello {name}!'.format(name='Jimmy')
# > Hello Jimmy!

前置知识 后端入门 Django 项目基础配置

本笔记默认读者已经对数据库有一定的认识

最少需要理解如何在数据库中建立一对一、一对多、多对多关系

本笔记建立在已经知晓并配置完数据库连接的前提下

本笔记中使用的数据库是 MySQL 8.0

使用pymysql模块连接数据库时，manage.py 在执行数据库相关指令时要求计算机shell中可以运行mysql指令

ORM 基础概念

简单了解 ORM

Object Relational Mapping 对象关系映射，简称ORM。

ORM通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。ORM在业务逻辑层和数据库层之间充当了桥梁的作用。

简单来说，以往我们操作数据库时使用的是 SQL 语句，但有了 ORM 后，我们操作数据库只需要操作在 ORM 框架下建立的数据模型对象，然后 ORM 替我们执行背后的 SQL 语句。符合我们面向对象编程的习惯，也有效防止了 SQL 注入攻击的发生。

ORM 对象和数据库结构的对应关系

这里以 Django 为例。

以下是我们大创数据库中的一个表的模型与设计。

class SiteAllPeriod(models.Model):
    periodid = models.AutoField(db_column='periodID', primary_key=True)
    week = models.IntegerField()
    siteperiodid = models.IntegerField(db_column='sitePeriodID')
    siteid = models.ForeignKey(Site, models.DO_NOTHING, db_column='siteID', related_name='%(class)s_siteid')
    sitename = models.ForeignKey(Site, models.DO_NOTHING, db_column='siteName', related_name='%(class)s_sitename')
    date = models.DateField()
    childsiteid = models.ForeignKey('SiteChild', models.DO_NOTHING, db_column='childSiteID', blank=True, null=True, related_name='%(class)s_childsiteid')
    childsitename = models.ForeignKey('SiteChild', models.DO_NOTHING, db_column='childSiteName', blank=True, null=True, related_name='%(class)s_childsitename')
    starttime = models.TimeField(db_column='startTime', blank=True, null=True)
    endtime = models.TimeField(db_column='endTime', blank=True, null=True)
    stateid = models.ForeignKey('SitePeriodState', models.DO_NOTHING, db_column='stateID', blank=True, null=True, related_name='%(class)s_stateid')
    prompt = models.CharField(max_length=50, blank=True, null=True)
    price = models.DecimalField(max_digits=10, decimal_places=2, blank=True, null=True)
    studentprice = models.DecimalField(db_column='studentPrice', max_digits=10, decimal_places=2, blank=True, null=True)
    staffprice = models.DecimalField(db_column='staffPrice', max_digits=10, decimal_places=2, blank=True, null=True)lowercase.
    orderusername = models.CharField(db_column='orderUserName', max_length=30, blank=True, null=True)
    orderuserpaymethod = models.CharField(db_column='orderUserPayMethod', max_length=30, blank=True, null=True)
    needsubcard = models.IntegerField(db_column='needSubcard', blank=True, null=True)
    teachingperiodname = models.CharField(db_column='teachingPeriodName', max_length=30, blank=True, null=True) 
    teacher = models.CharField(max_length=30, blank=True, null=True)

    class Meta:
        managed = False
        db_table = 'site_all_period'

可以看出来，Django 的 ORM 的模型中：

• 类对应某个特定的表
• 类的实例对应着一条记录
• 类的属性对应着表内的字段
• 类属性的类型对应着表内字段的类型
• 类属性类型构造时的参数与字段的参数一一对应
• 外键拥有特殊的类型
• 外键类型直接指向另一个 ORM 模型（如果另一个模型在本模型下方，需要用单引号包裹）

可见 ORM 的模型既能和数据库形成良好的对应关系、能体现出数据库不同表之间的对应关系。

【知识链接】👇

Django 官方文档 – ORM 中的模型

Django 官方文档 – ORM 中的字段

Django ORM 特性 — 反向查询

在上面的代码中可以发现，字段类型构造的参数中，有一个名为related_name的参数，它的作用是为 ORM 模型提供反向查询支持。

什么是反向查询

在关系型数据库中，我们使用常外键(Foreign Key)来实现关系，反向查询是使用外键寻找另一表中记录的反过程。

拿到一个记录后，反向查询可以获得使用外键指向该记录的其他表中的记录。

related_name 需要独一无二？

如果你将两个related_name设为相同值，你会发现框架无法正常启动。

这是因为，知道外键，你可以知道唯一的记录，但是可能有不同表的多个外键指向同一记录。如果存在相同的related_name，程序就无法知晓应该去哪一个表寻找外键了，就无法反向获得那些特定的记录。

在 Django 中配置 ORM 模型

创建一个 ORM 模型

为了偷懒容易理解，这里引入一个来自 Django 官方文档的样例

这个样例定义了一个 Person 模型，拥有 first_name 和 last_name:

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

first_name 和 last_name 是模型的 字段。每个字段都被指定为一个类属性，并且每个属性映射为一个数据库列。

上面的 Person 模型会创建一个如下的数据库表：

CREATE TABLE myapp_person (
    "id" serial NOT NULL PRIMARY KEY,
    "first_name" varchar(30) NOT NULL,
    "last_name" varchar(30) NOT NULL
);

若想详细了解各种字段，请移步Django 官方文档 – ORM 字段选项

使用新创建的模型

假设上面的模型位于myapp项目的models.py模块内

一旦你定义了你的模型，你需要告诉 Django 你准备 使用 这些模型。你需要修改设置文件中的 INSTALLED_APPS ，在这个设置中添加包含 models.py 文件的模块名称。

例如，若模型位于项目中的 myapp.models 模块（ 此包结构由 manage.py startapp 命令创建）， INSTALLED_APPS 应设置如下：

INSTALLED_APPS = [
    #...
    'myapp',
    #...
]

当你向 INSTALLED_APPS 添加新的应用后。

运行 manage.py migrate，你的模型会被自动映射到数据库中（新创建一个符合模型的表）

这时，数据库中就会出现一个名为 myapp_person 的表

使用 Meta 信息指定命名表

如果我想让上面的模型对应的表拥有自定义的表名呢？

答案是：定义 Meta 子类

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

    class Meta:
        db_table = 'person'

添加了该 Meta 子类后，使用manage.py migrate迁移完成，数据库中出现的表就名为 person 了。

元数据还有其他很多参数可选，具体请移步 模型可选参数参考

使用已有数据库自动建立 ORM 模型

• Django ORM 的另一强大之处在于它可以双向构造映射
• 创建了模型，可以生成表；同样的，设计了表，可以生成模型

首先，在settings.py配置数据库

完成后，运行指令

python manage.py dbshell

如果执行后，你进入了数据库的命令行，就说明配置成功了

python manage.py inspectdb > models.py

静待两分钟，没有任何输出，运行结束，则说明models.py生成成功

去根目录寻找models.py文件，放到喜欢的地方（？），就可以开始使用了。

在 Django 中使用 ORM 完成数据库操作

如果时间充裕，建议先去温习一下SQL，Django 的 ORM 使用了很多高级的 SQL 语句，拥有相关知识有助于理解 ORM 的运行否则就是玄学

下面会展示一些常用 SQL 语句的 ORM 对应

继续以笔记开头的第一个模型为例，为了方便观察，这里再贴一个拷贝

class SiteAllPeriod(models.Model):
    periodid = models.AutoField(db_column='periodID', primary_key=True)
    week = models.IntegerField()
    siteperiodid = models.IntegerField(db_column='sitePeriodID')
    siteid = models.ForeignKey(Site, models.DO_NOTHING, db_column='siteID', related_name='%(class)s_siteid')
    sitename = models.ForeignKey(Site, models.DO_NOTHING, db_column='siteName', related_name='%(class)s_sitename')
    date = models.DateField()
    childsiteid = models.ForeignKey('SiteChild', models.DO_NOTHING, db_column='childSiteID', blank=True, null=True, related_name='%(class)s_childsiteid')
    childsitename = models.ForeignKey('SiteChild', models.DO_NOTHING, db_column='childSiteName', blank=True, null=True, related_name='%(class)s_childsitename')
    starttime = models.TimeField(db_column='startTime', blank=True, null=True)
    endtime = models.TimeField(db_column='endTime', blank=True, null=True)
    stateid = models.ForeignKey('SitePeriodState', models.DO_NOTHING, db_column='stateID', blank=True, null=True, related_name='%(class)s_stateid')
    prompt = models.CharField(max_length=50, blank=True, null=True)
    price = models.DecimalField(max_digits=10, decimal_places=2, blank=True, null=True)
    studentprice = models.DecimalField(db_column='studentPrice', max_digits=10, decimal_places=2, blank=True, null=True)
    staffprice = models.DecimalField(db_column='staffPrice', max_digits=10, decimal_places=2, blank=True, null=True)lowercase.
    orderusername = models.CharField(db_column='orderUserName', max_length=30, blank=True, null=True)
    orderuserpaymethod = models.CharField(db_column='orderUserPayMethod', max_length=30, blank=True, null=True)
    needsubcard = models.IntegerField(db_column='needSubcard', blank=True, null=True)
    teachingperiodname = models.CharField(db_column='teachingPeriodName', max_length=30, blank=True, null=True) 
    teacher = models.CharField(max_length=30, blank=True, null=True)

    class Meta:
        managed = False
        db_table = 'site_all_period'

1. SELECT * FROM site_all_period

认真看本条！包含了一些讲解！

选择 site_all_period 中全部的记录

ORM中，使用以下语句获取记录

querySet = SiteAllPeriod.objects.all()

SQL 语句查询返回的是一个记录列表，而 ORM 查询的返回值是QuerySet，顾名思义，这是一个储存查询结果的集合。

了解 QuerySet

QuerySet和 Python 标准的 list 类型有些相似，使用时很多时候可以把它当作一个 list 来处理，比如可以使用for ... in ...遍历选择到的记录，或者使用下标访问index位置的记录（如果记录有序，这个的用处就比较大了）。

• 仅仅创建QuerySet不会触发数据库操作，只有在QuerySet被使用（读取具体内容）时，才会执行对应的 SQL 语句。

• QuerySet是可以迭代的，比如你可以使用records = SiteAllPeriod.objects.all().all().all().all().all()（逃）

  请牢记它可以被迭代，它的迭代特性可以用来组装一个复杂的 SQL 语句。看文档应该是会合并成单 SQL 语句，有待验证，好奇可以QQ联络我让我验证。

• QuerySet具有缓存功能，如果事先创建了QuerySet对象，那么对它进行遍历不会反复进行数据库操作，而是会对已有的QuerySet对象进行遍历。

  具体缓存机制请参阅 Django 官方文档 – ORM QuerySet 缓存机制

若想更全面的了解QuerySet，请阅读 Django 官方文档 – ORM 中的 QuerySet

2. SELECT * FROM site_all_period WHERE week=1

选择 site_all_period 中week=1的全部记录

ORM中，使用以下语句获取记录

querySet = SiteAllPeriod.objects.filter(week=1) # 使用参数名确定对象属性(字段)

TIP

假设你想要像2中选择week=1的记录那样，选择siteid=1的记录。为此你使用了如下语句，会怎么样？

querySet = SiteAllPeriod.objects.filter(siteid=1)

答案是无法正常运行，因为siteid是一个外键，你将它作为参数名称，ORM 会尝试去寻找外键对应的对象。

那如果确实想要获得siteid=1的记录呢？

请在该属性名称后方加上_id，使用如下语句：

querySet = SiteAllPeriod.objects.filter(siteid_id=1) # 外键属性+_id才能获取到字段的值

3. SELECT JOIN 连接查询/跨表查询

如果要实现对关系的处理，以往我们需要使用 JOIN SQL 语句来进行连接查询，Django 的 ORM 同样提供了极其简便的方式，即“双下划线”

题外话：这个笔记只能帮助读者对 ORM 建立一定的理解，鉴于这东西的复杂性，只能举一些例子，不可能完整呈现 ORM 的神奇功能，还是需要读者完整阅读文档。

比如上面的SiteAllPeriod，里面有一些外键，我们可以利用这些外键实现跨表查询

比如外键siteid，Site类型里面有个courtid字段，如果我们想选择SiteAllPeriod中(此处断句)所有外键siteid指向的Site对象的courtid字段为1的记录

这时需要使用语句

querySet = SiteAllPeriod.objects.filter(siteid__courtid_id=1)

这行语句的背后就是 SQL 的 JOIN 连接查询，Django 会帮你完成该语句的构造和执行。

4. 模型对象之间的访问

Django 的 ORM 模型还有个不错的地方就是：

siteAllPeriod_record = SiteAllPeriod.objects.filter(siteid_id=1).first() # 选择 siteid = 1 的记录，并拿取第一个（当然这种情况也只有一个）
courtid_of_this_period = siteAllPeriod_record.siteid.courtid_id
"""
siteid 是外键属性，访问该属性会直接返回对应的对象
这里可以直接获得 siteAllPeriod 归属的 site 对象的 courtid （site-siteAllPeriod 是个一对多关系）
注意，这样写看起来很美好，但是访问另一个表的记录对象，是会执行一次 SQL 语句的，性能损耗很大！
"""

5. 记录的保存

这个很容易，拿到对象，直接改属性，改完调用这个对象的save()方法就保存了

当然，对QuerySet也可以像上面那样干（python的对象默认都是引用，所以懂的都懂）

6. 记录的删除

和5一模一样，就是把save()换成delete()

结语

上面只提供了部分例子，也是我认为的入门最需要理解的例子。

如果想查看详细的样例与解释，请参阅 Django 官方文档 – ORM 执行查询

后端道阻且长，希望大家一起加油呀！