数据缓存、接口限流和服务降级

数据缓存、接口限流和服务降级

数据缓存

在web系统中,数据库很容易成为系统的短板,而为了满足高并发的需求,就需要存在一个缓存层,分摊数据库的压力,提高并发能力。

同样的道理,缓存在大多数分层设计中都是不可或缺的,比如:

  • 内存作为数据落地到硬盘的缓存

  • CPU高速缓存作为内存的缓存

  • PHP组件opcache对预编译opcode的缓存

  • CDN加速作为静态文件访问的缓存

    缓存系统的好处:

  • 加快访问速度,提高并发量

  • 避免重复运算,节约计算资源

  • 保护下游系统,提高系统可用性

一般的数据库架构都是一主多从,高并发的系统中,大多数的数据库请求都是读请求,此时通过主从同步,增加多个从库,可以有效的分摊主库的读压力,如果高峰期数据读写大的情况下,会存在主从延迟,对业务代码会有一定要求。

读库的压力问题解决了,写库也会存在高并发、负载高的状况,通常可以通过消息队列、延迟写入的做法缓解瞬时的高并发高负载,对于一些对实时性要求不高的业务,先放进队列缓存,然后延迟处理,用时间换空间。

一主多从的数据库系统中,多个从库的权重设置通常按照资源划分,但是当某个节点异常的情况下,此时节点的 健康检查动态权重 就至关重要了。

接口限流

为什么要对访问进行限流呢?

  • 恶意访问(DDoS攻击),拒绝资源过度使用

  • 并发流量超过系统承载能力,选择性的拒绝一部分访问(服务降级)

      我们队服务进行了大量优化,极大的提高了系统并发能力的前提下,受限于有限资源,还是很难满足瞬时高并发,那么我们只能选择对访问进行限制了,拒绝掉一部分流量,保证我们系统的大部分功能模块的可用性。

    常用的接口限流的算法:

  • 计数器算法

  • 漏桶算法

  • 令牌桶算法

以上算法都是从请求数量,请求频率上决定是否限制访问,同时在我么日常开发过程中,也可以根据业务暂时对某些功能模块限流。

服务降级

当并发量太大,外围业务负载较高时,我们为了保证主要业务的可用性,就需要降低服务质量,或者舍弃一部分非必需业务,从而降低服务的负载,这就是我理解的服务降级,或者可以说是暂时开启『瘦身模式』。

举个例子:

  • 日常访问用户订单列表的时候,我们是实时查询的,而当服务降级以后,可能你的订单需要等几分钟才可以被查看到。
  • 日常访问文章页面,可以查看文章,添加评论,当服务降级以后,只能查看内容,而无法添加评论、点赞等其他操作。

当我们砍掉一部分服务,全力保证主要业务可用性的情况下,还是没办法满足当前负载,更可怕的是数据库宕机了!

数据库挂了,用户访问页面直接报错,此时用户体验极差。

那当我们的数据库服务熔断的时候,我们该如何保证损失最小?

  • 做好服务隔离,即使没有数据库的情况下,我们依然可以保证一些服务可用
  • 设计合理的错误页面,引导用户到可用的服务

细想,难道404页面不也是一种服务熔断思想的体现。

实际产品开发过程中,不仅需要技术架构上合理,还需要产品设计中融入高可用、服务化的思想,一个多部门合作共同产出的产品,不可能仅靠技术架构合理就一枝独秀,产品设计不合理,产品原型一版推翻一版,简直是逼着开发吃屎。

俗话说,一个巴掌拍不响,不要为了服务化而服务化。

以上只是理论分析,后面会就其中细节写一些真正可实践的操作方法。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注