分布式系统知识点梳理
CAP 原则
CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。
Consistency (一致性)：
“all nodes see the same data at the same time”，即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
Availability (可用性)：
可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
Partition Tolerance (分区容错性)：
即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。
BASE 定理
分布式系统不可能同时满足cap三个特性，最多只能同时满足其中的两个，分区容错性必不可少，因为总是假定网络不是可靠的，所以必须要在可用性和一致性之间做选择。
保证一致性：让系统暂停服务，等待数据同步完成。
保证可用性：同步过程中继续提供服务，读取的数据可能不一致。
CA矛盾的原因
如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性；如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。
分布式一致性协议raft
一致性哈希算法
在分布式系统中，为了保证负载均衡，可以对发送的信息进行hash映射，然而，如果节点增加或减少，将会使得系统所有的数据节点映射改变，给系统带来不稳定性。一致性哈希对2的32次方取模，节点增加或减少对系统的影响很小。若增加或减少节点，造成不命中，只需在哈希环上顺时针找到最近的一个节点即可。
由于哈希环节点可能稠密不同，为了保证负载均衡，可以对称增加服务器虚拟节点。
HTTP和RPC的区别
| rpc | http | |
|---|---|---|
| 传输协议 | tcp; http | http |
| 传输效率 | 基于tcp或者http2效率会更高 | 基于http1.1会慢，基于http2再做简单封装就可以当rpc来用 |
| 性能消耗 | 基于thrift可以实现高效的二进制传输 | 大部分通过json实现，字节大小和序列化耗时都会降低性能。 |
| 负载均衡 | 自带了负载均衡策略 | 需要配置nginx |
| 服务治理 | 自动通知，不影响上游 | 要做到事先通知，修改nginx配置 |
分布式系统一致性
分布式系统一致性级别：强一致性，顺序一致性以及弱一致性。
线性一致性
在全局时钟范围内，所有数据的读写都是一致合理的。
这表现为：1、任何一次读都能读到最近一次写的数据；2、所有进程的操作顺序都和全局时钟下保持一致。
顺序一致性
进程的操作顺序是一致合理的，但在全局时钟范围内并不一致。
最终一致性
不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化，从而达到最终的一致性。
最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，可以继续分为：
- 因果一致性（Casual Consistency）。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问，遵守一般的最终一致性规则。
- “读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
- 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
- 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
- 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。
分布式系统一致性的解决方案
分布式存储
分布式存储除了传统意义上的分布式文件系统、分布式块存储和 分布式对象存储外，还包括分布式数据库和分布式缓存等。
以文件系统为例，常见的架构有中间控制节点架构（HDFS）、完全无中心架构（一致性哈希）。
问到分布式存储，大概率就是要问一致性哈希算法了！
分布式事务
大型网站系统架构
“用户-负载均衡器-N台服务器-redis缓存集群-mysql集群”
前端限流（例如一个用户10秒内只能点击一次，异步处理，消息队列）；
负载均衡一般采用NGINX反向代理；
mysql读写分离，主库写，从库读，分库分表。
秒杀系统设计
分布式锁（ZooKeeper）
分布式缓存
微服务
数据库主从一致性
主从不一致是延时导致的。出于性能考虑，采用读写分离。
- 半同步复制：主从同步完成之后，主库再返回写请求。主库写请求延时增加，吞吐量下降。
- 数据库中间件：加了中间件后，设置一个同步时间，如果
限流算法
漏桶算法
业务组件处理速率恒定。
令牌桶算法
业务组件会出现高峰，能短期处理些高发情况。
