大家好我是咸鱼了大半年的一灰灰，终于放暑假了，把小孩送回老家，作为咸鱼的我也可以翻翻身了，接下来将趁着暑假的这段时间，将准备一个全新的分布式专栏，为了给大家提供更好的阅读体验，可以再我的个人站点上查看系列的专栏内容：
https://hhui.top/分布式1.架构设计 冗余：简单理解为找个备胎，现任挂掉之后，备胎顶上 拆分：不能让一个人承担所有的重任，拆分下，每个人负担一部分，压力均摊 1.1 主备架构 人工 VIP(虚拟ip) + keepalived 机制 1.2 主从架构 添加从，源头依然是数据冗余的思想 读写分离：主负责读写，从只负责读，可以视为负载均衡策略 从需要向主同步数据，所若有的从都同步与主，对主的压力依然可能很大；所以就有了主从从的模式 关键问题则在于1.3 多主多从架构 1.4 普通集群模式 资源竞争：如何确保一个资源在同一时刻只能被一个业务操作 如现在同时来了申请退款和货物出库的请求，如果不对这个订单进行加锁，两个请求同时响应，将会导致发货又退款了，导致财货两失 数据一致性：如何确保所有的实例数据都是一致的，或者最终是一致的 如应用服务使用jvm缓存，那么如何确保所有实例的jvm缓存一致？ 如Eureka的分区导致不同的分区的注册信息表不一致 1.5 数据分片架构 这个分片模型的描述可能并不准确，大家看的时候重点理解一下这个思想1.6 一灰灰的小结 对于拆分这一块，我们常说的分库分表也体现的是这一思想2.理论基础 一致性算法-Gossip协议详解 - 腾讯云开发者社区-腾讯云 P2P 网络核心技术：Gossip 协议 - 知乎 从Paxos到Raft，分布式一致性算法解析_mb5fdb0a87e2fa1的技术博客_51CTO博客 【理论篇】浅析分布式中的 CAP、BASE、2PC、3PC、Paxos、Raft、ZAB - 知乎 2.1 CAP定理 不可能 同时提供下面三个要求： Consistency：一致性 操作更新完成并返回客户端之后，所有节点数据完全一致 Availability：可用性 Partition tolerance：分区容错性 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性 和可用性 的服务 通常来讲P很难不保证，当服务部署到多台实例上时，节点异常、网络故障属于常态，根据不同业务场景进行选择2.2 BASE理论 Basically Available: 基本可用 指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用 如大促时降级策略 Soft State：软状态 允许系统存在中间状态，而该中间状态不会影响系统整体可用性 MySql异步方式的主从同步，可能导致的主从数据不一致 Eventual Consistency：最终一致性 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态 基于上面的描述，可以看到BASE理论适用于大型高可用可扩展的分布式系统2.3 PACELEC 定理 这个真没听说过，以下内容来自:
Distributed System Design Patterns | by Nishant | Medium 如果有一个分区（'P'），分布式系统可以在可用性和一致性（即'A'和'C'）之间进行权衡; 否则（'E'），当系统在没有分区的情况下正常运行时，系统可以在延迟（'L'）和一致性（'C'）之间进行权衡。 2.4 Paxos共识算法 Paxos算法解决的问题是分布式共识性问题，即一个分布式系统中的各个进程如何就某个值（决议）通过共识达成一致 一个或多个提议进程 (Proposer) 可以发起提案 (Proposal)， Paxos算法使所有提案中的某一个提案，在所有进程中达成一致。 系统中的多数派同时认可该提案，即达成了一致 角色划分: Proposer: 提出提案Proposal，包含编号 + value Acceptor: 参与决策，回应Proposers的提案；当一个提案，被半数以上的Acceptor接受，则该提案被批准 Learner: 不参与决策，获取最新的提案value 2.5 Raft算法 推荐有兴趣的小伙伴，查看
Raft 算法动画演示
Raft算法详解 - 知乎 Leader：领导者，接受客户端请求，并向Follower同步请求，当数据同步到大多数节点上后告诉Follower提交日志 Follow: 接受并持久化Leader同步的数据，在Leader告之日志可以提交之后，提交 Candidate：Leader选举过程中的临时角色，向其他节点拉选票，得到多数的晋升为leader，选举完成之后不存在这个角色 2.6 ZAB协议 ZAB(Zookeeper Atomic Broadcast) 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议，基于该协议，ZooKeeper 实现了一种 主从模式的系统架构来保持集群中各个副本之间的数据一致性。
zookeeper核心之ZAB协议就这么简单！角色划分 Leader: 负责整个Zookeeper 集群工作机制中的核心 事务请求的唯一调度和处理者，保证集群事务处理的顺序性 集群内部各服务器的调度者 Follower：Leader的追随者 处理客户端的非实物请求，转发事务请求给 Leader 服务器 参与事务请求 Proposal 的投票 参与 Leader 选举投票 Observer：是 zookeeper 自 3.3.0 开始引入的一个角色， 它不参与事务请求 Proposal 的投票， 也不参与 Leader 选举投票 只提供非事务的服务（查询），通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力。 2.7 2PC协议 two-phase commit protocol，两阶段提交协议，主要是为了解决强一致性，中心化的强一致性协议角色划分 协调节点(coordinator)：中心化 参与者节点(partcipant)：多个 执行流程 特点 协调节点的单点故障 第一阶段全部ack正常，第二阶段存在部分参与者节点异常时，可能出现不一致问题 2.8 3PC协议 分布式事务：两阶段提交与三阶段提交 - SegmentFault 思否第一阶段 cancommit 第二阶段 precommit 第三阶段 docommit 特点 降低了阻塞与单点故障： 参与者返回 CanCommit 请求的响应后，等待第二阶段指令，若等待超时/协调者宕机，则自动 abort，降低了阻塞； 参与者返回 PreCommit 请求的响应后，等待第三阶段指令，若等待超时/协调者宕机，则自动 commit 事务，也降低了阻塞； 数据不一致问题依然存在 比如第三阶段协调者发出了 abort 请求，然后有些参与者没有收到 abort，那么就会自动 commit，造成数据不一致 2.9 Gossip协议 Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。Gossip 协议通过上面的特性，可以保证系统能在极端情况下（比如集群中只有一个节点在运行）也能运行
P2P 网络核心技术：Gossip 协议 - 知乎工作流程 周期性的传播消息，通常周期时间为1s 被感染的节点，随机选择n个相邻节点，传播消息 每次传播消息都选择还没有发送过的节点进行传播 收单消息的节点，不会传播给向它发送消息的节点 特点 扩展性：允许节点动态增加、减少，新增的节点状态最终会与其他节点一致 容错：网络中任意一个节点宕机重启都不会影响消息传播 去中心化：不要求中心节点，所有节点对等，任何一个节点无需知道整个网络状况，只要网络连通，则一个节点的消息最终会散播到整个网络 一致性收敛：协议中的消息会以一传十、十传百一样的指数级速度在网络中快速传播，因此系统状态的不一致可以在很快的时间内收敛到一致。消息传播速度达到了 logN 简单：Gossip 协议的过程极其简单，实现起来几乎没有太多复杂性 缺点 消息延迟：节点只会随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网的，因此使用 Gossip 协议会造成不可避免的消息延迟 消息冗余：节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，导致消息的冗余 2.10 一灰灰的小结 BASE，CAP，PACELEC理论：构建稳定的分布式系统应该考虑的方向 paxos,raft共识算法 zab一致性协议 gossip消息同步协议 3.算法 3.1 一致性hash算法 注意： redis集群实现了一套hash槽机制，其核心思想与一致性hash比较相似 3.2 Quorum NWR算法 用来保证数据冗余和最终一致性的投票算法，其主要数学思想来源于鸽巢原理
分布式系统之Quorum （NRW）算法-阿里云开发者社区 N 表示副本数，又叫做复制因子（Replication Factor）。也就是说，N 表示集群中同一份数据有多少个副本 W，又称写一致性级别（Write Consistency Level），表示成功完成 W 个副本更新写入，才会视为本次写操作成功 R 又称读一致性级别（Read Consistency Level），表示读取一个数据对象时需要读 R 个副本, 才会视为本次读操作成功 Quorum NWR算法要求每个数据拷贝对象 都可以投1票，而每一个操作的执行则需要获取最小的读票数，写票数；通常来讲写票数W一般需要超过N/2，即我们通常说的得到半数以上的票才表示数据写入成功3.3 PBFT拜占庭算法 客户端向主节点发起请求，主节点接受请求之后，向其他节点广播 pre-prepare 消息 节点接受pre-prepare消息之后，若同意请求，则向其他节点广播 prepare 消息； 当一个节点接受到2f+1个prepare新消息，则进入commit阶段，并广播commit消息 当收到 2f+1 个 commit 消息后（包括自己），代表大多数节点已经进入 commit 阶段，这一阶段已经达成共识，于是节点就会执行请求，写入数据 相比 Raft 算法完全不适应有人作恶的场景，PBFT 算法能容忍 (n 1)/3 个恶意节点 (也可以是故障节点)。另外，相比 PoW 算法，PBFT 的优点是不消耗算 力。PBFT 算法是O(n ^ 2) 的消息复杂度的算法，所以以及随着消息数 的增加，网络时延对系统运行的影响也会越大，这些都限制了运行 PBFT 算法的分布式系统 的规模，也决定了 PBFT 算法适用于中小型分布式系统3.4 PoW算法 A转账给B，交易信息记录在一个区块1中 A转账给C，交易信息被记录在另一个区块2中 当区块1被矿工成功提交到链上，并被大多数认可（通过校验区块链上的hash值验证是否准确，而这个hash值体现的是矿工的工作量），此时尚未提交的区块2则会被抛弃 若区块1被提交，区块2也被提交，各自有部分人认可，就会导致分叉，区块链中采用的是优选最长的链作为主链，丢弃分叉的部分（这就属于区块链的知识点了，有兴趣的小伙伴可以扩展下相关知识点，这里就不展开了） PoW的算法，主要应用在上面的区块提交验证，通过hash值计算来消耗算力，以此证明矿工确实有付出，得到多数认可的可以达成共识3.5 一灰灰的小结 分区的一致性hash算法: 基于hash环，减少节点动态增加减少对整个集群的影响；适用于数据分片的场景 适用于一致性的Quorum NWR算法: 投票算法，定义如何就一个提案达成共识 PBFT拜占庭容错算法: 适用于集群中节点故障、或者不可信的场景 区块链中大量使用的工作量证明PoW算法: 通过工作量证明，认可节点的提交 4.技术思想 4.1 CQRS DDD 中的那些模式 — CQRS - 知乎
详解CQRS架构模式_架构_Kislay Verma_InfoQ精选文章4.2 复制负载平衡服务 分布式系统设计:服务模式之复制负载平衡服务 - 知乎
负载均衡调度算法大全 | 菜鸟教程4.3 心跳机制 4.4 租约机制 case1 分布式锁 case2 raft算法的任期 4.5 Leader & Follow 4.6 Fencing 资源屏蔽：系统会阻止以前处于活动状态的领导者访问执行基本任务所需的资源。 节点屏蔽：系统会阻止以前处于活动状态的领导者访问所有资源。执行此操作的常见方法是关闭节点电源或重置节点。 4.7 Quorum法定人数 4.8 High-Water mark高水位线 4.9 Phi 累计故障检测 4.10 Write-ahead Log预写日志 事务提交的流程中，先写redolog precommit， 然后写binlog，最后再redolog commit；当redolog记录成功之后，才表示事务执行成功； 因此当出现上面的宕机恢复时，则会加载redologo，然后重放对应的命令，来恢复未持久化的数据 ElasticSearch: 在内存中数据生成段写到操作系统文件缓存前，会先写事务日志，出现异常时，也是从事务日志进行恢复 4.11 分段日志 4.12 checksum校验 4.13 一灰灰的小结 Distributed System Design Patterns | by Nishant | Medium 这一节主要简单的介绍了下分布式系统中应用到的一些技术方案，如有对其中某个技术有兴趣的小伙伴可以留言，后续会逐一进行补全5.分布式系统解决方案 5.1 缓存 redis的性能高于mysql 如内存的读写，远高于磁盘IO，文件IO 磁盘顺序读写 > 随机读写 用好缓存可以有效提高应用性能，下面以一个普通的java前台应用为例说明 JVM缓存 -> 分布式缓存(redis/memcache) -> mysql缓存 -> 操作系统文件缓存 -> 磁盘文件 缓存面临的核心问题，则在于 一致性问题：缓存与db的一致性如何保障（相信大家都听说过或者实际处理过这种问题） 数据完整性：比如常见的先写缓存，异步刷新到磁盘，那么缓存到磁盘刷新这段时间内，若宕机导致数据丢失怎么办？ TIP: 上面这个问题可以参考mysql的redolog 5.2 全局唯一ID uuid 数据库自增id表 redis原子自增命令 雪花算法 (原生的，扩展的百度UidGenerator, 美团Leaf等) Mist 薄雾算法 5.3 分布式锁 基于数据库实现分布式锁 Redis实现分布式锁（应用篇） | 一灰灰Learning 从0到1实现一个分布式锁 | 一灰灰Learning etcd实现分布式锁 基于consul实现分布式锁 5.4 分布式事务 下单扣库存 用户下单，付钱 此时订单服务，会生成订单信息 支付网关，会记录付款信息，成功or失败 库存服务，扣减对应的库存 一个下单支付操作，涉及到三个系统，而分布式事务则是要求，若支付成功，则上面三个系统都应该更新成功；若有一个操作失败，如支付失败，则已经扣了库存的要回滚（还库存），生成的订单信息回滚（删掉--注：现实中并不会去删除订单信息，这里只是用于说明分布式事务，请勿带入实际的实现方案） 2PC: 前面说的两阶段提交，就是实现分布式事务的一个经典解决方案 3PC: 三阶段提交 TCC：补偿事务，简单理解为应用层面的2PC SAGA事务 本地消息表 MQ事务方案 5.5 分布式任务 互斥性的分布式任务 并存式的分布式任务 同一时刻，所有的实例都可以执行这个任务 续考虑如何避免多个任务操作相同的资源 分布式任务实现方案： Quartz Cluster XXL-Job Elastic-Job 自研： 5.6 分布式Session Session一般叫做会话，Session技术是http状态保持在服务端的解决方案，它是通过服务器来保持状态的。我们可以把客户端浏览器与服务器之间一系列交互的动作称为一个 Session。是服务器端为客户端所开辟的存储空间，在其中保存的信息就是用于保持状态。因此，session是解决http协议无状态问题的服务端解决方案，它能让客户端和服务端一系列交互动作变成一个完整的事务。 session stick：客户端每次请求都转发到同一台服务器(如基于ip的hash路由转发策略） session复制: session生成之后，主动同步给其他服务器 session集中保存：用户信息统一存储，每次需要时统一从这里取(也就是常说的redis实现分布式session方案) cookie: 使用客户端cookie存储session数据，每次请求时携带这个 5.7 分布式链路追踪 zipkin pinpoint SkyWalking CAT jaeger 5.8 布隆过滤器 判定命中的，不一定真的命中 判定没有命中的，则一定不在里面
5.9 一灰灰的小结 6.一灰灰的总结 6.1 综述 主备，主从，多主多从，普通无中心集群，数据分片架构 分布式系统中的理论基石： CAP， BASE, PACELEC 共识算法：paxos, raft, zab 一致性协议：2pc, 3pc 数据同步：gossip 分布式系统中的算法： 分区的一致性hash算法: 基于hash环，减少节点动态增加减少对整个集群的影响；适用于数据分片的场景 适用于一致性的Quorum NWR算法: 投票算法，定义如何就一个提案达成共识 PBFT拜占庭容错算法: 适用于集群中节点故障、或者不可信的场景 区块链中大量使用的工作量证明PoW算法: 通过工作量证明，认可节点的提交 分布式系统解决方案： 分布式缓存 全局唯一ID 分布式锁 分布式事务 分布式任务 分布式会话 分布式链路追踪 布隆过滤器 6.2 题外话 咸鱼太久了，想做一些有意思的东西，活跃一下大脑 准备依托于《分布式专栏》来将自己的知识体系进行归纳汇总，让零散分布在大脑中的知识点能有一个脉络串联起来 不想做架构的码农不是好码农，而想成为一个好的架构，当然得做一些基础准备，向业务精品学习取经 
游戏开发
发布于：2022-08-11 10:00
|
阅读数：434
|
评论：0
QQ好友和群
QQ空间
