简介
发展史
单一应用架构
垂直应用架构
分布式服务架构
分布式系统面临的挑战
分布式session
session共享的问题，用户请求机器a创建session,下一个请求负载到机器b，还需要创建session.
session粘性
session同步
tomcat-reids-session-manager session多机同步
session集中管理
spring-session 如使用redis集中管理session
分布式配置
appolla
eruka
nacos
zk
分布式事务
- 两阶段/三阶段提交
- tcc
- 本地消息表
- rocketmq
- seata
集群和冗余的一致性
- paxos
- zab (zk)
主从是Leader和Flower 主备是Leader和
第一次变更 请求号为编号为1，修改值为3
第二次变更 请求编号为5，修改值为4
分布式锁
redis
zk分布式锁
- 饿汉式 所有客户端争抢创建锁znode节点，缺点：会造成争抢过程中的不必要性能浪费 (和redis基本相同)
- 懒汉式 所有客户端监听锁znode的删除事件，缺点：第一次上锁还是会并发抢锁
- 队列 进入队列排队上锁。实现方式：在mylock根目录下创建有序临时节点，表示排队
分布式Job任务
大厂的系统可能有成千上万个job
- elstic-job
- quartz
- xx-job
选型：
quartz不支持分片，单任务多节点时只能一个节点执行，只适用于单机或者数据量较少的情况；
xx-job侧重业务实现简单，推荐在用户基数少，机器集群在一定范围内的场景下使用
elastic-job 关注数据，增加弹性扩容和数据分片的思路，推荐数据量庞大且机器部署较多的场景
高性能高可用
高吞吐
CAP高可用
- 日志
全链路日志 业务日志类似于binglog 起监控、查询和复原等作用
异常日志 异常code+msg 定义异常编码库 (阿里京东等一个接口的异常编码定义可高达几百个)
- 监控
C一致性
- 缓存与db一致性
- 多数据节点同步的一致性
- 分布式事务的一致性
A高可用
- 客户端容错
- 服务端容错
？一个接口 1个月后返回给我，也是数据一致的、结果正确的，但是高可用吗？
1秒法则 面向web侧，h5链路上加载性能和体验的一个指标，大于1秒不属于高可用。
- 强网下1秒内完成页面加载，包括首屏资源
- 3G下1秒内完成首包返回
- 2G下1秒内完成连接建立
P分区容错
异域容灾 代表不同空间
CA相互矛盾，因此一般只能保证CP和AP，和钱相关一般CP, 要求高吞吐AP
BASE理论
basicaly avaliabe 基本可用
soft state 软状态
eventualy 最终一致性
若有收获，就点个赞吧
0 人点赞
