分布式处理

一、什么是Cap CAP 是一个基于 .NET Standard 的 C# 库，它是一种处理分布式事务的解决方案，同样具有 EventBus 的功能，它具有轻量级、易使用、高性能等特点。 在我们构建 SOA 或者 微服务系统的过程中，我们通常需要使用事件来对各个服务进行集成，在这过程中简单的使用消息队列并不能保证数据的最终一致性， CAP 采用的是和当前数据库集成的本地消息表的方案来解决在分布式系统互相调用的各个环节可能出现的异常，它能够保证任何情况下事件消息都是不会丢失的。 你同样可以把 CAP 当做 EventBus 来使用，CAP提供了一种更加简单的方式来实现事件消息的发布和订阅，在订阅以及发布的过程中，你不需要继承或实现任何接口。 以下是CAP集在ASP.NET Core 微服务架构中的一个示意图： 二、安装 你可以运行以下下命令在你的项目中安装 CAP。 PM> Install-Package DotNetCore.CAP CAP 支持 Kafka、RabbitMQ、AzureServiceBus 等消息队列，你可以按需选择下面的包进行安装： PM> Install-Package DotNetCore.CAP.Kafka PM> Install-Package DotNetCore.CAP.RabbitMQ PM> Install-Package DotNetCore

1、关于分布式锁的了解？ 原理：控制分布式系统有序的去对共享资源进行操作，通过互斥来保持一致性。 具备的条件： ①分布式环境下，一个方法在同一时间只能被一个机器的一个线程执行 ②高可用的获取锁和释放锁 ③高性能的获取锁和释放锁 ④具备可重入特性 ⑤具备锁失效机制，防止死锁 分布式锁的三种实现： A. 基于数据库实现分布式锁； B. 基于缓存（Redis等）实现分布式锁； C. 基于Zookeeper实现分布式锁 A.基于数据库的实现： 在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就是用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁 B.基于缓存（Redis等）实现分布式锁： 推荐： Redis有很高的性能； Redis命令对此支持较好，实现起来比较方便 实现： （1）获取锁的时候，使用setnx加锁，并使用expire 命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID,通过此在释放锁的时候进行判断。 （2）获取锁的时候设置一个获取的超时时间，若超过这个时间就放弃获取锁。 （3）释放锁的时候，通过UUID判断是不是该锁，若是该锁，就执行delete进行锁释放。 C.基于Zookeeper的实现方式 原因： Zookeeper是一个为分布式应用提供一致性服务的开源组件

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能，高可用，可伸缩，可扩展的分布式网站进行了概要性描述，并给出一个架构参考。一部分为读书笔记，一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。 #1 大型网站的特点# 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 #2 大型网站架构目标# 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密，安全存储等策略。 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； #3 大型网站架构模式# 分层：一般可分为，应用层，服务层，数据层，管理层，分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应

原文链接: https://www.cnblogs.com/tommyli/p/3766189.html ZooKeeper 典型应用场景一览 数据发布与订阅（配置中心） 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。 分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点，供各个客户端订阅使用。 分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元，因此需要在ZK上创建一个以应用名作为path的节点P，并将这个应用的所有机器ip，以子节点的形式注册到节点P上，这样一来就能够实现机器变动的时候，能够实时通知到收集器调整任务分配。 系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口，例如JMX接口，来获取一些运行时的信息。引入ZK之后，就不用自己实现一套方案了

分布式基础知识 https://www.cnblogs.com/zhang-qc/p/8687663.html 参考 https://github.com/CyC2018/Interview-Notebook/blob/master/notes/ 基本概念 （1）异常： 1. 服务器宕机 　　内存错误、服务器停电等都会导致服务器宕机，此时节点无法正常工作，称为不可用。 　　服务器宕机会导致节点失去所有内存信息，因此需要将内存信息保存到持久化介质上。 2. 网络异常 　　有一种特殊的网络异常称为 网络分区 ，即集群的所有节点被划分为多个区域，每个区域内部可以通信，但是区域之间无法通信。 3. 磁盘故障 　　磁盘故障是一种发生概率很高的异常。 　　使用冗余机制，将数据存储到多台服务器。 （2）超时： 　　可以将服务器的操作设计为具有 幂等性 ，即执行多次的结果与执行一次的结果相同。如果使用这种方式，当出现超时的时候，可以不断地重新请求直到成功。 （3）衡量指标 1. 性能 　　常见的性能指标有：吞吐量、响应时间。这两个指标往往是矛盾的，追求高吞吐的系统，往往很难做到低响应时间。 　　高吞吐意味并发系统，高并发提高 CPU 资源的利用率，但是请求不能马上被处理，需要和其它请求一起进行并发处理，响应时间增高。 2. 可用性：指系统在面对各种异常时可以提供正常服务的能力 3. 一致性

浅谈分布式一致性与CAP/BASE/ACID理论 https://www.cnblogs.com/zhang-qc/p/6783657.html 　　 ##转载请注明 　　CAP理论（98年秋提出，99年正式发表）： C（ Consistency）一致性： 在分布式系统中，数据一致更新，所有数据变动都是同步的； A（ Availability）可用性： 分布式系统中，部分节点故障，系统是否依然可响应客户端请求（对数据更新具备高可用性）； P（ Partition tolerance）分区容错性： 分区是相对于通信的时延要求来讲，指在时延要求内部分节点与其它节点联系不可达，在该情况下系统是否依然可用（可靠性）。该场景下不同于节点宕机情况，可能由于网络交换器故障，使形成不同分区，分区不可达，或者是当前延迟过大，超过了设定的值。 点对点的网络上，复杂的拓扑结构和独立的路由选择可能使连接具有非对称（asymmetric）、非传递的特性，使进程间不可以通信。 由于网络存在延迟和丢包等问题，P性质相对必须满足，所以常在C和A之间进行权衡。CAP理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据

图解分布式一致性协议Paxos https://www.cnblogs.com/hugb/p/8955505.html Paxos协议/算法是分布式系统中比较重要的协议，它有多重要呢？ <分布式系统的事务处理> ： Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。 <大规模分布式存储系统> ： 理解了这两个分布式协议之后(Paxos/2PC)，学习其他分布式协议会变得相当容易。 学习Paxos算法有两部分：a) 算法的原理/证明；b) 算法的理解/运作。 理解这个算法的运作过程其实基本就可以用于工程实践。而且理解这个过程相对来说也容易得多。 网上我觉得讲Paxos讲的好的属于这篇： paxos图解 及 Paxos算法详解 ，我这里就结合 wiki上的实例 进一步阐述。一些paxos基础通过这里提到的两篇文章，以及wiki上的内容基本可以理解。 算法内容 Paxos在原作者的《Paxos Made Simple》中内容是比较精简的： Phase 1 (a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors. (b) If an

1. Git与SVN的主要区别 Git是目前世界上最先进的分布式版本控制系统 SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器那里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，宽带够大，速度够快，如果在联网下，网速慢的话，呃呃呃呃呃 Git是分布式版本控制系统，就是没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就可以不联网，反正都在自己的电脑上，如果两个人需要交流的话，要把各自的修改推送给对方就可以了。 （来自 lenovouser） 2. 什么是集群、分布式、集中式、伪分布式 （1）集中式：将项目等部署到同一台机器上，对机器性能要求比较高，一般会用多台机器进行备份，否则，如果机器出现死机等状况，整个项目将不能运行。例如：你要盖房子，如果只有一个人给你盖，那么这个人如果来不了，你又没找到合适的替代他，那么你的房子只能停工。 （2）分布式：将一个项目分成几块，分别在不同的机器上运行，相比较集中式，对机器的要求有所下降。 （3）集群：与集中式、分布式完全不同的概念，分布式一定是集群，但是集群不一定是分布式（例如：集中式的多机备份） 集群只是相对于机器数量的一个概念 （4）伪分布式：不是真正的分布式

单机模式 例如有一个在线商城系统，如果这个系统业务量很小，比如在校学生自己随便写的一个小项目，所有的代码都放在一个项目store-web中，然后把这个项目部署在一台服务器上。整个项目所有的服务都由这台服务器提供，这就是单机结构。 集群模式 如果业务量增大，一个服务器已经处理不了当前的数据量时，可以采用集群模式。集群模式简单来说，就是将同一份项目代码放在多个服务器上，这多个服务器中每个服务器就是一个节点，所有节点构成一个集群。也就是说每台服务器都跑着相同的项目代码（即store-web)。这样通过将大量请求分配给不同的节点来执行，可以提高系统的处理能力。理论来说有多少个节点系统的处理能力就能提升多少倍。 这里有一个问题就是如何将大量请求分配给集群中不同的节点来执行。这个就涉及到 负载均衡 技术。 负载均衡 负载均衡服务器起着调度者的作用，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一台服务器去处理。负载均衡服务器如何合理分配任务，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡问题。 负载均衡经典的有四种实现方式： HTTP重定向实现负载均衡 DNS负载均衡 反向代理负载均衡 负载均衡组件 分布式架构 还是那个在线商城，如果采用分布式架构，就不能将所有业务塞进一个项目store-web了。需要按照功能模块将业务分解

分布式问题分析 https://www.cnblogs.com/zhang-qc/p/8688052.html 原作者的blog问题写的非常好 先分布式 才能cloud native 参考： https://github.com/CyC2018/Interview-Notebook/blob/master/notes/ 业务中的分布式： 分布式 存储 ：将数据分片到多个节点上，不仅可以提高性能（可扩展性），同时也可以使用多个节点对同一份数据进行备份（高可用性） 分布式 计算 ：将一个大的计算任务分解成小任务分配到多个节点上去执行，再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算最好的例子。 分布式事务： 指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。 产生的原因： 数据库分库分表； SOA 架构，比如一个电商网站将订单业务和库存业务分离出来放到不同的节点上。 解决办法： 1. 两阶段提交协议（很好地解决分布式事务问题） 2. 消息中间件（本质上是一个暂存转发消息的一个中间件） 处理模型：（1）点对点；（2）发布/订阅 负载均衡的算法与实现： 算法有轮询（Round Robin）、加权轮询、最少连接（将请求发送给当前最少连接数的服务器）、加权最小连接、随机算法 上面的没有加权的适合服务器性能差不多场景 Zookeeper 分布式锁