网站留言系统是怎么做的网站 需求分析

网站留言系统是怎么做的,网站 需求分析,餐饮网站开发毕业设计模板,微信导入wordpress一、限流思路常见的系统服务限流模式有#xff1a;熔断、服务降级、延迟处理和特殊处理四种。1、熔断将熔断措施嵌入到系统设计中#xff0c;当系统出现问题时#xff0c;若短时间内无法修复#xff0c;系统会自动开启熔断开关#xff0c;拒绝流量访问#xff0c;避免大流…一、限流思路常见的系统服务限流模式有熔断、服务降级、延迟处理和特殊处理四种。1、熔断将熔断措施嵌入到系统设计中当系统出现问题时若短时间内无法修复系统会自动开启熔断开关拒绝流量访问避免大流量对后端的过载请求。除此之外系统还能够动态监测后端程序的修复情况当程序已恢复稳定时就关闭熔断开关恢复正常服务。常见的熔断组件有 Hystrix 以及阿里的 Sentinel。在Spring Cloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况当失败的调用到一定阈值缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是HystrixCommandHystrix会找有这个注解的方法并将这类方法关联到和熔断器连在一起的代理上。2、服务降级将系统的所有功能服务进行一个分级当系统出现问题需要紧急限流时可将不是那么重要的功能进行降级处理停止服务保障核心功能正常运作。例如在电商平台中如果突发流量激增可临时将商品评论、积分等非核心功能进行降级停止这些服务释放出机器和 CPU 等资源来保障用户正常下单。这些降级的功能服务可以等整个系统恢复正常后再来启动进行补单/补偿处理。除了功能降级以外还可以采用不直接操作数据库而全部读缓存、写缓存的方式作为临时降级方案。熔断降级相同点目标一致 都是从可用性和可靠性出发为了防止系统崩溃用户体验类似最终都让用户体验到的是某些功能暂时不可用。不同点触发原因不同服务熔断一般是某个服务下游服务,即被调用的服务故障引起而服务降级一般是从整体负荷考虑。3、延迟处理延迟处理需要在系统的前端设置一个流量缓冲池将所有的请求全部缓冲进这个池子不立即处理。后端真正的业务处理程序从这个池子中取出请求依次处理常见的可以用队列模式来实现。这就相当于用异步的方式去减少了后端的处理压力但是当流量较大时后端的处理能力有限缓冲池里的请求可能处理不及时会有一定程度延迟。4、特权处理这个模式需要将用户进行分类通过预设的分类让系统优先处理需要高保障的用户群体其它用户群的请求就会延迟处理或者直接不处理。二、限流算法常见的限流算法有三类计数器算法、漏桶算法和令牌桶算法。1、计数器算法计数器算法是限流算法中最简单最容易的一种如上图每分钟只允许100个请求第一个请求进去的时间为startTime在startTime 60s内只允许100个请求 。当60s内超过十个请求后则拒绝请求不超过的允许请求到第60s 重新设置时间。View Code利用计数器算法比如要求某一个接口1分钟内的请求不能超过100次。可以在开始时设置一个计数器每次请求该计数器1如果该计数器的值大于10并且与第一次请求的时间间隔在1分钟内那么说明请求过多则限制请求直接返回或不处理反之。如果该请求与第一次请求的时间间隔大于1分钟并且该计数器的值还在限流范围内那么重置该计数器。计算器算法虽然简单但它有一个很致命的临界问题。上图可以看出假若有一个恶意用户他在0:59时瞬间发送了100个请求并且在1:00时又瞬间发送了100个请求那么其实这个用户在 1秒后瞬间发送了200个请求。而上述计数器算法规定的是1分钟最多100个请求也就是每秒钟最多1.7个请求而用户通过在时间窗口的重置节点处突发请求可以瞬间超过限流的速率限制这个漏洞可能会瞬间压垮服务应用。上述漏洞问题其实是因为计数器限流算法统计的精度太低可以借助滑动窗口算法将临界问题的影响降低。2、滑动窗口上图中整个红色的矩形框表示一个时间窗口。在计数器算法限流的例子中一个时间窗口就是一分钟。在这里将时间窗口进行划分比如图中将滑动窗口划成了6格每格代表的是10秒钟。每过10秒钟时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter比如当一个请求在0:35秒的时候到达那么0:30~0:39对应的counter就会加1。那么滑动窗口是怎么解决刚才的临界问题的呢上图0:59到达的100个请求会落在灰色的格子中而1:00到达的请求会落在橘黄色的格子中。当时间到达1:00时窗口会往右移动一格那么此时时间窗口内的总请求数量一共是200个超过了限定的100个所以此时能够检测出来触发了限流。经过比较发现发现计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分所以只有1格。所以当滑动窗口的格子划分得越多则滑动窗口的滚动就越平滑限流的统计就会越精确。3、漏桶算法漏桶算法思路很简单水请求先进入到漏桶里漏桶以一定的速度出水当水流入速度过大会超过桶可接纳的容量时直接溢出可以看出漏桶算法能强行限制数据的传输速率。使用漏桶算法可以保证接口会以一个常速速率来处理请求所以漏桶算法必定不会出现临界问题。漏洞算法实现类View Code使用漏桶限流View Code漏洞算法的两个优点削峰有大量流量进入时会发生溢出从而限流保护服务可用。缓冲不至于直接请求到服务器缓冲压力消费速度固定因为计算性能固定。4、令牌桶算法令牌桶算法思想以固定速率产生令牌放入令牌桶每次用户请求都得申请令牌令牌不足则拒绝请求或等待。上图令牌桶算法会以一个恒定的速度往桶里放入令牌而如果请求需要被处理则需要先从桶里获取一个令牌当桶里没有令牌可取时则拒绝服务。View Code令牌桶算法默认从桶里移除令牌是不需要耗费时间的如果给移除令牌设置一个延时时间那么实际上又采用了漏桶算法的思路。至于临界问题的场景在0:59秒的时候由于桶内积满了100个token所以这100个请求可以瞬间通过。但是由于token是以较低的速率填充的所以在1:00的时候桶内的token数量不可能达到100个那么此时不可能再有100个请求通过。所以令牌桶算法可以很好地解决临界问题。漏桶与令牌桶算法的区别主要区别在于“令牌桶算法”能够强行限制数据的传输速率而“令牌桶算法”在能够限制数据的平均传输速率外还允许某种程度的突发传输。在“令牌桶算法”中只要令牌桶中存在令牌那么就允许突发地传输数据直到达到用户配置的门限因此它适合于具有突发特性的流量。令牌桶算法由于实现简单且允许某些流量的突发对用户友好所以被业界采用地较多。具体情况具体分析只有最合适的算法没有最优的算法。基于谷歌RateLimiter实现限流Google开源工具包Guava提供了限流工具类RateLimiter该类基于令牌桶算法(Token Bucket)来完成限流非常易于使用。RateLimiter经常用于限制对一些物理资源或者逻辑资源的访问速率它支持两种获取permits接口一种是如果拿不到立刻返回falsetryAcquire()另一种会阻塞等待一段时间看能不能拿到tryAcquire(long timeout, TimeUnit unit)。View Code三、集群限流前面几种算法都属于单机限流的范畴但简单的单机限流仍无法满足复杂的场景。比如为了限制某个资源被每个用户或者商户的访问次数5s只能访问2次或者一天只能调用1000次这种场景单机限流是无法实现的这时就需要通过集群限流进行实现。可以使用Redis实现集群限流大概思路是每次有相关操作的时候就向redis服务器发送一个incr命令。redisOperations.opsForValue().increment()比如需要限制某个用户访问某个详情/details接口的次数只需要拼接用户id和接口名加上当前服务名的前缀作为redis的key每次该用户访问此接口时只需要对这个key执行incr命令再这个key带上过期时间就可以实现指定时间的访问频率。