分布式部署

课程简介： 升级版的内容特色： 面向人群： 学习收益： 课程大纲： 第一课 静态网页爬虫：爬虫的基础技术 HTML CSS 选择器 JavaScript 介绍 lxml 及 XPath Python 里的网络请求 高速位缓存设计：BloomFilter 第一个爬虫：蚂蜂窝的游记 第二课 登录及动态网页的抓取 表单 网站登录及Cookie Headless 的浏览器：PhantomJS 浏览器的驱动：Selenium 动态网页数据获取 第三课 微博的抓取 微博网站分布及结构分析 通过动态页面来抓取 微博网络接口的逆向分析 Java 的反编译 加密库 源代码的接口分析 第四课 多线程与过进程的爬虫 第五课 微博数据的存储：分布式数据库及应用 SQL 与 NoSQL Hadoop 架构 HDFS HBase MongoDB Redis 基于分布式数据库的分布式爬虫 第六课 多机并行的微博抓取：分布式系统设计 Socket 编程 Master 设计 Slave 设计 任务调度及通信协议 分布式集群部署的爬虫 第七课 分布式系统进阶：复杂的分布式机制 分布式应用协调服务：ZooKeeper 分布式消息队列管理：RabbitMQ/Kafka 服务发布及注册 灰度升级 第八课 微博数据查询：分布式数据库系统的优化及负载均衡 复制与分片 流量控制及均衡 分布式事物及锁 Redis 的核心技术介绍

前言 随着互联网的发展，各种高并发、海量处理的场景越来越多。为了实现高可用、可扩展的系统，常常使用分布式，这样避免了单点故障和普通计算机cpu、内存等瓶颈。 但是分布式系统也带来了数据一致性的问题，比如用户抢购秒杀商品多台机器共同执行出现超卖等。有些同学容易将分布式锁与线程安全混淆，线程安全是指的线程间的协同。如果是多个进程间的协同需要用到分布式锁，本文总结了几种常见的分布式锁。 基于数据库 悲观锁―事务 比如用户抢购秒杀商品的场景，多台机器都接收到了抢购的请求，可以将获取库存、判断有货、用户付款、扣减库存等多个数据库操作放到一个事务，这样当一台机器与数据库建立链接请求了抢购商品这个事务，另外的机器只能等这个机器将请求完成才能操作数据库。在实际应用场景中，常常库存与交易是两个独立的系统，这时的事务是一个分布式事务，需要用到两段式、三段式提交。 优点：是比较安全的一种实现方法。 缺点：在高并发的场景下开销是不能容忍的。容易出现数据库死锁等情况。 乐观锁―基于版本号 乐观锁常常用于分布式系统对数据库某张特定表执行update操作。考虑线上选座的场景，用户A和B同时选择了某场次电影的一个座位，都去将座位的状态设置为已售。 设想这样的执行序列： 1、用户A判断该座位为未售状态； 2、用户B判断该座位为未售状态； 3、用户A执行update座位为已售； 4、用户B执行update座位为已售。

集群 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。 分布式 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。 节点 节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中，一个节点表示的是一个操作系统上的进程。 副本机制 副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。 数据副本指在不同的节点上持久化同一份数据，当出现某一个节点的数据丢失时，可以从副本上读取到数据。（张三请假了，李四负责顶替张三的工作）数据副本是分布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现服务的高可用方案。 中间件 中间件位于操作系统提供的服务之外，又不属于应用，他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件，能够让用户关心自己应用的部分。 一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步完善演变过来的。在这个过程中，开发模式、技术架构等都会发生非常大的变化。 阶段一，单应用架构

前言：可能是大佬都觉得简单吧都没有详细的介绍(有介绍，可能是我太小白看不懂，哈哈哈)，捉摸了一段时间把大佬们的文档记录下： 一、各服务器命名和作用（摘自：ET社区） 服务器名称 Manager : 对服务器进程进行管理Realm : 登录服务器 ( 验证账号密码 相当于LoginServer 祖传叫法,你想叫什么随你) Gate : 网关服务器 DB : 数据库服务器 Location : 位置服务器 Map : 地图服务器 Client : 客户端 All Server: 所有服务器集合 各服务器的作用(摘录自文档ET框架笔记): Manager：连接客户端的外网和连接内部服务器的内网，对服务器进程进行管理，自动检测和启动服务器进程。加载有内网组件NetInnerComponent，外网组件NetOuterComponent，服务器进程管理组件。自动启动突然停止运行的服务器，保证此服务器管理的其它服务器崩溃后能及时自动启动运行。 Realm：对Actor消息进行管理（添加、移除、分发等），连接内网和外网，对内网服务器进程进行操作，随机分配Gate服务器地址。内网组件NetInnerComponent，外网组件NetOuterComponent，Gate服务器随机分发组件。客户端登录时连接的第一个服务器，也可称为登录服务器。 Gate：对玩家进行管理，对Actor消息进行管理（添加

一、案例分析 1、案例概述 在ESXi的虚拟机之间确保正常通信的基础是网络服务，通常在物理网络中需要使用不同的物理设备进行连接才能组建出稳定高效的网络服务，而在虚拟网络中，需要不同的虚拟设备为其提供服务。本案例主要介绍Vmware虚拟化体系中的另一个重要成员――网络服务。 二、案例前知识点 1、ESXi网络概述 1）物理网络 物理网络是在ESXi主机上运行的虚拟机之间为了互相通信而相互逻辑连接所形成的网络。ESXi主机可以有多个物理网卡，虚拟机也可以创建多个虚拟网卡，将其同时连接到虚拟交换机可实现虚拟机之间的互相通信。 2）虚拟网络 虚拟网络是在ESXi主机上运行的虚拟机之间为了互相通信而相互逻辑连接所形成的网络。ESXi主机可以有多个物理网卡，虚拟机也可以创建多个虚拟网卡，将其同时连接到虚拟交换机可实现虚拟机之间的相互通信。 2、ESXi网络组件 1）物理网卡 物理网卡简称vmnic，如下图所示，ESXi内核的第一块称为vmnic0，第二块称为vmnic1，以此类推。ESXi主机可以有多个vmnic连接不同的物理网络设备，如交换机、路由器、iSCSI存储等。 2）虚拟网卡 虚拟网卡简称vNIC，每台虚拟机都可以有多个虚拟网卡，用于连接虚拟交换机，确保相互之间的正常通信。如下图所示，可以看出每台虚拟机都有自己的虚拟网卡。 3）虚拟交换机 虚拟交换机简称vSwitch

背景：调度机在windows环境，两台执行机在linux环境 linux环境上传《jdk-8u181-linux-x64.tar》和《apache-jmeter-4.0.zip》安装包 1.安装jdk 配置java环境变量 1）vi /etc/profile，在最后面增加两行 2）执行命令：source /etc/profile，无需重启，配置的环境变量立马生效 3）查看是否安装成功，执行命令：java -version 2.安装jmeter 将本地的Jmeter文件打包成zip文件：apache-jmeter-4.0.zip，再上传到服务器/usr/local 在服务器解压缩，生成apache-jmeter-4.0目录 配置Jmeter环境变量。 1）vi /etc/profile，再添加如下变量 2）source /etc/profile （让配置文件立马生效） 3）查看是否安装成功，执行命令：jmeter -v 3.jmeter分布式部署 执行机部署 进入bin文件夹，修改jmeter.properties配置， 1）remote_hosts=执行机ip，端口统一设置为1090 remote_hosts=172.16.23.229 server_port=1090 server.rmi.localport=1090 2）“#server.rmi.ssl.disable

原文链接：https://blog.csdn.net/weixin_38003389/article/details/89434629 redis 集群做分布式锁，我们使用 Redisson。 框架 版本 Spring Boot 2.0.3.RELEASE Spring Cloud Finchley.RELEASE redis redis-4.0.11 JDK 1.8.x maven配置 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.3.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom<

本文以三台机器为例，分别为bigdata111，bigdata112，bigdata113三台机器，先部署bigdata111机器，然后通过scp分发配置方式配置其他两台机器； 利用rz命令，上传zookeeper的gz包到/opt/soft/文件夹下。 [root@bigdata111 soft]# rz [root@bigdata111 soft]# ls hadoop-2.8.4.tar.gz jdk-8u144-linux-x64.tar.gz zookeeper-3.4.10.tar.gz 通过tar命令解压zookeeper到/opt/module/目录下。 [root@bigdata111 soft]# tar -zvxf zookeeper-3.4.10.tar.gz -C /opt/module/ [root@bigdata111 soft]# cd /opt/module/ [root@bigdata111 module]# ls hadoop-2.8.4 jdk1.8.0_144 zookeeper-3.4.10 在zookeeper的解压目录下新建zkData文件夹，用于数据文件目录+数据持久化路径。 [root@bigdata111 module]# cd zookeeper-3.4.10/ [root@bigdata111 zookeeper-3.4

世上本没有坑，挖的人多了，自然就有坑了。 公司最近要搭一个分布式集群来训练数据，作为一个无知而又热爱求知的小白，自然被虐得头发都掉了一地。 花了整整2.5个星期后，终于在开源哥们的指导下才大概估计到原因所在，最后才在华为的一个技术贴上找到答案，那时候真是Duang的一声，看着进程终于跑起来的那一刻，真的是想来个夕阳下的奔跑来庆祝一下。这过程真的不容易啊，期间基本把google和百度的资料不管相关和不相关都翻了个遍，也没有很好解决问题，那时候心态是真的爆炸了，最后改了一下关键字，才在谷歌结果的最后一页看到华为的帖子有那么几个字相关，没想到点开后就打开了新世界，激动!!!!! 扯淡到此为止，现在来介绍一下部署细节。 本部署是基于ubuntu 16.04 + hadoop + spark + tensorflowOnSpark + tensorflow 1.8 这里集群的环境是1个ps和2个worker hadoop和spark的部署这里不做叙述，网上的资料一大堆，按照来基本上没有问题，有问题的话再找一个其它靠谱的再配，反正最终能运行就可以了。 这里是采取yarn作为资源管理器，具体安装过程可以参考 官网 。网上很多文章都说官方说明文档简略，但是其实踩完坑后发觉，其实真的就这么简略，跑不起来，大多是和自身集群的配置有关。所以这些坑得自己填，官方也只能给提示。 一句话，

为了让jmeter工具提供更强大的负载能力，jmeter提供了多台机器同时产生负载的机制。 一、申请5台Linux服务器，配置好点。 二、分布式测试原理：其中一台作为主控机/调度机（server），其他为压力机（agent） 三、处理过程： 　　1）调度机server启动以后，会拷贝本地的jmx文件分发到远程的agent机器上； 　　2）agent机器拿到脚本以后启动命令行模式去执行脚本，对于每台agent机器拿到的脚本都是一样的，所以如果jmx脚本为50个线程跑3分钟，那么实际并发就是50*5=250个线程并发跑3分钟； 　　3）执行时，agent会把执行获得的数据结果传给server机器，server机器会收集所有agent机器的信息并汇总，这样server机器上就存在一份所有agent机器汇总的数据结果。 四、Jmeter分布式压测环境搭建 　　1、分布式环境压力服务器要求： 　　需要server（控制机）和agent（压力机），agent搭建在linux服务器环境下，server搭建在Linux或windows环境下。 　　压力测试瓶颈大都在带宽上面，需要保证压力机的带宽要比服务器的带宽高，不然压力上不去。 　　需要保证agent和server都在一个网络中，且在多网卡环境需要保证启动的网卡都在一个网段。 　　需要保证server和agent之间的时间同步。 　　关闭防火墙