分布式技术

1. 为什么要学习Jmeter分布式部署？ 1.1 需求 1. 对学院接口(查询学院-所有)进行1000用户并发访问，测试服务器处理批量请求能力 1.2 问题 1. 我们单台电脑由于配置(CPU、内存)问题，最模拟500用户时，就出现卡死现象 2. 什么是分布式？ 概念：由多台电脑共同完成同一1个任务(请求)部署，我们称这种部署为分布式部署 2.1 分布式原理 1. 一台电脑作为控制机(Controller)，其它电脑做为执行机(Agent); 2. 执行时，控制机会把脚本发送到每台执行机上，执行机拿到脚本后就开始执行 3. 执行机执行时不需要启动Jmeter界面，可以理解它是通过命令行模式执行的 4. 执行完成后，执行机会把结果回传给控制机，控制机会收集所有执行机的信息并汇总 2.1 解决方案分析 1. 1台电脑(控制机)分发执行任务 2. 2台电脑(执行机)执行任务 3. 在执行机上启动监听服务程序 4. 在控制机上启动运行 5. 测试计划->聚合报告 2.2 技术难点分析 1. 执行机-jmeter.properties设置 2. 控制机jmeter.properties设置 3. 执行机启动分布式监听服务程序 3. 2台执行机,用户数如何设置 2.3 执行机Jmeter.properties配置图 1. 打开bin目录下jmeter.properties配置文件 2.

在使用Jmeter进行性能测试时，如果并发数比较大(比如项目需要支持上万的并发量)，单台PC的配置(CPU和内存)可能无法支持，这时可以使用Jmeter提供的分布式测试的功能。 根据目前PC的配置：4.00G内存，可以最多达到2000左右的并发数量。那么对于支持上万的并发量，一台PC是很难实现的。 Jmeter分布式执行原理 1 Jmeter分布式测试时，选择其中一台作为调度机(master)，其它机器做为执行机(slave)。 2 执行时，master会把脚本发送到每台slave上，slave 拿到脚本后就开始执行，slave执行时不需要启动GUI，我理解它应该是通过命令行模式执行的。 3 执行完成后，slave会把结果回传给master，master会收集所有slave的信息并汇总。 执行机（slave）配置 1 slave机上需要安装Jmeter，具体如何安装这里不详细介绍了。 2 添加环境变量：JMETER_HOME=D: \apache-jmeter-3.0，此处为你Jmeter的路径 3 启动bin目录下的：jmeter-server.bat，启动成功如下图： 4 上图上标红的IP和端口会在master里配置时用到。IP就是slave机器IP，端口默认是1099. 5 如果需要多台slave的话，那么重复1~4步骤就好。 调度机配置 1 找到Jmeter的bin目录下

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

1、好多公司动不动就JVM、高并发、分布式、微服务等等，我没有实际经验。 2、从事Java开发三年了，目前的职位是高级Java工程师，感觉技术和工资都到了瓶颈，对以后的发展方向有些迷茫。 3、加班时间过长，年龄大了，精力严重不够，竞争力远不如年轻程序员了。 4、Java工程师体量庞大，供大于需，导致Java程序员面临更加激烈的竞争。 5、目前做技术管理，薪资25K，但25K基本是天花板了，不甘心。 　　在我看来，开发三年甚至五六年以上的Java程序员要解决上面的问题无非就是两个层面： 1、技术经验 　　在技术经验方便，个人感觉你要想有所突破，首先就要形成一套技术体系，从技术的实现原理到技术应用，再到不同技术的优劣比较。因为当前各大公司使用的如火如荼的技术栈，无怪乎那些你已经曾经使用过的东西，只是你需要在这个基础上，让自己更有深度和见解。 2、业务需求能力 　　在业务需求能力方面，一个公司除了看重技术积累方面，另外还比较注重个人的业务理解和分析能力，如果你在某个领域的业务能力比较强，能够hold住当前的一个业务架构，这样说明你对业务的理解能力是非常到位的。所以在业务方便，首先需要的是结合场景的个人理解，其次是延伸扩展。 　　裁员并不可怕，没有技术实力才可怕，真正有实力的人不会被埋没。真正有实力的人才能走的更远飞的更高。当你具备这些能力时，你不用担心裁员而是应该考虑我要不要继续留在

1.Redis 缓存和 MySQL 数据如何实现一致性 需求起因 缓存和数据库一致性解决方案 　　在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。 　　读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。 　　不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。 　　举一个例子： 1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。 2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况 。 　　因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。 　　如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。 缓存和数据库一致性解决方案 1.第一种方案：采用延时双删策略 　　在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。 伪代码如下 public void write(String key,Object data){ redis

在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，同时由于网络闪断等原因，分布式调用失败的风险也增大。如果服务框架没有足够的容错能力，业务失败率将会大幅提升。 除了性能、可靠性等问题，跨节点的事务一致性问题、分布式调用带来的故障定界困难、海量微服务运维成本增加等也是分布式服务框架必须要解决的难题。本章节我们将对服务化之后面临的挑战进行分析，并给出解决方案和业务最佳实践。 1. 性能和时延问题 在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗： 1） 客户端需要对消息进行序列化，主要占用CPU计算资源。 2） 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。 3） 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。 4） 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。 5） 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。 6） 服务端将响应结果序列化，占用CPU计算资源。 7） 服务端将应答码流发送给客户端，占用网络带宽资源。 8） 客户端读取应答码流，反序列化成响应消息，占用CPU资源。

FROM： https://www.cnblogs.com/jajian/p/10014145.html 之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 1 | 0 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 2 | 0 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子

你如何考虑服务化 # 集中式与分布式 要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。 # 集中式 集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。 集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 # 分布式 分布式就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 拿电商网站来说，我们一般把一个电商网站横向拆分成商品模块、订单模块、购物车模块、消息模块、支付模块等。然后我们把不同的模块部署到不同的机器上，各个模块之间通过远程服务调用( RPC )等方式进行通信。以一个分布式的系统对外提供服务。 # 服务化 提到分布式，一个不得不提的词就是服务化

谈谈业务中使用分布式的场景 首先，需要了解系统为什么使用分布式。 随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面： 1.应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。 2.底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。 #场景1：应用系统集群的 Session 共享 应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。 #场景2：应用系统的服务化拆分 服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。 #场景3：底层数据库的压力分摊 如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。 Session 分布式方案 #基于 nfs(net filesystem) 的 Session 共享 将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制

课程介绍 微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建，或者当现有架构已到达瓶颈需要进行架构演进时，很多架构师、运维工程师会考虑是否需要搭建微服务架构体系。虽然很多文章都说微服务架构是复杂的、会带来很多分布式的问题，但只要我们了解这些问题，并找到解法，就会有种拨开云雾的感觉。 微服务架构也不是完美的，世上没有完美的架构，微服务架构也是随着业务、团队成长而不断演进的。最开始可能就几个、十几个微服务，每个服务是分库的，通过 API Gateway 并行进行服务数据合并、转发。随着业务扩大、不断地加入搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。 本课程会一一解开微服务架构下分布式场景的问题，以及通过对于一些分布式技术的原理、模型和算法的介绍，来帮助想要实施微服务架构的工程师们知其然并知其所以然。并且，本课程通过对分布式问题的体系化梳理，结合一些方案的对比选型，可以让工程师们一览微服务的知识图谱。 注：为了方便初学者理解微服务实践，以及掌握怎样在微服务中使用 DDD（Domain-Driven Design）思想，在本课程第 05 课中讲解了 Demo 示例，该示例是基于 Spring Boot、Spring Cloud Eureka 技术写的，Microservice 代码详见这里，Gateway 代码详见这里。 专家推荐