Day 19:处理系统超载

读完软件测试之後,接下来读到一个比较有帮助的章节是如何处理系统超载,书中提供了一些可供参考的策略。撇除那些针对大型分散式系统的部分,我想整理一下对於我们这种小型的服务也具有参考价值的做法。

为每个使用者设定限额

这个部分主要是讨论如何因应全域超载 (global overloading),当它发生的时候,我们也应该要避免所以人都没有办法正常使用服务,所以针对每个使用者去限制它可以使用的资源额度便是一种有效的策略。

以 NOJ 来说,之前比较常发生在考试时产生的大量 submission 塞住了整台 server,导致所有人进行的任何操作都变得非常缓慢,在这种情况下,我想可以就两个层面去进行限制:

  • 容器:第一个部分是应该要针对容器去进行资源的限制,避免服务中的特定元件消耗掉了太多资源,进而导致其他元件无法正常运作。
  • 使用者:上述问题发生的其中一个成因是因为後端接受了太多 submission 的请求,所以针对 submission 数量去做控管是个方法。然而若是基於请求的先後顺序去接受 submission 请求可能会阻塞其他人的请求,因此我想若是可以限制每位使用者在单位时间内可以发送的 submission 数量或许会更好。

客户端节流

有些时候,大量地从 server 端拒绝请求也会造成额外的负担,若是可以预期接下来的请求也会被拒绝的话,其实在客户端就拒绝发送可以减小後端受到的压力。

书中是采用请求数量与被接受请求数量的比例去决定发送请求的成功机率,当被拒绝太多次则会逐渐提高拒绝发送请求的机率。

重要性

将请求按照重要程度分级,可以让後端决定是否要处理这项请求,以书中来说它分成了四个等级:

  • CRITICAL_PLUS
  • CRITICAL
  • SHEDDABLE_PLUS
  • SHEDDABLE

当然也只是个参考,可以依照需求增减。

小结

如何优雅的处理超载的情况是个重要的议题,并不是说通通拒绝掉就好,而是应该考量如何尽可能降低对使用者的影响。话说要能够处理这些情况,我想好好记录服务当前的状态是个重要的前提。希望今天记录下来的这些技巧对於这学期重构系统会有些帮助...

BTW,之前纪录的有关机敏资料管理的修正已经发出 PR 了,果然有写文章有差,不然去年一直在逃避处理这些问题。


<<:  【程序】软件测试 Testing 转生成恶役菜鸟工程师避免 Bad End 的 30 件事 - 20

>>:  [经典回顾]资讯服务异常公关用语「 骇客攻击」

第23天~又是JSON+ListView

又是JSON 开新专案 准备XML档+ListView 放好ID 准备一个TXT档案- 把txt档案...

Consistency and Consensus (4-1) - Atomic Commit and Two-Phase Commit(2pC)

分散式 transaction 和共识 (Distributed Transactions and ...

Week40 - 各种安全性演算法的应用 - 窜改、抵赖实作 [高智能方程序系列]

本文章同时发布於: Medium iT 邦帮忙 大家好,继上次Week39 - 各种安全性演算法的应...

C# 入门笔记02

物件导向 这单元主要是让大家了解物件导向的基本实作 物件导向有三大特性: 封装 继承 多型 封装 类...

Python 演算法 Day 12 - Weak Learning

Chap.II Machine Learning 机器学习 https://yourfreetemp...