分布式系统中的服务等级协议SLA

SLA（Service-Level Agreement），服务等级协议，指的是系统服务提供者对客户的一个承诺。用来衡量一个分布式系统的好坏程度。
最常用的SLA指标：可用性、准确性、系统容量和延迟。

1.可用性（Availability）

可用性指的是系统服务能正常运行所占的时间百分比。
“99.9%”指的是一天系统服务将会有大约86秒（$24\times 60\times 60\times 0.001$）的服务间断期。

2.准确性（Accuracy）

准确性指的是系统服务中，是否允许某些数据是不准确的或者是丢失的。如果允许，用户可以接受的概率是多少。
很多时候，系统架构会用错误率来定义这一项SLA。

$$错误率=\frac{导致系统产生内部错误的有效请求书}{期间的有效请求总数}$$

Google Cloud Platform 的SLA中对准确性的定义：每个月系统的错误率超过5%的时间要少于0.1%，以每分钟为单位来计算。
AWS对准确性的定义：以每5分钟为单位，错误率不会超过0.1%。

3.系统容量（Capacity）

系统容量是指系统能够支持的预期负载量是多少，一般以每秒的请求数为单位来表示。

QPS – Queries Per Second
PRS – Request Per Second 是指系统每秒可以响应多少请求数。

Twitter系统可以响应30万的QPS来读取Twitter Timelines。

有以下方式来对自己设计的系统架构定理准确的QPS：

限流（Throttling）

Java语言可以使用Google Guava库中的RateLimiter类来定义每秒最多发送多少请求到后台处理。
假设每台服务器定义每秒1000个请求的RateLimiter并且我们有N台服务器。最理想下的QPS = 1000*N。

注意：请求数不是越多越好，每台及其内存有限，过多请求可能会导致内存溢出（Out-Of-Memory），从而让整个服务器崩溃。

系统交付前进行性能测试（Performance Test）

可以使用Apache JMeter 或者是 LoadRunner这类工具可以用来进行性能测试。

注意：使用同一类型的请求参数，可能会导致后台服务器多数情况下命中缓存（Cache Hit），导致得到的QPS不是真实的QPS。

分析系统在实际使用中产生的日志（Log）

我们可以在系统上线后，计算每天最繁忙时刻接受到的请求数，来计算系统的QPS。

注意：这样算出的QPS不一定可以得到系统可以承载的最大QPS。
实际中，更多会采用性能测试和日志分析相结合的手段。

4.延迟（Latency）

延迟是指系统在收到用户请求到响应这个请求之间的时间间隔。

延迟声明p95中的p是指percentile，意味着一个系统的p95延迟是1s的话，表示在100个请求里面有95个请求的响应时间会小于1s，而剩下的5个请求的响应时间会大于1s。

为了降低系统的延迟，会将数据库内容放进缓存。
可通过改进缓存策略来提高缓存命中率或者优化数据库的Schema或者Index来降低p95延迟。