基础
性能
-
性能指标
- 响应时间
- 吞吐量（QPS、TPS）
- 并发用户数：不是越高越好，如果系统来不及处理就会阻塞，响应时间会大大提高
-
性能优化
- 集群
- 缓存（Redis、CDN）
- 异步
伸缩性
- 扩容
- 无状态的应用服务器可以通过负载均衡器想集群中添加新的节点
- 关系型数据库可以用过Sharding实现
- 非关系型数据库对伸缩性支持很好
扩展性
- 添加新的功能对现有系统的其他应用无影响
- 使用消息队列进行解耦
- 分布式服务奖业务可复用的部分模块化
可用性
- 冗余（多点备份，异地双活）
- 故障切换
- 服务降级
- 监控
安全性
-
应对各种攻击手段
- SQL注入
- XSS攻击
分布式
分布式锁
-
数据库唯一索引
- 没有失效时间，解锁失败会造成死锁
- 只能是非阻塞，插入失败无法重试
- 不可重入，已获得锁的进程也必须重新获取锁
-
Redis的SETNX指令
- 节点挂了就不可用，造成死锁
-
RedLock
- 高可用
-
Zookeeper的有序节点
分布式事务
-
两阶段提交（2PC）
-
准备阶段
- 协调者询问所有参与者事务执行的结果
-
提交阶段
- 协调者根据所有参与者返回的结果判断最终是提交还是回滚
-
存在问题
- 同步阻塞
- 单点故障
- 数据不一致
-
-
本地消息表
- 1. 分布式事务操作方完成写业务数据后向本地消息表发送一个消息，确保这个消息一定会写入本地消息表
- 之后将本地消息表中的消息转发到消息队列，转发成功则从本地消息表删除，否则继续重发
- 分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作
CAP
-
分布式系统不可能同时满足
- 一致性（Consistency）
- 分区容忍性（Partition Tolerance）
- 可用性（Availability）
-
权衡
- 分区容忍性必不可少，可用性和一致性的权衡
- 为了保证一致性，不能访问未同步完成的节点，就失去了部分可用性
- 为了保证可用性，允许读取所有节点的数据，但是数据可能不一致
BASE
-
概念
-
基本可用（Basically Available）
- 分布式系统在故障的时候保证核心可用，允许损失部分可用性
-
软状态（Soft State）
- 允许系统中的数据存在中间状态，并认为该中间状态不会影响整体可用性
-
最终一致性（Eventually Consistent）
- 系统中的所有数据副本在经过一段时间的同步后，最终能达到一致性的状态
-
竞选协议
-
Paxos
-
执行过程
- Prepare
- Accept
- Learn
-
约束条件
- 正确性
- 可终止性
-
-
Raft
集群
负载均衡
-
算法
-
轮询
- 服务器性能均衡的场景
-
加权轮询
- 轮询的基础上根据权重分配
-
最少连接
- 将请求发送给当前最少连接的服务器上
-
加权最少连接
- 根据权重结算最少连接
-
随机算法
-
源地址哈希
- 对客户端IP计算哈希值取模
-
-
转发实现
-
HTTP重定向
- 返回302重新发起请求
- 延迟高，处理能力有限
-
DNS域名解析
- 解析域名同时使用负载均衡算法计算服务器IP
- 优点：能根据地理位置进行域名解析，可以返回最近的服务器
- 缺点：DNS多级缓存，当下线机器需要修改DNS记录，生效时间慢
-
反向代理
- Openresty/Nginx
- 缺点：所有请求和响应都要经过反向代理服务器，容易成为瓶颈
-
网络层
-
链路层
- LVS
-
Session管理
-
Sticky Session
-
Session Replication
-
Session Server
- Redis、MySQL
攻击技术
跨站脚本攻击：XSS（Cross-Site Scripting）
跨站请求伪造：CSRF（Cross-Site request forgery）
- 检查Referer头
- 添加token校验
- 验证码
SQL注入
- sql quote预处理
拒绝服务攻击（DoS、DDoS）
一致性哈希
基本原理
- 将哈希空间看做一个环，每个节点都配置在环上，每个数据对象通过哈希取模得到哈希值后，顺时针向前走，存放在碰到第一个节点上
分布不均问题
- 虚拟节点解决
LRU
消息队列
消息模型
-
点对点
- 生产者向MQ中发送了一个消息后，只能被一个消费者消费一次
-
发布/订阅
- 生产者向频道发送了一个消息后，多个消费者可以从该频道订阅这条消息并消费
使用场景
- 异步处理
- 流量削峰
- 应用解耦
可靠性
-
发送端可靠性
- 本地消息表
-
接收端可靠性
- 幂等性
- 唯一消息ID
网友评论