分布式部署

浅解.Net分布式锁的实现 序言 我晚上有在公司多呆会儿的习惯，所以很多晚上我都是最后一个离开公司的。当然也有一些同事，跟我一样喜欢在公司多搞会儿。这篇文章就要从，去年年末一个多搞会的晚上说起，那是一个夜黑风高的晚上，公司应该没有几个人在啦，我司一技术男悠悠的走到我的背后，突然一句：“还没走啊？”！“我日，吓死我啦，你也没走啊”。此同事现在已被裁员，走啦，当晚他问我啦一个问题，至此时也没有机会告知，今天我就在这里就简单描述下他当时的问题，其实实现起来简单的不值一提，不过任何一个简单的问题往往都会有很多中解决方案，探索找到最佳的解决方案，然后把细节做好，那就是技术的精髓与乐趣所在。我这里只抛砖一下，希望能给我老同事一个思路。 回到问题 首先有如下二张表，字段有IsBuyed（0：未使用，1：已使用），ProductNo：产品编号，Count：使用次数。 就是针对这张表做需求扩展的。 1、每次请求过来，都随机拿到一个未使用过的产品编号 public int GetNo() { using (IDbConnection conn = GetConn()) { return conn.ExecuteScalar<int>("select top 1 ProductNo from AStore where isBuyed=0 order by newid()"); } } 2、每次请求过来

1. 使用JAVA的UUID生成 算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。 优点：本地生成，生成简单，性能好，没有高可用风险 缺点：长度过长，字母和数字组合，存储冗余，且无序不可读，查询效率低 2. 数据库自增ID 使用数据库的id自增策略，如 MySQL 的 auto_increment、oracle的sequence。并且可以使用两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。 优点：数据库生成的ID绝对有序，高可用实现方式简单 缺点：需要独立部署数据库实例，成本高，实时操作数据库，大并发时存在性能瓶颈问题 3. 数据库+程序（批量生成ID） 一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值。 优点：避免了每次生成ID都要访问数据库并带来压力，提高了性能 缺点：属于本地生成策略，存在单点故障，如果服务器宕机，重启服务造成ID不连续 4. Redis生成ID Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。 优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。 缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度

摘自： 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、Jmeter分布式测试时，选择其中一台作为调度机(master)，其它机器做为执行机(slave)。 　　2、执行时，master会把脚本发送到每台slave上，slave 拿到脚本后就开始执行。 　　3、执行完成后，slave会把结果回传给master，master会收集所有slave的信息并汇总。 　　　 二、执行机（slave）配置： 两台执行机IP分别为192.168.1.11 ， 192.168.1.12 1、在执行机的jmeter的bin目录下，找到jmeter.properties文件，编辑该文件 　　查找： 　　server_port=1099 　　修改为： 　　server_port=8081 　　查找： 　　server.rmi.localport=4000 　　修改为： 　　server.rmi.localport=8081 ２、开启远程接口 　　在IP为192.168.1.11的执行机执行 　　jmeter-server -Djava.rmi.server.hostname=192.168.1.11 　　在IP为192.168.1.12的执行机执行 　　jmeter-server -Djava.rmi.server.hostname=192.168.1.12 　 三、调度机（master）配置： 1

不要一味的百度，然后找到图文并茂的软文，一步一个操作来调试自己本地的服务，当然这是属于菜鸟行列的必备操作。 一、 JMETER分布式执行原理： 1、Jmeter分布式压测，选择本机作为调度机(master)，其它机器做为执行机(agent)，都需要启动jmeter-server； 2、执行时，master会把脚本发送到每台agent上执行，agent执行时不需要启动GUI程序。 3、执行完后，agent会把结果回传给master，master会收集所有agent的信息并汇总报告展示。 二、执行机（agent）配置： 1、agent机上需要安装和调度机完全一样的Jmeter版本(在测试jmeter3.1与5.1的异同) jmeter官网：确保在所有系统上使用相同版本的JMeter和Java。混合版本将无法正常工作。 2、调度机和执行机需再同一网段内（这里有个坑,启动会随机其他网关）系统上的防火墙已关闭或打开了正确的端口。 解决办法：win10系统释放一个wifi信号，笔记本连接即可。 3、启动bin目录下的：jmeter-server.bat；linux启动的是jmeter-server.sh 4、如果分布式配置多台agent，一直重复1~3步就ok了。 三、使用JMeter，完成一台master控制，多台agent执行，即实现多台机器压测master、agent

一、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

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分布式部署的背景 由于Jmeter本身的瓶颈，当需要模拟数以千计的并发用户时，使用单台机器模拟所有的并发用户就有些力不从心，甚至还会引起JAVA内存溢出的错误。要解决这个问题，可以使用分布式测试，运行多台机器运行所谓的Agent来分担JMeter自身的压力，并借此来获取更大的并发用户数，但是需要进行相关的一些修改。（jmeter由Java开发，耗内存、CPU，大量并发需要分布式） 部署方法： 在所有运行的jmeter上，选择一台jmeter作为controller ，其他的的机器作为agent 步骤一： 在controller机器的jmeter的bin目录下，编辑jmeter.properties 文件，编辑内容如下： remote_hosts=remote_hosts=192.168.72.134:1099,192.168.72.1:1099,127.0.0.1:1099 #127.0.0.1代表将本机也作为一个agent；1099为jmeter的controller 和agent 之间进行通信的默认RMI端口号 server.rmi.ssl.disable=true 步骤二： 启动作为agent的所有jmeter机器 启动命令： [root@localhost jmeter]# ./bin/jmeter-server -Djava.rmi.server

一、架构简介 目标 单机搭建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机制 ，