一个完整的网站里的用户注册流程，大概是
- 用户名（邮箱）
- 密码
- 确认密码
- 电话号码
- 验证码
这几天把用户注册重新梳理了一遍，用到了挺多东西的
注册页面前端（vue）
data（数据）
这次我用的是vue来做的前端框架，虽然不是前端程序员，但是可以大概的使用vue来写一点简单的逻辑了。
首先先大概说说vue，对于后端来说，大概懂怎么用就好了，首先第一步就是创建 VUE 实例，在HTML骨架中要先定义一个盒子，比如定义一个
<script type="text/javascript">
var app = new Vue({
el: '#app',
data: {
message: 'Hello Vue!'
}
})
</script>
data里面的“hello Vue”可以理解为，通过data，绑定了message这个标签，并将标签的值变为 “hello Vue” ， 于是就页面就可以渲染出来了
method（事件）
这个就很好理解了，method里面放的就是函数，比如你在html里面给一个标签定义了一个点击事件，就可以把点击事件写在事件里面，这个就很好理解。
还有一个生命周期mounted，这个用处目前不大，就不多赘述。
JS逻辑部分（ajax）
通过ajax请求来局部刷新是注册的核心部分，没有ajax用户体验会极差，所以这一部分很重要。VUE的文档里是建议通过axios来进行ajax请求，所以在html中要导一个axios的包。
基本语法
axios.get(url, {
responseType: 'json'
})
.then(()=>{})
.catch(()=>{})
用axios发送ajax请求也挺简单的，发送一个get请求，这个url最好在前面先声明一个URL变量，把地址放在这里，这样写的也比较干净一点。
基本逻辑
我们通过v-model先把 用户名，密码，确认密码等标签全部拿过来可以用‘ ’的空字符接着，当用户输入了以后，我们里面的变量就有了值，有了以后，我们就可以进行基本的前端逻辑判断，比如用正则来规范密码，确认两个密码是否一致，手机号码，用户名是否规范之类的简单操作，当然，这里的前端不会涉及到后端的一些数据库操作，所以，当我们需要进行一些和数据库之间的对比时，就像看看用户名是否注册，手机号是否被注册之类的操作，就需要在view里面进行了。
图形验证码
前端
图形验证码是注册逻辑中很重要的一环，我们在前端可以做到展示图片验证码，但是校验图片验证码是否正确就要给到后端来处理了，在发送ajax请求之前，前端还需要生成一个uuid，这就个uuid的生成可以百度，里面有现成的函数，直接拿来用就好了。uuid就像是一个图形验证码的ID，一个图形验证码对应一个uuid，我们我在前端生成一个uuid，然后发送给后端，后端调用相关函数，生成一个图片验证码，并和这个uuid一起存进redis数据库里，当然我们会设定过期事件。
后端
我们后端的逻辑也很简单，最主要的需求就是先从前端接到一个uuid，生成一个图片验证码，然后实例化一个redis对象，我们通过这个对象将生成的图片验证码和uuid保存，并且返回给前端，当前端的验证完成，后端在这一步并不会验证图形验证码是否正确，验证图形验证码这一步是放在发送短信这一步的。所以在焦点离开图形验证码这个输入框的时候并不会显示你的验证码对了没有，只会显示看你输入的位数是不是设定的位数，比如四位的图形验证码，你写了五位，就会报错，这其实是前端的工作。
短信验证码
这次用的是容联云的短信验证码服务，容联云是一个发送短信的平台，其他的还有阿里云，腾讯云之类，都差不多。这里前端其实没有什么活，主要就是再次验证一下，看看手机号有没有问题，图形验证码的位数对了没有，看看前面的用户名什么的有没有问题，如果都没有问题，就可以向后端发送请求了。
后端
这里主要就是用了容联云的接口，从官网上直接下载下来就好了。调用接口其实也很简单，就是调用函数而已。在图形验证码那一部分说过了，我们要在发送短信验证码这一个视图里校验一下看看图片验证码有没有问题，验证的步骤跟存进去的步骤差不多，首先就是实例redis对象，通过这个对象来进行对数据库的操作，可以把它想象成Django程序和redis数据库的桥梁，我们实例了redis对象，在用uuid对存在里面的数据进行操作，我们可以验证了。具体的过程大概是这样：
- 接收参数
- 校验参数（看看收到的数据是否为空）
- 实例对象
- 提取验证码
- 删除验证码
- 对比
成功了就可以发送验证码了，错误的话就返回json数据回去。
优化
我们在验证图片验证码的时候还要验证一下一下这个人的手机号，避免被同一个人恶意注册，所以我们要往redis里面发送两次请求，redis数据库是c/s结构的，所以问题就来了，如果网络一旦卡了，这时我们要发送的两条请求就会卡住，严重点可能就会蹦了。所以这时后我们就要用到管道了，用pipeline管道可以在一个请求里面放多条命令，这就解决了问题。
异步方案
我们在发送完短信的时候，会响应一个结果，就是倒计时60秒，但是我们会遇到问题，就是必须要先发送短信，发完了以后才会倒计时，这时候就会有一个延迟的问题，万一网络卡一点，这个延迟问题就很大了，这时候我们肯定能想到多任务，什么multiprocessing什么的，多进程，多线程，我们当然可以这么做，但是这时候出现了一个新的东西：celery，这个celery，封装了一个生产者消费者模型，这是什么呢，就打比方你妈给你煮饺子，一次煮一个，煮完你就吃，这个没问题吧。但是如果她一次煮十个，你总不能一口吃十个吧，这时候你就可以拿一个盘子接着。这就是生产者消费者模型。我们用celery可以异步，开启celery服务，默认可以一次开8个进程来处理问题。
这就是Django里的用户注册逻辑了
日拱一卒，功不唐捐
完
