性能与可扩展性

可扩展，意味着服务能以加资源的方式成比例地提升性能，性能提升体现在能够承担更多的工作量，但加资源也会引入多样性：一些节点可能比其它节点的处理能力更强大，另一些老旧节点可能弱一些，而系统又必须适应这种异质性（heterogeneity），那么依赖均匀性的算法就会对新节点利用不足，继而产生性能影响

延迟与吞吐量

延迟（Latency）是指从执行操作到产生结果所需要的时间，其度量单位是时间。
吞吐量（Throughput）是指单位时间内所能处理的操作数，或能产生的结果数。
通过单位时间所生产的东西来计量，例如内存带宽（memory bandwidth）用来衡量内存系统的吞吐量，而对于Web系统，有这些度量单位：

QPS（Queries Per Second）：用来衡量信息检索系统（如搜索引擎、数据库等）在1秒内的搜索流量RPS（Requests Per Second）：请求-响应系统（如Web服务器）每秒所能处理的最大请求数量TPS（Transactions Per Second）：广义上指在1秒内所能执行的原子操作数量，狭义上指DBMS在1秒所能执行的transaction数量

通常也用QPS衡量Web服务的吞吐量，但更准确的单位是RPS。
由于无法兼具低延迟和高吞吐量，所以权衡之下的原则是：在确保延迟尚可接受的前提下，转而追求最大的吞吐量

可用性与一致性

关于可用性与一致性，有个著名的CAP定理，可以查看往期笔记：CAP理论
在分布式计算机系统中，一致性、可用性和分区容错性三者只能择其二（而且分区容错性必选）：

一致性（Consistency）：每次读取都能得到最新写入的结果，抑或出错
可用性（Availability）：每个请求都能收到正常响应，但不保证返回的是最新信息
分区容错性（Partition Tolerance）：即便有一部分由于网络故障down掉了，系统仍能继续运行

因为网络不完全可靠，所以必须保证分区容错性（P必选）。当部分节点出现网络故障时，有2个选择：

取消操作：能确保一致性，但会降低可用性（用户可能收到超时错误），即CP（Consistency and Partition Tolerance），适用于需要原子读写的场景
继续操作：保证可用性，但存在一致性风险（返回的信息可能是旧的），即AP（Availability and Partition Tolerance），适用于可接受最终一致性（Eventual consistency）的场景

在P必须满足的前提下（网络故障是系统之外的不可控因素，没得选），只能在C和A之间进行取舍，要么保证一致性（牺牲可用性），要么保证可用性（牺牲一致性）。在中心化系统（例如RDBMS）中，不存在网络可靠性的问题，此时C和A能够两全

一致性模式

同一数据存在多份拷贝，那么就需要考虑如何保证其一致性。而严格的一致性意味着要么读到最新数据，要么出错。但并非所有场景下都需要达到这样的一致性要求，所以出现了弱一致性与最终一致性等妥协产物。
弱一致性：
写完之后，不一定能读到。弱一致性模式（Weak consistency）适用于网络电话、视频聊天、实时多人游戏等实时场景，而网络电话断线重连后，不会再收到断线期间的通话内容
最终一致性：
写完之后，异步复制数据，保证最终能读到。最终一致性模式（Eventual consistency）适用于DNS、email等高可用系统
强一致性：
写完之后，同步复制数据，立即就能读到
强一致性模式（Strong consistency）适用于文件系统、RDBMS等需要事务机制的场景

可用性模式

可用性保障方面，主要有两种方式：故障转移与复制
故障转移：
一个节点down掉之后，迅速用另一个点代替它，以缩减宕机时间。具体的，有两种故障转移模式：

主动-被动（主从故障转移）：只由主动服务器处理流量，在工作的主动服务器与待命的被动服务器之间发送心跳包，如果心跳断了，由被动服务器接管主动服务器的IP地址并恢复服务，宕机时间的长短取决于被动机器是热启动还是冷启动

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。2、热启动：当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。

主动-主动（主主故障转移）：两台服务器都处理流量，共同承担负载

主动-被动模式下，（切换时）存在数据丢失的风险，而且无论哪种方式，故障转移都会增加硬件资源和复杂度
复制
分为主从复制与主主复制，多用于数据库，可以参考往期文章：
https://hanhandi.blog.csdn.net/article/details/115447488
https://hanhandi.blog.csdn.net/article/details/115459092

可用性衡量

对于由多部分组成的服务，其整体可用性取决于这些组成部分是串行的还是并行的：
可用性都达不到100%的两个服务组合起来，如果是串行的，其整体可用性会下降（99.9% * 99.9% = 99.8%），而并行的话，整体可用性会提高（1 - 0.1% * 0.1% = 99.9999%）
可用性通常用几个9来衡量，表示服务可用时间占运行时间的百分比：

图1 99.9%