wordpress新浪微博图床插件,邯郸seo优化,有色建设网站,白嫖域名的申请地址项目开发模式 在预测未来之前#xff0c;首先分析一下程序员的日常工作中遇到哪些困难与挑战。 需求和设计 在需求沟通阶段#xff0c;程序员需要准确的获取PRD上的需求信息#xff0c;并对业务的价值和发展有一定的预判。根据以上的信息进行技术选型#xff0c;数据建模首先分析一下程序员的日常工作中遇到哪些困难与挑战。 需求和设计 在需求沟通阶段程序员需要准确的获取PRD上的需求信息并对业务的价值和发展有一定的预判。根据以上的信息进行技术选型数据建模设计抽象。在这个过程中主要的挑战有 高效的需求沟通 合理的技术方案选择 对现实世界的逻辑抽象 开发和测试 在编码和测试阶段程序员需要选择适合的数据结构并编写算法合理的运用设计模式高效的实现功能并且保证尽可能少的存在bug。在这个过程中主要的挑战有 高效的编码 避免语言的陷阱 尽量少的bug 代码有可读性和机器执行效率 部署和运维 在部署和运维阶段涉及到测试环境和生产环境2个方面程序员分别需要在测试环境和生产环境部署代码和定位问题。在这个过程中主要的挑战有 方便的提供多套隔离的测试环境 方便的在多集群多机器的生产环境部署和回滚代码 方便的部署和升级基础设施(例如mysql) 生产环境和测试环境的一致 生产环境可以弹性伸缩 有工具能辅助发现定位问题 系统内部 系统内部的主要挑战来自代码腐烂和功能复用2个方面。 代码腐烂如何在系统复杂度不断增加几千几万次迭代之后依然可以高效的进行功能开发而不是系统变成谁都不敢动的层层叠开发效率越来越慢。 功能复用代码和系统的复用往往意味着更高的开发效率更少的系统风险一次修改就可以解决问题而不是满世界的查找相同功能的代码进行修改。 系统外部 系统外部的主要挑战来自高并发高并发带来3个问题抗压竞态条件热点数据 抗压 高并发意味着系统需要支撑更高的吞吐量如果存在比较严重的性能瓶颈往往导致服务的不可用无状态的节点可以比较容易的水平扩展有状态的节点通常会成为系统的瓶颈。比较常见的解决方案是分库分表缓存但是同样带来开发难度提升数据不一致数据迁移等问题。 竞态条件 高并发也会导致小概率的竞态条件不断出现导致不能得到正确的结果。例如cache aside模式中读缓存为空并且DB读耗时DB写耗时会导致缓存脏数据问题。 热点数据 高并发在秒杀等场景中也会导致热点数据问题在DB中会导致严重的锁冲突性能急剧下降在cache中会导致缓存穿透击穿雪崩等问题。 业务约束 不同业务的特点也会带来不一样的挑战例如很多金融业务会要求强一致而非最终一致计费等业务的错误容忍度也远低于社区微博突发热点话题的业务特点也会带来更大的技术挑战。 微服务相关 微服务https://www.jianshu.com/p/7293b148028f es与mysql同步https://blog.csdn.net/RuiKe1400360107/article/details/104270421 Java interview https://blog.csdn.net/X5fnncxzq4/article/details/81611991 springcloud项目https://blog.csdn.net/wzy18210825916/article/details/103444346 https://github.com/QiuFengYanMeng/cloud-demo https://www.cnblogs.com/springboot/p/8445780.html https://blog.csdn.net/u010938610/article/details/79282624 https://blog.csdn.net/sunroyi666/article/details/95189938 synchronize锁优化https://blog.csdn.net/qq_25843323/article/details/104565777 缓存更新套路https://coolshell.cn/articles/17416.html 分布式事务处理https://coolshell.cn/articles/10910.html https://blog.csdn.net/alex_xfboy/article/details/77572970 msyql与es数据同步问题https://blog.csdn.net/RuiKe1400360107/article/details/104270421 分布式学习最佳实践https://www.cnblogs.com/xybaby/p/8544715.html 动态规划算法https://blog.csdn.net/baidu_28312631/article/details/47426445 zookeeper的zab协议https://blog.csdn.net/u012151684/article/details/108979828 java并发之AQShttps://www.cnblogs.com/caison/p/11641159.html Redis为什么快 1、Redis是基于内存的我们大家都知道内存的寻址和带宽都是远远快于磁盘的 3、合理线程模型Redis网络模型是采用I/O多路复用器对key的处理是单线程 避免了多线程之间的竞争省去了线程切换带来的时间和空间上的性能开销而且也不会导致死锁的问题。 4、合理的数据编码 2、高效的数据结构Redis底层数据结构有简单动态字符串跳跃表压缩列表字典整数集合针对简单动态字符串压缩列表主要是考虑到节约内存像跳跃表字典主要是考虑到查询速度整数集合即考虑到了空间又考虑到了时间其实像字典中的渐进式rehash以及间断key查找都是考虑到了节约时间在Redis中不管是底层数据结构的设计以及事务的设计和key过期策略乃至key的查找还有持久化都为了快速这个特性而有了自己的特殊实现String简单动态字符串、hash、set\zset(跳表)、list(压缩链表) Question hashtable和hashmap的区别默认容量多少什么时候扩容扩容为多少 线程池的创建方式有几种 线程池的队列有哪几种 线程池的拒绝策略有几种 线程池的参数keepalivetime在什么时候会生效 Redis缓存的更新策略如果想要强一致性可以怎么做 Redis的分布式锁实现思路如何优化Redis的分布式锁有什么问题 缓存击穿缓存穿透缓存雪崩是什么如何处理 elasticsearch的原理 解决过什么难点问题如何解决 线程池的工作原理 Redis设计一个限制登录次数超过次数锁定对应的账号一定时间 package com.java_lettuce.ServiceImpl;
import com.java_lettuce.Util.SendEmailUtil;
import com.java_lettuce.config.redisConfig;
import com.java_lettuce.entity.User;
import jdk.nashorn.internal.runtime.logging.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import java.util.HashMap;
import java.util.Map;
import java.util.Random;
import java.util.concurrent.TimeUnit;
Logger
Service
public class LettceServiceImp {private org.slf4j.Logger logger LoggerFactory.getLogger(redisConfig.class);Autowiredprivate RedisTemplateString,String redisTemplate;
public String judge(String u){String keyLoginFailuser:u: login:fail: count;//用户登录失败次数String keyLoginStopuser:u: login:stop:time;//用户禁止登录时间
int num5;//总登录次数
//判断用户是否处于限制时间内if (redisTemplate.hasKey(keyLoginStop)){
long stopTimeredisTemplate.getExpire(keyLoginStop,TimeUnit.MINUTES);//剩余 禁止登陆时间return 处于限制登陆状态请在stopTime分钟后重新登陆;}else {if (!redisTemplate.hasKey(keyLoginFail)){//是首次失败//设置过期时间要和存值分开不然会失效。redisTemplate.opsForValue().set(keyLoginFail,1);redisTemplate.expire(keyLoginFail,2,TimeUnit.MINUTES);return 密码输入错误2分钟内还剩(num-1)次机会登陆;
}else {//2分钟内非首次登陆失败int failCountInteger.parseInt(redisTemplate.opsForValue().get(keyLoginFail));if (failCountnum-1){//超过限制次数冻结帐号redisTemplate.opsForValue().set(keyLoginStop,1);redisTemplate.expire(keyLoginStop,1,TimeUnit.HOURS);return 密码输入错误超过五次冻结帐号一小时;}else {redisTemplate.opsForValue().increment(keyLoginFail,1);Long waitTime redisTemplate.getExpire(keyLoginFail, TimeUnit.SECONDS);
return 密码输入错误(failCount1)次在2分钟内还可输入(num-(failCount1))次次数将于waitTime秒后重置;
}
}
}
}
} 1、判断当前登录的用户是否被限制登录 1.1如果没有被限制(执行登录功能) 2、 判断是否登录成功 2.1登录成功–(清除输入密码错误次数信息) 2.2登录不成功 2.2.1记录登录错误次数(判断 Redis中的登录次数KEY是否存在) user: loginCount:fail:用户名 2.2.1.1如果不存在 是第一次登录失败次数为1user; loginCount:fai1:用户名进行赋值,同时设置失效期 2.2.1.2 如果存在 查询登录失败次数的key结果 if(结果4) user: loginCount: fail: 1 else{//4 限制登录KEY存在,同时设置限制登录时间锁定1小时。} 3、 如果被锁定 做出相应的提示 RocketMQ https://zhuanlan.zhihu.com/p/159573084 前后端合作开发 前端要求后端传来的数据格式能够直接用于渲染是什么一个情况呢举个例子后端提供一个接口获取某单位所有人员的接口。前端则需要根据用户的职级分类显示那么前端的数据显然是要根据不同职级进行合并这合并的数据操作能放到后端的接口中么显然是不行的。假如需求改了或者其他入口需要根据年龄段分类显示所有人员本来这只是跟前端显示有关系的需求变更反而还需要改后台代码。 后端直接从数据库里扒下来的数据格式就丢给前端又是个什么情况一个更为常见的例子就是树格式。数据库的格式是基于行和表的并不存在嵌套是不可能的存在一个children 属性里面包含子节点的格式。所以一般数据库存一个树格式的数据是通过 parent 标识当前节点的父结点的方式。然而前端这边是不可能需要这种格式渲染一个树的于是每一个调用接口的地方都会写这么一套转换逻辑。当然前端可以抽离一个通用的函数进行统一转换但是不同的平台仍要都要写一套转换逻辑。仅仅是多些几次也就罢了但是通过 _parent 这种方式描述一个树是不准确的万一某个节点的父结点不存集合中是应该直接舍弃还是当作根节点parent 存在循环引用怎么办这种业务逻辑和错误本应该在后端做处理然而现在则上浮到前端才被发现。 前后端分离的场景下大家都知道要做到前后端职责的分离。前端的职责是通过调用后台提供的接口构造用户界面。前端需要感知到数据库结构吗并不需要数据库是后端用于数据持久化的工具罢了后端用什么方式做数据持久化跟我如何构造用户界面并无关系。反之后台需要感知到用户界面是什么样子吗同样不需要后端只需要提供符合业务模型的接口罢了如何构造用户界面是前端的事。 为啥又说知道这个没卵用该撕逼还是撕逼呢以上所说的都是理想情况然而实际开发往往并非能够很好落实。我知道什么是正确的做法如何去抽象我可以用这一套约束我的代码但是当我开始约束别人的时候往往会遇到问题。抽象和规范是有成本的我来付这成本当然没人有意见当要求别人付出别人难免会有意见特别是项目工期紧张/跨工种/架构不合理/人员素质良莠不齐的情况下。很多答者所认为“前端能处理就放到前端处理”“前端做比较方便”其实都是这种思路。而很多人提到的性能问题做一些数据格式转换和数据校验说实话我并不觉得会对服务器产生多大的性能瓶颈相比服务端渲染这点性能消耗只能算小巫见大巫。当然这也不是针对后端同学像很多答者没提到的问题比如浏览器对并行的请求数量有限制要求后端对提供的接口进行合并其实也就是前端不愿付出 BFF 层的成本罢了。
