网关协议，表和字段的自定义命名，301与302状态码区别，jwt，全局唯一id生成(雪花算法)、函数与方法的区别

一、网关协议

CGI：

通用网关接口（Common Gateway Interface/CGI），可以让浏览器向服务器上的程序请求数据。

 CGI 是一种服务器和后端可执行程序之间的交互标准

优点

CGI 的优点也就是它的作用了。CGI 程序提供了很多静态网页无法实现的功能，比如加载数据、数据运算等等。早期的动态网页基本都是基于 CGI 实现的。

缺点

在 CGI 协议下，解析器的反复加载是性能低下的主要原因。每个发送到服务器的请求，都需要经过『启动进程、处理请求、结束进程』三个步骤，所以当访问量增大时，系统资源的开销也会增大，导致服务器性能下降甚至服务中断。

 FastCGI：

快速通用网关接口（Fast Common Gateway Interface／FastCGI）是一种让交互程序与Web服务器通信的协议。FastCGI是早期通用网关接口（CGI）的增强版本。
FastCGI致力于减少网页服务器与CGI程序之间互动的开销，从而使服务器可以同时处理更多的网页请求。

优点

除了继承 CGI 原有的优点之外， FastCGI 还有以下特点：

• 业务分离：FastCGI 后端和 Web Server 运行在不同的进程中，后端的故障不会导致 Web Server 停止服务。
• 分布式计算：由于 FastCGI 服务器是可以独立运行的，所以 FastCGI 程序可以在服务器以外的主机上执行，并且接受来自其它服务器的请求。
• 多个可扩展角色：在 FastCGI 中，程序被赋予明确的角色，例如响应器角色、认证器角色、过滤器角色等等。

WSGI：

Web服务器网关接口（Python Web Server Gateway Interface，缩写为WSGI）是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。自从WSGI被开发出来以后，许多其它语言中也出现了类似接口。 

WSGI 中存在两种角色：接受请求的 Server 和处理请求的 Application，它们底层是通过 FastCGI 沟通的。

uWSGI：

一个Web Server，即一个实现了WSGI的服务器，大体和Apache是一个类型的东西，处理发来的请求。 

uwsgi：

 uWSGI自有的一个协议 ，用于定义传输信息的类型。

 三、状态码301和302的区别

301：永久重定向

301比较常用的场景是使用域名跳转。

　　比如，我们访问 http://www.baidu.com 会跳转到 https://www.baidu.com，发送请求之后，就会返回301状态码，然后返回一个location，提示新的地址，浏览器就会拿着这个新的地址去访问。 

　　注意： 301请求是可以缓存的， 即通过看status code，可以发现后面写着from cache。

302：临时重定向

        比如未登陆的用户访问用户中心重定向到登录页面。

        访问404页面会重新定向到首页。

区别：

302重定向只是暂时的重定向，搜索引擎会抓取新的内容而保留旧的地址，因为服务器返回302，所以，搜索搜索引擎认为新的网址是暂时的。

而301重定向是永久的重定向，搜索引擎在抓取新的内容的同时也将旧的网址替换为了重定向之后的网址。

nginx配置：

rewrite后面接上permenent就代表301跳

rewrite后面接上redirect就代表302跳

四、layui：经典模块化前端框架

https://www.layui.com/ 

五、不同程序可以使用同一个数据库。

六、django如何自定义表名？

我们知道，django在创建表时，数据库中的表名会自动加一个应用名作为前缀（app01_user），那么如何自定义呢？

在meta 类中指定表名，在字段中通过db_column指定列名
如下所示：

class Record(models.Model):
    content=models.CharField(max_length=32,db_column='record_content')
    class Meta:
        db_table="Record"

 七、DG软件（DATAGRIP）

jetbrains旗下数据库连接软件（类似navicat）

同旗下ide：idea    pycharm 

八、什么是jwt

参考：https://www.cnblogs.com/cjsblog/p/9277677.html 

jwt（json  web  token）

Json web token（JWT）是为了网络应用环境间传递声明而执行的一种基于JSON的开发标准（RFC 7519），该token被设计为紧凑且安全的，特别适用于分布式站点的单点登陆（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：

• Header
• Payload
• Signature

九、django 中OneToOneField继承了Foreignkey，但其本质就是Foreignkey设置了一个unique=True。

十、CommonMiddleware中间件

django中请求路径带斜杠和不带斜杠

基于APPEND_SLASH和PREPEND_WWW的设置来重写URL。

如果APPEND_SLASH设为True，并且初始URL 没有以斜线结尾以及在URLconf 中没找到对应定义，这时形成一个斜线结尾的新URL。如果这个新的URL存在于URLconf，那么Django 重定向请求到这个新URL上。否则，按正常情况处理初始的URL。

比如，如果你没有为foo.com/bar定义有效的正则，但是为foo.com/bar/定义了有效的正则，foo.com/bar将会被重定向到foo.com/bar/。

十一、全局唯一id生成 

雪花算法：

分布式系统中，有一些需要使用全局唯一ID的场景，这种时候为了防止ID冲突可以使用36位的UUID，但是UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。

SnowFlake算法生成id的结果是一个64bit大小的整数，它的结构如下图：

• 1位，不用。二进制中最高位为1的都是负数，但是我们生成的id一般都使用整数，所以这个最高位固定是0

• 41位，用来记录时间戳（毫秒）。

  • 41位可以表示$2^{41}-1$个数字，
  • 如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0 至 $2^{41}-1$，减1是因为可表示的数值范围是从0开始算的，而不是1。
  • 也就是说41位可以表示$2^{41}-1$个毫秒的值，转化成单位年则是$(2^{41}-1) / (1000 * 60 * 60 * 24 * 365) = 69$年

• 10位，用来记录工作机器id。

  • 可以部署在$2^{10} = 1024$个节点，包括5位datacenterId和5位workerId
  • 5位（bit）可以表示的最大正整数是$2^{5}-1 = 31$，即可以用0、1、2、3、....31这32个数字，来表示不同的datecenterId或workerId

• 12位，序列号，用来记录同毫秒内产生的不同id。

  • 12位（bit）可以表示的最大正整数是$2^{12}-1 = 4095$，即可以用0、1、2、3、....4094这4095个数字，来表示同一机器同一时间截（毫秒)内产生的4095个ID序号

SnowFlake可以保证：

• 所有生成的id按时间趋势递增
• 整个分布式系统内不会产生重复id（因为有datacenterId和workerId来做区分）

十二、数据库相关

1.  基于对象的跨表查询是子查询；基于双下划线的跨表查询是联表查询
2. left join是左边表有的全保存，右边表的没有的就给null
3. right join是右边表有的全保存，左边表没有的给null
4. inner join是保存两个表共有的字段
5. full join是两个表的所有字段都保存，两边没有的对应给null

十三、函数与方法的区别

•  函数理论上不与其他东西有关系，若是有参函数只需要相关的参数即可运行；
• 方法一般与对象或类绑定；
• 定义在类中的函数如果没有特殊的装饰就是对象方法，如果有@classmethod装饰就是类方法，如果有@static装饰就是静态方法；
• 类调用对象方法时，其实就相当于函数了
•