项目重要技术点介绍项目简介

项目是一个B2C模式的电商网站，采用的是前后端分离开发模式。前端主要使用vue.js开发，后端则主要使用DRF框架。

celery

Celery是一个简单、灵活且可靠的，处理大量消息的分布式系统

专注于实时处理的异步任务队列

同时也支持任务调度

Celery架构

    Celery的架构由三部分组成，消息中间件（message broker），任务执行单元（worker）和任务执行结果存储（task result store）组成。

celery是一个专注于实时处理和任务调度的分布式任务队列。本质上来说就是通过提前创建的进程调用函数来实现异步的任务。它有三个比较重要的组成部分：任务发出者，中间人和任务执行者。任务发出者通过 .delay()来发出指令，发出的指令好像排队一样按先后顺序在中间人的地方进行排列，而任务执行者则是实时的检测中间人中的任务指令，一有任务，立马调用封装的函数进行处理。

它有很多的优点，比如任务执行者可以单独的创建在其他的电脑上，这样的分布式也可以一定程度上缓解服务器的压力；异步执行任务，减少等待时间，提高效率等等。

    在项目中一共有三个地方用到了celery异步任务。分别是发送短信验证码、发送验证邮件以及生成详情页面。下面拿发送短信验证码的例子来简单的说一下celery。

传统的发送短信的方法是客户端向服务器请求短信验证码，服务器再向云通讯发送请求，让其帮我们发送短信，但是有一个很大的问题，就是每一步请求都是需要等待响应的，如果网络较差，服务器迟迟得不到响应，那么客户端也得不到响应，最直观的现象就是用户点击了发送短信验证码后，没有任何反应。为了解决这一问题，我们使用了celery异步发送短信，减少了等待的时间。使用之后过程就变成了用户点击发送短信验证码按钮，服务器向中间人的任务队列中添加一条任务，立马向客户端返回响应，客户端开始倒计时。celery的任务执行者调用发送短信的任务函数，使用云通讯给指定的手机号发送短信验证码。

jwt

1.JWT使用的过程中服务器端保存了什么，客户端保存了什么？

答：服务器端保存的是SECRET私钥；客户端保存的是服务器加密后的jwt token。

2.JWT的校验过程？

答：客户端发起请求的时候，传递给服务器一个jwt token，jwt token分为三部分：头部(header)、载荷(payload)和签证(signature)。服务器在收到这个token的时候将前两部分header和payload使用header中的加密算法HMACSHA256进行加盐SECRET组合加密，然后将生成的签名信息与jwt token中的第三部分signature进行对比，如果一致，说明token合法，否则就是伪造的。因为生成签名信息的SECRET只有服务器知道，所以相对来说很安全。

3.JWT中是如何加密的，安全吗？

答：JWT中header、payload都是由base64加密的，而base64是对称加密解密的过程，不安全，详细内容介绍见5。signature部分则是将上面加密过的头部和载荷利用头部中声明的加密方式(HMACSHA256)进行加盐 secret组合加密，这样一来三部分组合而成的JWT就相对安全了。因为万事没有绝对，只能是相对的安全。

注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

4.token中可以存放敏感的信息吗？

答：不可以，前面已经提到了，token的header和payload是经过base64加密的，而base64是对称加密，并不安全，因此不建议存放敏感信息。

5.为什么使用jwt认证机制？

答：在美多商城项目中，jwt token认证机制是对session认证机制的替代，基于之前的session认证机制，存在很多问题。比如，session信息存储在服务器端，如果登录用户过多，会占用过多服务器的空间；session依赖于cookie，session信息的标识保存在cookie中，如果cookie被截获，可能会造成 CSRF(跨站请求伪造攻击)；session认证不适合的分布式站点的应用场景。

6.jwt认证机制？

答：对于jwt token的认证机制，在用户登录时，服务器会签发( 生成)一个jwt token字符串。然后服务器在响应时将jwt token数据返回给客户端，客户端需保存jwt token数据。之后客户端在请求服务器时，如果需要进行用户的认证，需要将jwt token数据通过请求头传递给服务器，服务器会核验jwt token数据的有效性。

ES

    ES是java语言实现的一个开源的搜索引擎，很火，一般我们首选ES搜索。它的原理就是先建立索引结构数据，类似于咱们新华字典的前面索引表。在通过搜索引擎查询的时候，和咱们查字典一样，先通过拆分关键字的方式查一下这个数据在哪，然后直接就找到了。

我们使用haystack全文检索框架，它是python中的全文搜索框架，支持多种搜索引擎，能帮助开发者利用搜索引擎建立数据表的索引数据。能帮助开发者利用搜索引擎进行关键词搜索，获取对应的索引数据。还能利用索引数据查找到对应数据表的数据。也就是它什么都有了，你直接使用就好了。

在美多商城项目中，使用Docker搭建es搜索引擎服务器并使用haystack对接es搜索引擎来实现商品的搜索功能。

redis

    redis数据库是非关系型数据库，将数据存储在缓存中，读取速度快是其最大的优点。在Django中需要引入第三方扩展django-redis来使用。redis适用于存储使用频繁的数据，这样减少访问数据库的次数，提高了运行效率。它又五种数据类型列表、字符串、哈希hash、无序集合set和有序集合zset。详细的操作流程点击链接『redis操作命令总结』

在购物车记录存储的时后用到了redis，因为如果存储在mysql中，用户频繁的操作购物车的记录(删除或这添加)，就需要频繁操作mysql数据库。在redis中存储登录用户的购物车记录。读写效率要快很多。每个登录用户的购物车数据采用两条数据保存。其hash用于保存用户购物车记录中添加的商品id和对应数量；set用于保存用户购物车记录勾选状态(保存勾选商品id)。

浏览记录的保存的时候也用到了redis。采用的是列表数据类型。因为字符串和hash存储的时候需要额外的字符串操作，而列表直接可以存储，然后直接取值。zset需要额外的权重值来保证有序，而列表不需要。

nginx

    Nginx相当于一个中转站，它的并发处理能力十分强劲，可以将客户端的请求转发给业务服务器，也可以将业务服务器的响应返回给客户端。我们在Nginx中设置了两台服务器，一台是静态文件服务器，一台是提供后端API服务器入口的服务器。

1.静态文件服务器用来向客户端提供静态文件。静态文件服务器在处理xadmin站点和富文本CKEditor的请求时，会报错。因为这两个接口是由业务服务器处理的，解决的办法就是修改静态文件服务器的配置文件，让其转发给业务服务器。

2.在Nginx中的另一台服务器，是后端API服务器的入口，向业务服务器转发请求，实现负载均衡。这台服务器收到请求后向业务服务器进行转发，默认的形式是轮流转发。

跨域请求

    对于两个url地址，如果协议，ip和port完整一致，这样的地址就是同源地址，否则就是不同源地址。客户端发出请求时，如果源请求地址和被请求地址不是同源，这个请求就是跨域请求。而浏览器在发起ajax跨域请求时，会有CORS跨域请求的限制。在发起跨域请求时，在请求中携带一个请求头Origin（源请求地址）。被请求的服务器在返回响应时，如果允许源地址对其进行跨域请求，需要中响应时携带一个响应头Access-Control-Allow-Origin（源请求地址），要是没有响应头，直接就报错，将请求驳回，概不受理。

在我们的项目中使用了django-cors-headers这个扩展，通过设置白名单的方式指明可以访问后端的域名。

项目重要技术点介绍项目简介

项目是一个B2C模式的电商网站，采用的是前后端分离开发模式。前端主要使用vue.js开发，后端则主要使用DRF框架。

celery

Celery是一个简单、灵活且可靠的，处理大量消息的分布式系统

专注于实时处理的异步任务队列

同时也支持任务调度

Celery架构

    Celery的架构由三部分组成，消息中间件（message broker），任务执行单元（worker）和任务执行结果存储（task result store）组成。

celery是一个专注于实时处理和任务调度的分布式任务队列。本质上来说就是通过提前创建的进程调用函数来实现异步的任务。它有三个比较重要的组成部分：任务发出者，中间人和任务执行者。任务发出者通过 .delay()来发出指令，发出的指令好像排队一样按先后顺序在中间人的地方进行排列，而任务执行者则是实时的检测中间人中的任务指令，一有任务，立马调用封装的函数进行处理。

它有很多的优点，比如任务执行者可以单独的创建在其他的电脑上，这样的分布式也可以一定程度上缓解服务器的压力；异步执行任务，减少等待时间，提高效率等等。

    在项目中一共有三个地方用到了celery异步任务。分别是发送短信验证码、发送验证邮件以及生成详情页面。下面拿发送短信验证码的例子来简单的说一下celery。

传统的发送短信的方法是客户端向服务器请求短信验证码，服务器再向云通讯发送请求，让其帮我们发送短信，但是有一个很大的问题，就是每一步请求都是需要等待响应的，如果网络较差，服务器迟迟得不到响应，那么客户端也得不到响应，最直观的现象就是用户点击了发送短信验证码后，没有任何反应。为了解决这一问题，我们使用了celery异步发送短信，减少了等待的时间。使用之后过程就变成了用户点击发送短信验证码按钮，服务器向中间人的任务队列中添加一条任务，立马向客户端返回响应，客户端开始倒计时。celery的任务执行者调用发送短信的任务函数，使用云通讯给指定的手机号发送短信验证码。

jwt

1.JWT使用的过程中服务器端保存了什么，客户端保存了什么？

答：服务器端保存的是SECRET私钥；客户端保存的是服务器加密后的jwt token。

2.JWT的校验过程？

答：客户端发起请求的时候，传递给服务器一个jwt token，jwt token分为三部分：头部(header)、载荷(payload)和签证(signature)。服务器在收到这个token的时候将前两部分header和payload使用header中的加密算法HMACSHA256进行加盐SECRET组合加密，然后将生成的签名信息与jwt token中的第三部分signature进行对比，如果一致，说明token合法，否则就是伪造的。因为生成签名信息的SECRET只有服务器知道，所以相对来说很安全。

3.JWT中是如何加密的，安全吗？

答：JWT中header、payload都是由base64加密的，而base64是对称加密解密的过程，不安全，详细内容介绍见5。signature部分则是将上面加密过的头部和载荷利用头部中声明的加密方式(HMACSHA256)进行加盐 secret组合加密，这样一来三部分组合而成的JWT就相对安全了。因为万事没有绝对，只能是相对的安全。

注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

4.token中可以存放敏感的信息吗？

答：不可以，前面已经提到了，token的header和payload是经过base64加密的，而base64是对称加密，并不安全，因此不建议存放敏感信息。

5.为什么使用jwt认证机制？

答：在美多商城项目中，jwt token认证机制是对session认证机制的替代，基于之前的session认证机制，存在很多问题。比如，session信息存储在服务器端，如果登录用户过多，会占用过多服务器的空间；session依赖于cookie，session信息的标识保存在cookie中，如果cookie被截获，可能会造成 CSRF(跨站请求伪造攻击)；session认证不适合的分布式站点的应用场景。

6.jwt认证机制？

答：对于jwt token的认证机制，在用户登录时，服务器会签发( 生成)一个jwt token字符串。然后服务器在响应时将jwt token数据返回给客户端，客户端需保存jwt token数据。之后客户端在请求服务器时，如果需要进行用户的认证，需要将jwt token数据通过请求头传递给服务器，服务器会核验jwt token数据的有效性。

ES

    ES是java语言实现的一个开源的搜索引擎，很火，一般我们首选ES搜索。它的原理就是先建立索引结构数据，类似于咱们新华字典的前面索引表。在通过搜索引擎查询的时候，和咱们查字典一样，先通过拆分关键字的方式查一下这个数据在哪，然后直接就找到了。

我们使用haystack全文检索框架，它是python中的全文搜索框架，支持多种搜索引擎，能帮助开发者利用搜索引擎建立数据表的索引数据。能帮助开发者利用搜索引擎进行关键词搜索，获取对应的索引数据。还能利用索引数据查找到对应数据表的数据。也就是它什么都有了，你直接使用就好了。

在美多商城项目中，使用Docker搭建es搜索引擎服务器并使用haystack对接es搜索引擎来实现商品的搜索功能。

redis

    redis数据库是非关系型数据库，将数据存储在缓存中，读取速度快是其最大的优点。在Django中需要引入第三方扩展django-redis来使用。redis适用于存储使用频繁的数据，这样减少访问数据库的次数，提高了运行效率。它又五种数据类型列表、字符串、哈希hash、无序集合set和有序集合zset。详细的操作流程点击链接『redis操作命令总结』

在购物车记录存储的时后用到了redis，因为如果存储在mysql中，用户频繁的操作购物车的记录(删除或这添加)，就需要频繁操作mysql数据库。在redis中存储登录用户的购物车记录。读写效率要快很多。每个登录用户的购物车数据采用两条数据保存。其hash用于保存用户购物车记录中添加的商品id和对应数量；set用于保存用户购物车记录勾选状态(保存勾选商品id)。

浏览记录的保存的时候也用到了redis。采用的是列表数据类型。因为字符串和hash存储的时候需要额外的字符串操作，而列表直接可以存储，然后直接取值。zset需要额外的权重值来保证有序，而列表不需要。

nginx

    Nginx相当于一个中转站，它的并发处理能力十分强劲，可以将客户端的请求转发给业务服务器，也可以将业务服务器的响应返回给客户端。我们在Nginx中设置了两台服务器，一台是静态文件服务器，一台是提供后端API服务器入口的服务器。

1.静态文件服务器用来向客户端提供静态文件。静态文件服务器在处理xadmin站点和富文本CKEditor的请求时，会报错。因为这两个接口是由业务服务器处理的，解决的办法就是修改静态文件服务器的配置文件，让其转发给业务服务器。

2.在Nginx中的另一台服务器，是后端API服务器的入口，向业务服务器转发请求，实现负载均衡。这台服务器收到请求后向业务服务器进行转发，默认的形式是轮流转发。

跨域请求

    对于两个url地址，如果协议，ip和port完整一致，这样的地址就是同源地址，否则就是不同源地址。客户端发出请求时，如果源请求地址和被请求地址不是同源，这个请求就是跨域请求。而浏览器在发起ajax跨域请求时，会有CORS跨域请求的限制。在发起跨域请求时，在请求中携带一个请求头Origin（源请求地址）。被请求的服务器在返回响应时，如果允许源地址对其进行跨域请求，需要中响应时携带一个响应头Access-Control-Allow-Origin（源请求地址），要是没有响应头，直接就报错，将请求驳回，概不受理。

在我们的项目中使用了django-cors-headers这个扩展，通过设置白名单的方式指明可以访问后端的域名。