权衡取舍Trade Off
-
前言
- 我们没有一块又大、又快、又偏移的存储，于是出现如下权衡的产物:
- CPU寄存器: 非常快，但不便宜也不大
- RAM: 不太快也不太大，还算便宜
- 硬盘: 非常便宜非常大，但读写慢
- 我们没有一块又大、又快、又偏移的存储，于是出现如下权衡的产物:
-
同理，系统设计也面临许多权衡取舍:
-
性能 与 可扩展性 Scability
- 可扩展意味着服务能够以加资源的方式，成比例地提升性能
- 但加入资源，又会引入多样性，出现新老节点之间使用率不均匀的情况，性能受到影响
-
延迟 Latency 与 吞吐量 Throughput
- 延迟
- 指的是 执行操作 到 产生结果 所需要的时间
- 比如多少毫秒
- 吞吐量
- 指的是 单位时间 能处理的操作数
- 比如
- QPS
- 全称Queries Per Second
- 代表 系统在1秒内能响应的查询数
- RPS
- 全称Requests Per Second
- 代表 系统在1秒内能响应的请求数
- QPS
- 无法兼具 低延迟 和 高吞吐量，所以权衡的原则是
- 在确保延迟可以接受的前提下，追求最大的吞吐量
- 延迟
-
可用性 与 一致性
-
CAP定理
- C 指 consistency 一致性，每次读取都能得到最新写入的结果
- A 指 availability 可用性，每个请求都能收到正常响应，但不保证数据最新
- P 指 partition tolerance 分区容错性，即使系统有一部分挂掉了，也能正常运行
-
因为网络不完全可靠，所以必须保证P，而C和A只能选一个
- 如果你要C，那数据一致性高，节点出现故障时，必须要等数据完全一致才能继续提供服务，则可用性无法保证
- 如果你要A，那服务可用性高，节点出现故障时，不用等数据完全同步就继续服务，则一致性无法保证
-
三种一致性模式
- 弱一致性
- 写完之后，不一定能读到
- 适用于 网络电话、视频聊天
- 最终一致性
- 写完之后，异步复制数据，保证最终能读到最新的
- 适用于 DNS、email等系统
- 强一致性
- 写完之后，同步复制数据，立即就能读到
- 适用于文件系统、RDBMS等需要事务机制的场景
- 弱一致性
-
两种可用性模式
- 故障转移
- 一个节点挂掉后，迅速用另一个节点替代它，具体又有两种
- 主动-被动模式: 被动的随时待命，准备接管ip地址并恢复服务
- 主动-主动模式: 一起工作，挂掉一个也没关系
- 一个节点挂掉后，迅速用另一个节点替代它，具体又有两种
- 复制
- 多用于数据库，具体又有两种
- 主从复制: 主库等从库确认后才返回，保证从库是最新的，可以无缝切换
- 主主复制: 同时更新两台主库，都成功才返回，挂掉一个也没关系
- 多用于数据库，具体又有两种
- 故障转移
-
可用性衡量方式
- 通常用几个9来衡量，表示服务可用时间占运行时间的百分比
- 3个9
99.9%- 每年 宕机时间 不超过 8小时45分钟57秒
- 每月 宕机时间 不超过 43分钟49秒
- 4个9
99.99%- 每年 宕机时间 不超过 52分钟35秒
- 每月 宕机时间 不超过 4分钟23秒
- 对于多部分组成的系统，整体可用性取决于 串行 还是 并行
- 串行的话，整体可用性会下降(只要坏一个，都算坏)
- 并行的话，整体可用性会上升(两个同时坏，才算坏)
-
-