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

项目是一个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这个扩展,通过设置白名单的方式指明可以访问后端的域名。

 

Logo

前往低代码交流专区

更多推荐