1. 数据系统的核心目标

• 可靠：当出现意外情况（如硬件、软件故障、人为失误等），系统应该可以继续正常运转
• 可扩展：系统可以合理地应对规模增长(数据量、流量或负载性)
• 可维护：新参与的人员可以快速参与维护现有功能或适配新的场景。

2. 错误（fault）与失效（failure）的区别

• 错误或故障，通常表示组件偏离其正常规格

  • 容错(fault-tolerant)/弹性(resilient)：容忍特定类型的故障。通常需要设计容错机制来避免从故障引发系统失效。

• 失效，表示系统作为一个整体停止，无法向用户提供所需的服务。

3. 可以被消除的故障类型

• 硬件故障的应对方法：

  • 硬件冗余
  • 软件容错

• 软件故障的应对方法：

  • 全面测试
  • 进程隔离
  • 进程崩溃自动重启
  • 监控、告警

• 人为失误的应对方法：

  • 以最小出错的方式设计系统
  • 分离出易出错的地方、容易引发故障的接口
  • 充分的测试
  • 提供快速恢复机制，尽量减少故障的影响
  • 设置详细而清晰的监控子系统，包括性能和错误率等。遥测（Telemetry）。
  • 推行管理流程并加以培训。

4. 可扩展性

可扩展性用来描述系统应对负载增加的能力

如何描述负载？

负载可以用称为负载参数的若干数字描述，而具体参数的选择取决于系统的体系结构，它可能是：

• Web服务器的QPS
• 数据库中写入的比例
• 在线用户数量
• 缓冲命中率
• …

如何描述性能？

随着负载的增加，会发生什么。有两种考虑方式：

• 负载增加，但系统资源保存不变，系统性能会发生什么变化？
• 负载增加，如果要保持性能不变，需要增加多少资源？

一般使用如下指标来描述系统的性能：

• 吞吐量：每秒可处理的请求数

• 延迟：请求花费在处理上的时间

• 响应时间：客户端发送请求，到收到响应的时间

  • 响应时间 = 服务时间 + 网络延迟 + 排队延迟

对于不同的系统，侧重点也有所不同。

通常使用百分位数（percntiles）来描述、定义服务质量目标（Service Level Objectives,SLO）和服务质量协议（Service Level Agreemetns,SLA）：

• 50% （p50）
• 95%（p95）
• 99%（p99）
• 99.9%（p99.9）

应对负载增加的方法

❓ 负载增加时，如何保持良好的性能？

• 垂直扩展：升级到更强大的机器

  • 高端机器昂贵，且扩展水平有限

• 水平扩展：将负载分布到多个更小的机器

其他要考虑的问题：

• 手动扩展还是自动扩展（弹性系统）？
• 服务是有状态的还是无状态的？

5. 可维护性

在软件设计之初就应考虑，尽可能减少维护期间的麻烦。因此，需要关注软件系统的三个设计原则：

• 可运维性：方便运营团队来保持系统平稳运行
• 简单性：简化系统复杂性，使新工程师能够轻松理解系统。
• 可演化性：后续工程师能够轻松地对系统进行改造、扩展等