- CAP理论与BASE理论-√
CAP: consistent && avaliable && partition tolerance
一致性：整个系统的数据状态应该是一致的，不存在逻辑矛盾的
可用性：整个系统应该保证是可用的
分区容错性：整个系统应当有容灾性能，有哪个节点失效或者哪个服务挂掉了，也要保证系统的基本可用
一般是保证AP 或者 CP
BASE:basic avaliable && soft state && eventually consistent
基本可用:即，允许系统有一定程度的不可用，例如，请求时间变长 或者 非核心功能 暂时不可用
软状态:允许系统短期不一致，即系统处于某种中间状态
最终一致性:经过一段时间，整个系统最终能达到数据状态一致的情况
- 什么是RPC
RPC remote process call 远程过程调用
与编程语言、运行环境等其他东西都无关
它可以利用http，也可以利用tcp
- 数据一致性模型有哪些-√
强一致:每次修改过后，系统就已经做到数据一致，没有逻辑冲突矛盾
弱一致:每次修改以后，不承诺可以读到修改后的数据，也不承诺多久之后可以达到数据一致的状态
最终一致:过一段时间以后，系统最终能达到数据一致的状态
- 分布式ID是什么？有哪些解决方案
在分布式部署的情况下，全局唯一ID，称之为分布式ID
0.UUID生成，能搞定，但是需要额外的空间与性能，且不直观
1.数据库统一维护，每次请求ID都向同一个数据库请求，数据库负责自增
2.redis等存储中间件，每次请求ID都向redis请求，redis负责自增
3.雪花算法[1+41+10+12][不用+时间+主机号+进程号]
- 分布式锁的应用场景是什么？有哪些实现方案？
多个分布式部署的后台进程同时操作互斥资源，需要分布式锁，才能保证数据一致，处理逻辑正常
1.ZK实现 侧重CP
2.redis实现 侧重AP
redis的分布式锁，有可能出现主从不同步的风险，解决方案是红锁,但是官方都不推荐使用这个
成熟的用法:redisson
具体的注意事项:
1.setnx 当且仅当key不存在的时候，才上锁，否则就上锁失败
2.处理逻辑最后要移除锁
3.异常处理
4.判断锁归属
5.锁超时
6.锁续命
- 分布式架构，session有哪些方案
所谓的session共享，一般是在分布式多服务的场景下探讨的。由于后台服务较多，且因为负载均衡的原因，每次访问的后台可能不是同一个服务，因此，一些临时信息需要在不同服务之间共享[例如登录信息]
1.客户端保留，比如，存在cookies里面，由前端每次带入；存在浏览器localstorage；存在vuex
2.存入Redis等存储中间件
3.后台若干服务做同步[感觉要开发较长时间还不稳定]
- 存储拆分以后，如何保证唯一主键[解决方案应当与分布式ID的解决方案相同]
0.UUID
1.单数据库自增ID
2.Redis存储中级件
3.雪花算法
- 雪花算法原理
1+41+10+12
不用+时间+机器ID+进程ID
- 分布式系统中常用的缓存方案
1.客户端:localstorage、vuex
2.nginx:静态资源
3.Java:内存缓存
4.Redis:存储中间件
5.操作系统缓存
6.数据库缓存:mybatis分页组件利用了
- 分布式缓存寻址算法
哈希:点对点
一致性哈希:点对段
哈希slot:还是点对段，但是，由于增加了逻辑层，可以减小节点上下线的开销
- 负载均衡算法有哪些
1.随机:随机分配
2.轮询:循环遍历
3.源地址哈希:每个请求都计算哈希值，相同的请求计算出相同的哈希值，就会分配到相同的服务
4.加权随机:部分服务的权重增加，随机到的次数就更多
5.加权轮询:部分服务的权重增加，遍历的时候，多访问几次