1 分布式
1.1分布式理论
1 cap 理论
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
- 强一致性（C）：对某个指定的客户端来说，读操作能返回最新的写操作结果
- 高可用性（A）：非故障节点在合理的时间返回合理的响应
- 分区容错性（P）：分区容错性是指当网络出现分区（两个节点之间无法连通）之后，系统能否继续履行职责
当发生网络分区的时候，如果我们要继续服务，那么强一致性和高可用性只能 2 选 1。
也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。
若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
对于不同业务也会需要考虑到不同的CAP选择，以电商网站为例，会员登录、个人设置、个人订单、购物车、搜索用AP，因为这些数据短时间内不一致不影响使用；后台的商品管理就需要CP，避免商品数量的不一致；支付功能需要CA，保证支付功能的安全稳定
2 Base 理论
由于 CAP 只能二选一，是CAP 理论的一种妥协
-
基本可用：降低可用性，运行服务降级
-
软状态：允许系统存在中间状态
-
最终一致：数据同步可用存在时延
3 waro 机制
只有当所有副本的数据都写成功，才能返回成功
===》优点：优先保证读，只需要有个服务器存活就可以读到正确数据
===》缺点：写困难
4 quorum 机制
10个副本，更新三个就可用返回成功
===》优点：写快速，对写友好
===》需要读取多个节点数据，选择版本号最高的
5 Paxos算法
只是一个算法的模型，并不是一种实现
6 RAFT
7 ZAB
比较的是 ZID 和 Servie ID ,同样是广播发送，如果 A 的ZID 小于 B ,A 会投票给B
1.2 集群 分布式 微服务 概念
饭店的厨师、配菜师、传菜员、服务员就是分布式；厨师、配菜师、传菜员和服务员都不止一个人，这就是集群；分布式就是微服务的一种表现形式，分布式是部署层面，微服务是设计层面
集群：多个人在一起作同样的事 ，实现高可用，分摊压力
分布式 ：在业务层面进行拆分，多个人在一起作不同的事 ====》在机器的部署层面上
微服务：微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。=====》在设计层面
1.3 分布式常用的缓存方案
客户端缓冲：页面和浏览器进行缓存
CDN：内容存储、数据缓存
nginx：静态资源缓存
服务端缓存：本地缓存（放在java中的）、外部缓存（redis）
数据库层：持久层框架的缓存（mybatis）、mysql 查询缓存
操作系统缓存：page cache 、 Buffer cache
1.4 数据库和缓存的一致性
- 在一般情况下，缓存最好用删除而不是更新：删除更加轻量级，是一种延迟加载的表现，更新可能会设计多个表的计算
方案：
- 先更新数据库，在删除缓存
存在的问题在于：在更新数据库后，还没有删除缓存时候，读到的还是老的数据
- 延迟双删除：先删除缓存，在更新数据库，休眠1s再次删除缓存
存在问题在于：删除缓存之后，另一个线程过来读取，这时候又缓存了旧的数据，在更新了数据库，1s后才能删除缓存
最终方案，访问串行化
1.5 降级和熔断
熔断是降级的一种方案
熔断:比如A服务的X功能依赖B服务的某个接口，当B服务接口响应很慢时，A服务X功能的响应也会被拖慢，进一步导致了A服务的线程都卡在了X功能上，A服务的其它功能也会卡主或拖慢。此时就需要熔断机制，即A服务不在请求B这个接口，A服务内部发现B接口就直接返回错误，从而避免整个A服务被拖慢。
服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑
服务降级：保住核心业务，放弃非核心业务
服务熔断：保住当前业务不会受到下级业务的连累
服务降级的方案
- 页面拒绝服务：此服务暂停，页面提示由于服务繁忙。
- 服务接口拒绝服务：只读，对于增删改接口提示服务器繁忙。
- 延迟持久化：页面正常访问，涉及变更将数据记录到异步队列或log，服务恢复后执行。
- 随机拒绝服务：服务接口随机拒绝服务，让用户重试，用户体验不佳。
1.6 高并发下现实系统限流
时间窗口、令牌桶、漏桶
1.7 负债均衡算法
- 轮询
- 加权轮询
- 随机发
- 加权随机
- 哈希地址 ====》可用保证访问到同一个session
- 最小连接数发
