数据缓存、接口限流和服务降级
数据缓存
在web系统中,数据库很容易成为系统的短板,而为了满足高并发的需求,就需要存在一个缓存层,分摊数据库的压力,提高并发能力。
同样的道理,缓存在大多数分层设计中都是不可或缺的,比如:
-
内存作为数据落地到硬盘的缓存
-
CPU高速缓存作为内存的缓存
-
PHP组件opcache对预编译opcode的缓存
-
CDN加速作为静态文件访问的缓存
缓存系统的好处:
-
加快访问速度,提高并发量
-
避免重复运算,节约计算资源
-
保护下游系统,提高系统可用性
一般的数据库架构都是一主多从,高并发的系统中,大多数的数据库请求都是读请求,此时通过主从同步,增加多个从库,可以有效的分摊主库的读压力,如果高峰期数据读写大的情况下,会存在主从延迟,对业务代码会有一定要求。
读库的压力问题解决了,写库也会存在高并发、负载高的状况,通常可以通过消息队列、延迟写入的做法缓解瞬时的高并发高负载,对于一些对实时性要求不高的业务,先放进队列缓存,然后延迟处理,用时间换空间。
一主多从的数据库系统中,多个从库的权重设置通常按照资源划分,但是当某个节点异常的情况下,此时节点的 健康检查 和 动态权重 就至关重要了。
接口限流
为什么要对访问进行限流呢?
-
恶意访问(DDoS攻击),拒绝资源过度使用
-
并发流量超过系统承载能力,选择性的拒绝一部分访问(服务降级)
我们队服务进行了大量优化,极大的提高了系统并发能力的前提下,受限于有限资源,还是很难满足瞬时高并发,那么我们只能选择对访问进行限制了,拒绝掉一部分流量,保证我们系统的大部分功能模块的可用性。
常用的接口限流的算法:
-
计数器算法
-
漏桶算法
-
令牌桶算法
以上算法都是从请求数量,请求频率上决定是否限制访问,同时在我么日常开发过程中,也可以根据业务暂时对某些功能模块限流。
服务降级
当并发量太大,外围业务负载较高时,我们为了保证主要业务的可用性,就需要降低服务质量,或者舍弃一部分非必需业务,从而降低服务的负载,这就是我理解的服务降级,或者可以说是暂时开启『瘦身模式』。
举个例子:
- 日常访问用户订单列表的时候,我们是实时查询的,而当服务降级以后,可能你的订单需要等几分钟才可以被查看到。
- 日常访问文章页面,可以查看文章,添加评论,当服务降级以后,只能查看内容,而无法添加评论、点赞等其他操作。
当我们砍掉一部分服务,全力保证主要业务可用性的情况下,还是没办法满足当前负载,更可怕的是数据库宕机了!
数据库挂了,用户访问页面直接报错,此时用户体验极差。
那当我们的数据库服务熔断的时候,我们该如何保证损失最小?
- 做好服务隔离,即使没有数据库的情况下,我们依然可以保证一些服务可用
- 设计合理的错误页面,引导用户到可用的服务
细想,难道404页面不也是一种服务熔断思想的体现。
实际产品开发过程中,不仅需要技术架构上合理,还需要产品设计中融入高可用、服务化的思想,一个多部门合作共同产出的产品,不可能仅靠技术架构合理就一枝独秀,产品设计不合理,产品原型一版推翻一版,简直是逼着开发吃屎。
俗话说,一个巴掌拍不响,不要为了服务化而服务化。
以上只是理论分析,后面会就其中细节写一些真正可实践的操作方法。