# xdclass **Repository Path**: xiang-qiankan/xdclass ## Basic Information - **Project Name**: xdclass - **Description**: No description available - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2023-12-01 - **Last Updated**: 2024-01-21 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README **redis中存放验证码的注意事项** 1、key规范:业务划分,冒号隔离 - ip隔离 - 浏览器指纹:User-agent。对User-agent做md5加密解决太长的问题 2、为什么注册账号要加验证码 - 防止api被刷 - 防止api被当肉机 **简介:注册邮箱验证码防刷方案你能想到几个** * 需求:一定时间内禁止重复发送邮件,大家想下有哪几种实现方式 * 方式一:前端增加校验倒计时,不到60秒按钮不给点击 * 简单 * 不安全,存在绕过的情况 * 方式二:增加Redis存储,发送的时候设置下额外的key,并且60秒后过期 * 非原子操作,存在不一致性 * 增加的额外的key - value存储,浪费空间 * ``` /** * 前置:判断是否重复发送 * * 1、存储验证码到缓存 * * 2、发送邮箱验证码 * * 后置:存储发送记录 **/ ``` * 方式三[选用]:基于原先的key拼装时间戳 * 好处:满足了当前节点内的原子性,也满足业务需求 * MQ + 本地消息表 * 好处:业务解藕 * 坏处:复杂性提高 **简介:分布式文件存储解决核心知识介绍和面试题** * 面试题:做分布式文件存储,主要是想实现文件存储访问的高性能与高可用,如何保证分布式存储的高性能与高可用? * 大家可以想到基本就是副本备份、双活、多活这种架构 * 在系统中通过复制协议将数据同步到多个存储节点,并确保多个副本之间的数据一致性,当某个存储节点出故障时,系统能够自动将服务切换到其他的副本 * 在分布式存储中高性能与高可用是矛盾的,比如要设计一个分布式存储系统,CAP定理也可以推断出来 * 对性能的考虑,记录数据时先写一个份数据到某个机器上并立即返回,然后异步发起多个数据备份过程。这种设计的性能最好,但存在“容错性”的风险,加入返回后,还没来得及同步给其它节点就宕机了,则数据就丢失(异步复制,也存在是写主节点到内存还是落到磁盘) * 如果同时写多个副本,每个副本写成功以后再返回,则又导致性能下降,这个过程取决于最慢的那台机器的性能 (同步多写,是同步每个副本节点还是一个副本先) * 那应该如何选择呢? * 根据业务而定,如果要求性能更高,偶尔出现文件丢失或访问出错则可以异步复制 * 要求文件系统一定要高可用,则用同步多写的策略,牺牲一定的性能也要保证高可用数据一致性 * 基于上述的,大家还知道有一个很类似的消息队列就是支持这种操作 * RocketMQ消息高可用里面的 * 同步双写、异步刷盘,即同时写到两个节点上的内存才返回,然后异步持久化到磁盘里面 **简介:高并发下账号唯一性安全保证方案** * 注册业务 * 同个时刻注册,需要保证账号在数据库里唯一 * 高并发下问题发现扩大 * 万分之一的时间,放大100万倍 * 不是你的代码安全,而是你的并发量过少,几个几十个并发量发现不了问题 * 几十万几百万并发 ,线下难模拟 * 代码暂停思维:假如非原子性代码运行到某一行暂停,其他线程重新操作是否会出问题 * 时间扩大思维:1纳秒的时间,扩大到1分钟,代码逻辑是否会有问题 * Redis:先看redis是否有,然后没的话则是新的注册 * key -value 存储, 配置60秒过期 * 非原子性操作,存在不一致 * 数据库唯一索引(建表的时间已经添加) ``` ALTER TABLE user ADD unique(`mail`) ``` **账号删除在新建一个同名账号,用户权限会不会继承?** - 用id进行关联