分布式架构

分布式基础知识 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理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据

摘自： https://www.cnblogs.com/powertoolsteam/p/redis.html Redis是什么？看这一篇就够了 本文由葡萄城技术团队编撰并首发 转载请注明出处： 葡萄城官网 ，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。 引言 在Web应用发展的初期，那时关系型数据库受到了较为广泛的关注和应用，原因是因为那时候Web站点基本上访问和并发不高、交互也较少。而在后来，随着访问量的提升，使用关系型数据库的Web站点多多少少都开始在性能上出现了一些瓶颈，而瓶颈的源头一般是在磁盘的I/O上。而随着互联网技术的进一步发展，各种类型的应用层出不穷，这导致在当今云计算、大数据盛行的时代，对性能有了更多的需求，主要体现在以下四个方面： 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理 庞大运营成本的考量：IT部门希望在硬件成本、软件成本和人力成本能够有大幅度地降低 为了克服这一问题，NoSQL应运而生，它同时具备了高性能、可扩展性强、高可用等优点，受到广泛开发人员和仓库管理人员的青睐。 Redis是什么 Redis是现在最受欢迎的NoSQL数据库之一，Redis是一个使用ANSI

关于tensorflow的分布式训练和部署， 官方有个英文的文档介绍，但是写的比较简单， 给的例子也比较简单，刚接触分布式深度学习的可能不太容易理解。在网上看到一些资料，总感觉说的不够通俗易懂，不如自己写一个通俗易懂给大家分享一下。 如果大家有看不懂的，欢迎留言，我再改文章，改到大学一年级的学生可以看懂的程度。 1. 单机多GPU训练 先简单介绍下单机的多GPU训练，然后再介绍分布式的多机多GPU训练。 单机的多GPU训练， tensorflow的官方已经给了一个cifar的例子，已经有比较详细的代码和文档介绍， 这里大致说下多GPU的过程，以便方便引入到多机多GPU的介绍。 单机多GPU的训练过程： a) 假设你的机器上有3个GPU; b) 在单机单GPU的训练中，数据是一个batch一个batch的训练。 在单机多GPU中，数据一次处理3个batch(假设是3个GPU训练）， 每个GPU处理一个batch的数据计算。 c） 变量，或者说参数，保存在CPU上 d） 刚开始的时候数据由CPU分发给3个GPU， 在GPU上完成了计算，得到每个batch要更新的梯度。 e） 然后在CPU上收集完了3个GPU上的要更新的梯度， 计算一下平均梯度，然后更新参数。 f） 然后继续循环这个过程。 通过这个过程，处理的速度取决于最慢的那个GPU的速度。如果3个GPU的处理速度差不多的话，

jmeter分布式-命令行下 说明 配置 报错1： 报错2： 报错3： 运行 说明 基于运行架构，也可以分为两种，即（本地化运行或称单机运行）、远程运行，不论是GUI模式还是非GUI模式，都支持本地运行与远程运行。 本地运行：只运行一台JMeter机器，所有的请求从一台机器发出； 远程运行：一台JMeter控制机（Master）控制远程的多台机器（Slave）来产生负载； 负载机：向被测服务器发起负载请求的机器，与其他支持远程运行的测试工具一样，负载机受控制机管理时首先启动一个客户端Agent程序，控制机才可以接管负载机； 控制机：控制机也是一台负载机，只不过是多台负载机中被选中作为管理机的那台机器，所以控制机也可以参与脚本的运行，同时担负着管理和指挥远程的负载机运行的任务，并且收集远程的负载机的测试结果； 远程运行的逻辑是： 远程机首先启动Agent程序（运行jmeter-server.bat）； 控制机连接上远程负载机（修改配置文件，会自动探测并连接）； 控制机发送指令（脚本及启动命令）启动线程（参数化文件或依赖包需要手工拷贝到远程负载机）； 负载机运行脚本，回传状态（包括测试结果）； 控制机收集结果并显示； 配置 实验都是在一个机器上 报错1： [root@vm bin]# ./jmeter-server Server failed to start: java.rmi

一、JMeter分布式压测介绍 在工作中使用jmeter做大并发压力测试的场景下，单机受限内存、CPU、网络IO，会出现服务器压力还没有上去，但是压测服务器已经由于模拟的压力太大死机了。为了让jmeter工具提供更强大的负载能力，jmeter提供了多台机器同时产生负载的机制，下面是架构图。 二、JMeter分布式压测环境搭建 1.Windows搭建JMeter作为Master 步骤1：安装部署JDK，注意JMeter3必须JDK1.8以上支持。 windows安装部署JDK可参见： https://blog.csdn.net/q13554515812/article/details/83278200 　 步骤2：直接去官网下载最新的二进制源码包即可。 官网下载地址： https://jmeter.apache.org/download_jmeter.cgi 步骤3：解压jmeter到指定目录，配置Jmeter环境变量参见： https://blog.csdn.net/q13554515812/article/details/85096579 2.Linux搭建JMeter作为Slave 步骤1：下载并将Jmeter安装到/opt目录下，命令如下： cd /opt wget http://mirrors.shu.edu.cn/apache//jmeter/binaries

一、架构简介 目标 单机搭建mongodb分布式集群(副本集 + 分片集群)，演示mongodb分布式集群的安装部署、简单操作。 说明 在同一个vm启动由两个分片组成的分布式集群，每个分片都是一个PSS(Primary-Secondary-Secondary)模式的数据副本集； Config副本集采用PSS(Primary-Secondary-Secondary)模式。 二、配置说明 端口通讯 当前集群中存在shard、config、mongos共12个进程节点，端口矩阵编排如下： 编号 实例类型 1 mongos 2 mongos 3 mongos 4 config 5 config 6 config 7 shard1 8 shard1 9 shard1 10 shard2 11 shard2 12 shard2 内部鉴权 节点间鉴权采用keyfile方式实现鉴权，mongos与分片之间、副本集节点之间共享同一套keyfile文件。 官方说明 账户设置 管理员账户：admin/Admin @01 ，具有集群及所有库的管理权限 应用账号：appuser/AppUser @01 ，具有appdb的owner权限 关于初始化权限 keyfile方式默认会开启鉴权，而针对初始化安装的场景，Mongodb提供了 localhost-exception机制 ，

一、架构简介 目标 单机搭建mongodb分布式集群(副本集 + 分片集群)，演示mongodb分布式集群的安装部署、简单操作。 说明 在同一个vm启动由两个分片组成的分布式集群，每个分片都是一个PSS(Primary-Secondary-Secondary)模式的数据副本集； Config副本集采用PSS(Primary-Secondary-Secondary)模式。 二、配置说明 端口通讯 当前集群中存在shard、config、mongos共12个进程节点，端口矩阵编排如下： 编号 实例类型 1 mongos 2 mongos 3 mongos 4 config 5 config 6 config 7 shard1 8 shard1 9 shard1 10 shard2 11 shard2 12 shard2 内部鉴权 节点间鉴权采用keyfile方式实现鉴权，mongos与分片之间、副本集节点之间共享同一套keyfile文件。 官方说明 账户设置 管理员账户：admin/Admin @01 ，具有集群及所有库的管理权限 应用账号：appuser/AppUser @01 ，具有appdb的owner权限 关于初始化权限 keyfile方式默认会开启鉴权，而针对初始化安装的场景，Mongodb提供了 localhost-exception机制 ，

随着微服务架构的流行，一些微服务架构下的问题也会越来越突出，比如一个请求会涉及多个服务，而服务本身可能也会依赖其他服务，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响，所以会深深的感受到 “银弹” 这个词是不存在的，每种架构都有其优缺点 。 目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking， SkyWalking 它是一款优秀的国产 APM 工具，包括了分布式追踪、性能指标分析、应用和服务依赖分析等。 来源： https://www.cnblogs.com/qinwei/p/11929270.html

背景：记录对分布式锁的相关理解，不断提升自己 拜托，面试请不要再问我Redis分布式锁的实现原理！【石杉的架构笔记】 可重入锁 为什么不建议使用redis分布锁 主从切换可能丢失锁信息 考虑一下这样的场景：在分布式环境中，很多并发需要锁来同步，当使用redis分布式锁，通用的做法是使用redis的setnx key value px 这样的命令，设置一个字段，当设置成功说明获取锁，设置不成功说明锁被占用，当获取所之后需要删除锁，也就是删除设置的锁字段，这是锁可以被其他占用。 这里在主从切换回出现问题，当第一个线程在主服务器上设置了锁，但是这时候从服务器并没有及时同步主服务器的状态，也就是没有同步主服务器中的锁字段，而此时，主服务器挂了，redis的哨兵模式升级从服务器为主服务器，如果在并发量大的情况下，虽然第一个线程获取了锁，其他线程会在当前的主服务器（之前的从服务器，但是并没有同步已经设置的锁字段）上设置锁字段，这样并不能保证锁的互斥性。 缓存易失性 假如第一个线程设置了锁，但是之后触发内存淘汰机制很不幸淘汰了设置的锁字段，接下来的线程在第一个线程没有释放锁的情况下，也是重新设置锁字段的，这样并不能保证锁的安全性。 七张图彻底讲清楚ZooKeeper分布式锁的实现原理【石杉的架构笔记】 公平锁 来源： https://www.cnblogs.com/lixuwu/p