大家好，我是砸锅。一个摸鱼八年的后端开发。熟悉 Go、Lua。今天和大家一起学习分布式技术😊
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 14 天，点击查看活动详情
在分布式系统设计里，要充分考虑通过网络进行远程调用导致的不确定性，比如在响应超时的情况下增加重试机制，确保请求能够最少执行一次。在重试的时候增加幂等的机制，确保请求只被精确处理一次，并且对重试机制增加退避策略，确保系统不会因为重试导致雪崩
计算机系统通过网络定期获得时间服务器的事件，来调整本地时间，即网络时间协议（NTP），可以通过以下公式计算：本地时间 = 时间服务器返回时间 + 时间服务器响应的网络时延
分布式系统设计里，因为各个节点的本地时钟是存在误差的，所以不能依靠各自的时钟对事件进行排序。解决方案是：所有节点对需要排序的事件事件，不使用本地时钟的时间，而是去请求同一个时间服务器获得事件的发生时间，然后依据这个时间进行排序；另一个就是 Google 在 Spanner 中使用过的，通过 GPS 和原子钟实现了 TrueTime API 解决
CAP
数据一致性 C：Consistency /kənˈsɪs.tən.si/
服务可用性 A：Availability /əˌveɪ.ləˈbɪl.ə.ti/
分区容错性 P: Partition-tolerance
CAP 理论：一个分布式系统不可能同时满足数据一致性、服务可用性和分区容错性这三个基本需求，最多只能同时满足其中两个
一致性（C）
CAP 理论里一致性指的是强一致性（Strong Consistency），又叫线性一致性（Linearizable Consistency）。它要求多节点组成的分布式系统能够像单节点一样运作，如果一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有的读操作都不能读到这个数据
一致性中除了强一致性外，还有序列一致性、最终一致性
可用性（A）
CAP 理论对可用性的定义，要求系统提供的服务必须是处于 100% 可用的状态，对于用户每个操作请求，系统总能够在有限的时间内返回结果
分区容错性（P）
分区指的是在整个分布式系统里，因为各种网络原因，导致系统被分隔成多个单独的部分，不仅包含网络分区，也包含因为网络丢包导致的网络不通的情况。在现实的分布式系统里，就是一个拥有不可靠的网络和有一定概率宕机的设备，这两个因素都会导致分区出现，所以分区容错性 P 是一个必须项
所以对 CAP 理论更为合适的解释是：在满足分区容错性的前提下，没有算法能够同时满足数据一致性和服务可用性
BASE 理论
基本可用（basically available）
软状态（soft state）
最终一致性（eventually consistent）
基本可用
分布式系统出现故障时，允许损失部分可用性，以保证系统基础运转仍然正常。例如故障时响应的时间变长了，或者是在秒杀时为了系统稳定性，部分订单不成功用户会被引导至降级页面，牺牲部分功能
软状态
软状态也称为弱状态，是指允许系统中的数据存在中间状态，并且该中间状态不影响系统的可用性。也可以说分布式系统在不同节点之间进行数据同步的过程中允许有一定的不同步性
最终一致性
最终一致性是指系统里所有副本在经过一段时间同步之后，最终总是能够达到一致的状态。例如引入分布式事务：2PC、3PC、TCC 等，或者简单一些的：重试+幂等、状态机、重做日志
此文章为2月Day9学习笔记，内容来源于极客时间《深入浅出分布式技术原理》
