未来会出现人工智能化的教育方式吗？

如果非要写一个过程的话：

• 当用户首次注册的时候，系统随机生成salt，然后和密码按照规则拼接成一个字符串，然后求散列值，并存储在pwd列中
• 客户端请求登陆接口，上传用户的账号和密码，这里的密码推荐md5的摘要(js也可以生成md5)
• 服务端接收到请求，根据用户的账号查询对应的salt
• 把上传的密码和salt根据规则拼接，然后生成摘要
• 把上一步生成的摘要和数据库的pwd进行对比，相同则登录成功，不同则登录失败

为什么非要加入salt呢?有了salt不仅可以加大黑客破解的难度，而且同样密码的用户存储的pwd列也不相同，在用户信息安全性上又提高了一点。

验证码

验证码是一种比较廉价的但是很有效的防止别人乱搞的手段，它通过一种只有真人才能识别的防伪手段来阻止危险。
 

“据说，这篇也是快餐，完全符合年轻人口味

说到登录，无人不知无人不晓。每一个有用户体系的相关系统都会有登录的入口，登录是为了确认操作人的正确性。说到登录安全，其实是一个很伟大的命题，不过常用的手段也不过尔尔。

避免明文

这个设计到用户凭证信息的表设计，切记避免明文存储用户的密码信息。还记得以前很多大厂的密码泄露事件吗?

在数据表的设计中，除了用户密码的摘要列之外，需要添加所谓的“salt”列，其实是随机生成的一个字符串，用于和用户密码的摘要联合生成最终的摘要。
 

使用压缩列表，如果查找定位表头元素，我们只需要使用压缩列表起始地址加上表头三个字段长度就可以直接点位，查找非常快，复杂度是 O(1)。

而压缩列表的最后一个元素，查找起来也非常轻松，我们使用压缩列表起始地址加上zltail包含的长度就可以直接点位，查找也非常快，复杂度是 O(1)。

至于列表中的其他元素，就没有这么好运了，我们只能从第一个元素或者最后一个元素，遍历列表查找，此时的复杂度就是 O(N) 了。

另外压缩列表的新增、删除元素，都将会导致重新分配内存，效率不高，平均复杂度为 O(N)，最坏福复杂度为 O(N^2)。

编码转换

当我们创建一个 Redis 列表键，如果同时满足以下两个条件，列表对象将会使用压缩列表作为底层数据结构

列表对象保存的所有字符串元素的长度都小于 64 字节

列表对象中保存的元素数量小于 512 个

如果不能同时满足这两个条件，那么默认将会使用双向列表作为底层数据结构。

小结

Redis 列表底层使用两种数据结构，压缩列表与双向链表。

压缩列表由于使用了连续内存块，内存占用少，并且内存利用率高，但是新增、删除由于涉及重新分配内存，效率不高。

双向列表呢，新增、删除元素非常方便，但是由于每个节点都是独立的内存快，内存占用比较高，且内存碎片化严重。

这两种数据结构在表头/表尾插入与删除元素，都十分高效。但是其他操作，可能就效率较低。

所以我们使用 Redis 列表，一定要因地制宜，可以将其当做 FIFO 队列，这样仅使用 POP/PUSH ，效率将会很高。

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!