分布式部署

前言 一般单机或者单数据库的项目可能规模比较小，适应的场景也比较有限，平台的访问量和业务量都较小，业务ID的生成方式比较原始但是够用，它并没有给这样的系统带来问题和瓶颈，所以这种情况下我们并没有对此给予太多的关注。但是对于大厂的那种大规模复杂业务、分布式高并发的应用场景，显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成，而且在分布式环境下这种方式已经无法满足业务的需求，不仅无法完成业务能力，业务ID生成的速度或者重复问题可能给系统带来严重的故障。所以这一次，我们看看大厂都是怎么分析和解决这种ID生成问题的，同时，我也将我之前使用过的方式拿出来对比，看看有什么问题，从中能够得到什么启发。 分布式ID的生成特性 在分析之前，我们先明确一下业务ID的生成特性，在此特性的基础上，我们能够对下面的这几种生成方式有更加深刻的认识和感悟。 全局唯一 ，这是基本要求，不能出现重复。 数字类型，趋势递增 ，后面的ID必须比前面的大，这是从MySQL存储引擎来考虑的，需要保证写入数据的性能。 长度短 ，能够提高查询效率，这也是从MySQL数据库规范出发的，尤其是ID作为主键时。 信息安全 ，如果ID连续生成，势必会泄露业务信息，甚至可能被猜出，所以需要无规则不规则。 高可用低延时 ，ID生成快，能够扛住高并发，延时足够低不至于成为业务瓶颈。 分布式ID的几种生成办法

原理图： 步骤： 一、使用ping查看负载机和执行机是否连通 二、执行机配置 　1、在apache-jmeter-5.1.1\bin路径下，打开jmeter.properties文件，在文件中找到remote_hosts，将负载机的IP添加在remote_hosts后面，1099是Jmeter默认端口号，可以随意修改。如果存在多个受控机，需要将IP和端口号全部添加，使用逗号分隔。 　2、在jmeter.properties文件中，server_port为默认端口号，如果存在冲突，需要修改端口号 　3、在jmeter.properties文件中，找到server.rmi.ssl.disable，将注释#去掉，false修改为true 　4、在jmeter.properties文件中，将mode=Standard前面的注释去掉 　5、保存，并在apache-jmeter-5.1.1\bin路径下，打开jmeter-server.bat 三、负载机 　1、在apache-jmeter-5.1.1\bin路径下，打开jmeter.properties文件，在文件中找到remote_hosts，将本机的IP添加在remote_hosts后面，1099是Jmeter默认端口号，可以随意修改。与控制机端口号保持一致。 　2、在jmeter.properties文件中，找到server.rmi

目录 大纲 下载地址 部署机器环境 SSH配置 分布式配置部署 启动 大纲 机器环境及SSH预处理 hadoop安装部署 下载地址 apache索引目录 Index of /dist 此处使用了 hadoop-3.1.2.tar.gz 部署机器环境 共3台机器 172.23.7.9 172.23.7.10 172.23.7.12 在每台机器使用hostname命令，查看机器命名 在每台机器上hosts配置文件 vim /etc/hosts SSH配置 创建ssh，或者使用已有的ssh 创建ssh命令 ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa 将其配置为无密码登录 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 0600 ~/.ssh/authorized_keys 修改/etc/ssh/sshd_config 文件 需要修改的 如果有注释 就打开注释 RSAAuthentication yes PubkeyAuthentication yes #这两项为打开公钥模式 AuthorizedKeysFile .ssh/authorized_keys #配置公钥记录文件 PasswordAuthentication yes #打开密码验证模式 测试 ssh [hostname] 问题：

zabbix概述 Zabbix是什么 Zabbix 是由Alexei Vladishev创建，目前由Zabbix SIA在持续开发和支持。 Zabbix 是一个企业级的分布式开源监控方案。 Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。这些功能使得Zabbix成为容量规划的理想方案。 Zabbix支持主动轮询和被动捕获。Zabbix所有的报告、统计信息和配置参数都可以通过基于Web的前端页面进行访问。基于Web的前端页面可以确保您从任何方面评估您的网络状态和服务器的健康性。适当的配置后，Zabbix可以在IT基础架构监控方面扮演重要的角色。对于只有少量服务器的小型组织和拥有大量服务器的大型公司也同样如此。 Zabbix是免费的。Zabbix是根据GPL通用公共许可证第2版编写和发行的。这意味着它的源代码都是免费发行的，可供公众任意使用。 zabbix定义 在本节中，你可以了解一些Zabbix常用术语的含义。 主机 (host) – 一台你想监控的网络设备，用IP或域名表示 主机组 (host group) – 主机的逻辑组；它包含主机和模板。一个主机组里的主机和模板之间并没有任何直接的关联

一、前言 ​　　随着社会的发展，技术的进步，以前的大型机架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的分布式架构，从大型机到分布式，经历了好几个阶段，我们弄明白各个阶段的架构，才能更好地理解和体会分布式架构的好处，那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。 二、背景说明 ​　　我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的。 在这个过程中，开发模式、技术架构等都会随着迭代发生非常大的变化。 而针对不同业务特征的系统，各自都会有自己的侧重点，例如像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。 ​　　下面我们来简单模拟一个架构演变过程。 我们以 javaweb 为例，来搭建一个简单的电商系统，从这个系统中来看系统的演变过程。要注意的是接下来的演示模型， 关注的是数据量、访问量提升，网站结构的变化， 而不关注具体业务的功能点。其次，这个过程是为了让大家能更好的了解网站演进过程中的一些问题和应对策略。

科技发展带来的挑战 在科技的快速发展推动下，在 IT 领域，企业会面临两个方面的问题。 一是如何实现网站的高可用、易伸缩、可扩展、高安全等目标。为了解决这样一系列问题，迫使网站的架构在不断发展。从单一架构迈向高可用架构，这过程中不得不提的就是分布式。 二是用户规模越来越大，由此产生的数据也在以指数倍增长，俗称数据大爆炸。海量数据处理的场景也越来越多。技术上该如何面对？ 分布式系统 概述 分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅。 仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。 分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 初代的 web 服务网站架构往往比较简单，应用程序、数据库、文件等所有的资源都在一台服务器上。 图：互联网初始阶段的网站架构 图：现在互联网网站常用的架构 图：现在互联网网站常用的架构 从分布式系统的概念中我们知道，各个主机之间通信和协调主要通过网络进行，所以，分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同 一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单 纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案： 分布式锁一般有三种实现方式： 1. 数据库锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁 。 分布式锁应该是怎么样的 互斥性 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 这把锁要是一把 可重入锁 （避免死锁） 不会发生死锁 ：有一个客户端在持有锁的过程中崩溃而没有解锁，也能保证其他客户端能够加锁 这把锁最好是一把 阻塞锁 （根据业务需求考虑要不要这条） 有高可用的获取锁和释放锁功能 获取锁和释放锁的性能要好 数据库锁 基于数据库表 要实现分布式锁，最简单的方式可能就是直接 创建一张锁表 ，然后通过操作该表中的数据来实现了。 当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。 CREATE TABLE `methodLock` ( `id` int(11) NOT NULL AUTO_INCREMENT

分布式集群系统下的高可用session解决方案 ----guanfuming 20130216 目前，为了使web能适应大规模的访问,需要实现应用的集群部署. 而实现集群部署首先要解决session的统一，即需要实现session的共享机制。 目前，在集群系统下实现session统一的有如下几种方案： (1) 应用服务器间的session复制共享（如tomcat session共享） (2) 基于cache DB缓存的session共享 应用服务器间的session复制共享 session复制共享，主要是指集群环境下，多台应用服务器之间同步session，使session保持一致，对外透明。 如果其中一台服务器发生故障，根据负载均衡的原理，web服务器（apache/nginx）会遍历寻找可用节点，分发请求，由于session已同步，故能保证用户的session信息不会丢失。 此方案的不足之处： 技术复杂,必须在同一种中间件之间完成(如:tomcat-tomcat之间). session复制带来的性能损失会快速增加.特别是当session中保存了较大的对象,而且对象变化较快时, 性能下降更加显著. 这种特性使得web应用的水平扩展受到了限制。 Session内容序列化（serialize），会消耗系统性能。 Session内容通过广播同步给成员，会造成网络流量瓶颈，即便是内网瓶颈。

在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件（middleware）负责实现这个模型。一个著名的分布式系统的例子是万维网（World Wide Web），在万维网中，所有的一切看起来就好像是一个文档（Web页面）一样。 在计算机网络中，这种统一性、模型以及其中的软件都不存在。用户看到的是实际的机器，计算机网络并没有使这些机器看起来是统一的。如果这些机器有不同的硬件或者不同的操作系统，那么，这些差异对于用户来说都是完全可见的。如果一个用户希望在一台远程机器上运行一个程序，那么，他必须登陆到远程机器上，然后在那台机器上运行该程序。 分布式系统和计算机网络系统的共同点是：多数分布式系统是建立在计算机网络之上的，所以分布式系统与计算机网络在物理结构上是基本相同的。 他们的区别在于：分布式操作系统的设计思想和网络操作系统是不同的，这决定了他们在结构、工作方式和功能上也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解网络资源，网络用户必须知道网络中各个计算机的功能与配置、软件资源、网络文件结构等情况

分布式文件系统: 分布式文件系统 (Distributed File System) 是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机 / 服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以 " 发表 " 一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地 驱动器 一样。（服务器间的数据访问从一对多变为多对多） （1）原始的文件管理系统图： 一、MooseFS(MFS)文件系统 MFS 文件系统结构 : （1）包含 4 种角色 : 管理服务器 managing server (master) 元数据日志服务器 Metalogger server （ Metalogger ） 数据存储服务器 data servers (chunkservers) 客户机挂载使用 client computers （2） 4 种角色作用 : 管理服务器 : 负责各个数据存储服务器的管理 , 文件读写调度 , 文件空间回收以及恢复 . 多节点拷贝 元数据日志服务器 : 负责备份 master 服务器的变化日志文件，文件类型为 changelog_ml.*.mfs ，以便于在 master server 出问题的时候接替其进行工作