沈阳网站怎么推广,下载百度推广app,条形码生成器在线制作图片,个人网站建设作用1. CAP理论
Consistency#xff08;一致性#xff09;#xff1a;用户访问分布式系统中的任意节点#xff0c;得到的数据必须一致。
Availability#xff08;可用性#xff09;#xff1a;用户访问集群中的任意健康节点#xff0c;必须得到相应#xff0c;而不是超时…1. CAP理论
Consistency一致性用户访问分布式系统中的任意节点得到的数据必须一致。
Availability可用性用户访问集群中的任意健康节点必须得到相应而不是超时或拒绝。
Partition tolerance 分区容忍性因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接形成独立分区。在集群出现分区时整个系统也要持续对外提供服务。
2. 一致性级别
CP和AP之间需要做权衡其实根据需求不同也可以将一致性划分为几个级别在这些级别里面做一个权衡 强一致性系统写入什么读出来的也会是什么但实现起来往往对性能影响较大 例如火车站购票有就是有没有就是没有不能出现不一致的情况 典型算法Paxos、Raft、ZAB 弱一致性系统写入成功后不承诺立刻可以读到写入的值也不承诺具体多久后数据能达到一致还可以细分为 会话一致性同一个客户端会话中可以保证一致其他会话不能保证用户一致性同一个用户中可以保证一致其他用户不能保证 例如网上购物在商品详情页看到库存还有好多下单的瞬间才被提示库存数量不足实际上商品详情页展示的库存并不是最新的数据只是在某个流程上才会做准确的检查 最终一致性是弱一致性的特例保证在一定时间内能够达到一个一致的状态 例如转账转账完成后会有一个提示您的转账会在24小时内到账一般用户也能接受但最终必须是一致的 典型算法Gossip
3. Paxos 算法
3.1 问题引入
集群中有N个节点如果一个节点写入后要求同步到剩余N - 1个节点后再向客户端返回 OK虽然看起来最保险但其中任意一个节点同步失败势必造成整个集群不可用能否在此基础上稍微提高可用性呢
我们可以在写操作的时候采用多数派的思想集群节点设置为奇数同步超过集群中 N / 2 个节点成功则向客户端返回 OK。你可能会疑惑当这 N / 2 个节点是写成功了如果此时访问到剩余那些没有同步成功的数据怎么办这里我们先简化一下问题暂不考虑多数派写成功后的读一致性
采用多数派思想其实还存在问题顺序性问题 如上图当S1服务器发送一个自增命令以后此时S5服务器发送了一个set x 0指令S2和S3服务器是正常自增了但S3服务器的 x值 先被设置为 0 后又因为顺序性问题自增为1虽然这两次操作都返回了 OK但此时就产生了各个服务器之间的数据的不一致。
3.2 角色划分和阶段划分
Paxos是一种共识算法目的是解决之前提到的强一致性问题。
Paxos角色划分集群中的每个节点都可以充当 Proposer负责生成提案 注意Paxos 算法允许有多个 Proposer 同时提案但可能会引起活锁问题 Acceptor负责批准提案 Acceptor 如果只有一个的话存在单点问题因此应当有多个 Learner负责获取提案Acceptor批准提案以后会将提案发送给所有 Learner
Paxos阶段划分
执行一个修改操作不是一上来就能执行
准备阶段Proposer 发起提案以后必须由多数派 Acceptor 批准通过后才能进入接受阶段接受阶段Proposer 需要再将要执行的修改操作广播给 Acceptor这次仍然多数派通过此修改才能生效可以返回响应给客户端
3.3 Basic Paxos 算法描述 要点 整个算法分成两个阶段预备阶段前两个箭头接受阶段后两个箭头 预备阶段的目的第一拦截掉旧的方案第二找到最新的 acceptValue 对于 Proposer 预备阶段只发送提案号接受阶段发送提案号 值提案号 n 唯一且全局递增大的提案号有更高的优先级如果见到最新已经接受的值的值就会替换掉 Proposer 自己的值保证一致性 对于 Acceptor 会持久化以下信息 minN最小提案号会在预备阶段和接受阶段被更新为更大的提案号会用来决定 Proposer 是否能选中提案acceptN已接受提案号和acceptValue已接受值会在接受阶段被更新如果 minN n 则不会更新
3.4 顺序性问题回顾
Paxos 算法通过预备和接受两个阶段来解决一致性问题。
情形一 情形二
3.5 缺点
1.效率比较低两轮操作只能选中一个值
2.难于理解算法比较复杂难懂
3.活锁问题
例如
S1 的 1 号提案会被 S5 的 2 号提案所影响导致 1 号提案作废同样的 S5 的 2 号提案也会被 S1 的 3 号提案所影响导致 2 号提案被作废如此循环导致提案都被废弃这就是 Paxos 的活锁问题。
4. Raft 算法
另一种强一致性算法共识算法目的是比 Paxos 更容易理解
Raft 算法演示网站https://raft.github.io/raftscope/index.html
整个 Raft 算法分解成三不分
Leader 选举 只有一个 Server 能作为 Leader一旦此 Server 崩溃选举新的 Leader 执行操作以日志复制为例Log Replication 由 Leader 执行自己的日志记录将日志复制到其他 Server以Leader 的日志为准会覆盖 Server 中不一致的部分多数派记录日志成功Leader 才能执行命令向客户端返回结果 确保安全 确保日志记录的一致性拥有最新日志的 Server 才能成为 Leader
4.1 Leader 选举
Leader 会不断向选民发送 AppendEntries 请求证明自己还活着选民收到 LeaderAppendEntries 请求后会重置自己的 timeout 时间选民收不到 AppendEntries 请求超时后转换角色为候选者并将任期加 1发送 RequestVote 请求推选自己选民收到第一个 RequestVote会向该候选者投一票这样即使有多个候选者必定会选出一个 Leader选票过半即当选落选后变回选民每一任期最多有一个 Leader但也可能没有选票数不过半的情况需要再进行一轮投票timeout在 T~2T 之间随机timeout时间过短会导致 Leader仍然存活时重新选举时间过长会导致选举时间变长整个系统响应速度变慢T是指两个节点之间的通信时间任期由各个 server 自己维护即可无需全局维护在超时后 1在接收到任意消息时更新为更新的任期遇到更旧的任期视为错误
4.2 执行操作日志复制为例
客户端发送命令到 LeaderLeader将命令写入日志Leader向所有选民发送 AppendEntries 请求 在多数派通过后执行命令即提交向客户端返回结果在后续的 AppendEntries 请求中通知选民选民执行命令即提交
4.3 确保安全
Leader 日志的完整性
Leader 被认为拥有最完整的日志一旦 Leader 完成了某条命令的提交那么未来的 Leader 也必须有该条命令提交信息投票时会将候选者最新的 TermIndex随 RequestVote 请求发送如果候选者的日志还没选民的新则投否决票
选民日志的一致性
以 Leader 为例对选民的日志进行补充或覆盖AppendEntries 请求发送时会携带最新的Term, Index, Commend以及上一个的Term, Index如果选民发现上一个的Term, Index能够对应上则成功否则失败继续携带更早的信息进行比对
5. Gossip 协议
与 Paxos 和 Raft 目标是强一致性不同Gossip 达到的是最终一致性 A gossip protocol is a procedure or process of computer peer-to-peer communication that is based on the way epidemics spread. 它可以快速的将信息散播给集群中每个成员散播速度为log N实际传播次数可能会高于此结果因为随机时会随到一些重复的成员
优点
扩展性高传播次数不会受集群成员增长而增长过快容错性好即使某些节点间发生了故障无法通信也不会影响最终的一致性Robust鲁棒性即皮实集群中的节点是对等的即便一些节点挂了一些节点添加进来也不会影响其他节点的信息传播
6. 分布式通用设计
6.1 如何监测节点活着
向节点周期性发送心跳请求如果能收到心跳回应表示该节点还活着
如果收不到心跳回应却不能证明该节点死了可能由于网络抖动、回应延时等原因没能及时收到回应。有如下解决思路
如 Redis 哨兵模式中如果 sentinel 向 master 发送 PING 而没有收到 PONG整你判断主观下线必须采用其他 sentinel 的意见达到多数派后才能判断客观下线进入主备切换流程将周期心跳检测升级为累计心跳检测机制即记录统计该节点的历史响应时间如果超过警戒则发起有限次数的重试作为进一步判定
6.2 如何保证高可用
应用层高可用
关键是做到无状态即所有节点地位平等去 session 化。利用负载均衡将请求发送到任意一台节点进行处理如果有某个节点宕机把该节点从服务列表中移除不会影响业务运行。
服务层高可用
同样要做到无状态此外还应当考虑
核心服务和非核心服务隔离部署分级管理方便非核心服务降级对于即时性没有要求的服务可以考虑采用异步调用优化合理设置超时时间在超时后应当有对应的处理策略如重试、转移、降级等
数据层高可用
需要有数据备份机制与故障转移机制
缓存服务是否需要高可用两种观点
缓存服务不可用会让数据库失去保护因此需要保证缓存服务高可用缓存服务不是数据存储服务缓存宕机应当通过其他手段解决如扩大缓存规模一个缓存服务器的宕机只会影响局部
6.3 如何实现全局唯一ID
Redis
使用 incr 生成 id由于 Redis 的单线程特性能保证它不会重复缺点属于集中式的解决方案有网络消耗
UUID
UUID有多种实现典型的UUID实现会包含时间信息、MAC地址信息、随机数优点属于本地解决方案无网络消耗缺点MAC地址提供了唯一性的保证但也带来安全风险最糟的是它是字符串形式占用空间大查询性能低无法保证趋势递增
Snowflake推荐
通常的实现是 41 位时间信息、精确到毫秒10 位的机器标识、12 位的序列号还有 1 位没有使用共 8 个字节理解思想以后可以根据自己实际情况对原有算法做调整优点本地解决方案无网络小号。长整型避免了字符串的缺点并保证了趋势递增
6.4 负载均衡算法
负载均衡算法用于在多个服务器或节点间分发工作负载以确保各个节点能够有效地处理请求提高系统的性能和可靠性。以下是一些常见的负载均衡算法 轮询Round Robin 将请求依次分配给每个节点循环往复。每个请求按照顺序分发给不同的节点适用于节点性能相近的情况。 加权轮询Weighted Round Robin 类似于轮询算法但给不同节点分配不同的权重使得性能更高的节点能够处理更多的请求。 随机算法Random 随机选择一个节点来处理请求适用于节点性能相差不大且请求相对均匀的场景。 最少连接Least Connections 将请求分配给当前连接数最少的节点。这种方式可以避免请求集中在少数节点上适用于长连接或处理时间较长的场景。 IP哈希IP Hash 根据请求的源IP地址进行哈希计算然后将相同哈希结果的请求发送到同一节点。这种方法可以确保同一客户端的请求始终发送到同一个节点适用于需要保持会话一致性的场景。 最优响应时间Least Response Time 根据节点的实时负载情况和响应时间选择最优节点。这需要实时监控节点的负载和性能指标来进行决策。 最少流量Least Traffic 分配请求到当前流量最小的节点确保整个系统的网络流量尽量均衡。 一致性哈希Consistent Hashing 根据请求的键值对将请求映射到节点通过哈希环的方式确定请求应该由哪个节点处理。这种算法在节点动态变化时能够更好地保持负载均衡。
6.5 数据分片策略
所谓分片就是指数据量较大时对数据进行水平切分让数据分布在多个节点上
1. Hash
按照 key 的 hash 值将数据映射到不同的节点上优点实现简洁、数据分布均匀缺点1如果直接 hash 与节点数取模节点变动时就会造成数据大规模迁移可以使用一致性 hash 改进缺点2查询某一类热点数据时由于它们是用 hash 分散到了不同的节点上造成查询效率不高
2. Range
可以将 key 按照range 进行划分让某一范围的数据都存放在同一节点上优点1按照 range 查询性能更高优点2如果配合动态 range 分片可以将较小的分片合并、将热点数据分散有很多有用的功能
3. 静态调度和动态调度
静态意味着数据分片后分布固定即使移动也需要人工介入动态意味着通过管理器基于调度算法在各个节点之间自由移动数据
7. 分布式事务解决方案
7.1 两阶段提交2PC
两阶段提交2PC 阶段1 - 准备阶段Prepare Phase 协调者Coordinator向所有参与者Participants发送准备请求并等待它们的响应。参与者收到请求后执行事务操作并将准备就绪的消息或“同意”响应返回给协调者。 阶段2 - 提交或回滚阶段Commit or Rollback Phase 如果所有参与者都准备就绪协调者向所有参与者发送提交请求并等待它们的响应。参与者收到提交请求后如果事务执行成功则提交事务并发送“提交完成”响应如果执行失败则回滚事务并发送“回滚完成”响应。
缺点
阻塞型协议所有参与者在等待接到下一步操作前都处于阻塞占用的资源也一直被锁定数据不一致在阶段二如果只有部分参与者收到的提交请求则会造成数据不一致协调者单点问题如果协调者故障在阶段二出现问题会导致所有参与者不会超时始终处于阻塞状态资源也被锁定得不到释放
7.2 TCC事务预留
TCC模式分成三个阶段 Try资源检查和预留 Confirm业务执行和提交 Cancel预留资源的释放
优点
一阶段完成直接提交事务释放数据库资源性能好不依赖数据库事务而是依赖补偿操作可以用于非事务型数据库
缺点
有代码侵入需要人为编写try、confirm和cancel接口太麻烦软状态事务是最终一致需要考虑confirm和cancel的失败情况做好幂等处理
7.3 基于可靠性消息的最终一致性方案
2PC 和 TCC 都属于同步方案实际开发中更多采用的是异步方案
我们可以将问题转换为本地事务与消息投递的原子性
例如下单以后得支付、扣减库存、增加积分等操作对实时性要求并不高。此时将下单成功的消息写入消息中间件利用消息中间件实现最终一致性
