分布式部署

** 分布式和集群有区别吗？ ** 概念理解： 分布式：一个业务分拆多个子业务，部署在不同的服务器上 集群：同一个业务，部署在多个服务器上。 怎么理解：网上很好的例子： 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。 单机结构 我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。 那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。 集群结构 集群模式在程序猿界有各种装逼解释，有的让你根本无法理解，其实就是一个很简单的玩意儿，且听我一一道来。 单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍

链路跟踪 链路跟踪归根到底只是一种理念和策略，简单的说就是在2次关联调用之间传递特定透传信息的能力。从组件设计的角度说其实关心的是是下面的几个特性： 泛用性：在多大范围的作用域上可用，有没有不可用的情况 完备性：数据模型的设计上是否考虑的足够全面，该有的都有，不该有的可以扔 成本：实现的成本和风险、接入的复杂度。 落地到实现方案上还是有很多不同的策略，但总的来说其实有三种策略。 基于特定语言实现的方案 典型的例子就是Java系的方案，总的来说java是一种编译语言，但是得意于虚拟机和字节码的实现方式，Java实际上是具有动态语言的特性的。 这类实现的基本思路就是在利用java-agent拦截具体类加载过程，在特定的类加载过程加入自定义的代码来实现trace的能力。 这类方案的主要缺点是的只能用于java，但是只要是java技术栈的实现就几乎可以无任何限制的接入，对java技术栈的公司来说是非常有效。接入成本也非常低，只要在启动命令中指定参数就可以了，无论是部署脚本还是构建镜像都很方便。剩下另一个一个缺点就是改字节码本身还是有一定风险的。不过总体来说稳定性还是有保障的。 skywalking 基于组织内编码规范的实现 并不是所有公司内部都是java的，其他语言并没有改字节码这种骚操作，或者认为这种方式太过粗暴该怎么办呢？ 这种情况下基本的思路就是抽象出协议层面的概念

3.2. 分布式锁的实现 随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！ 分布式锁主流的实现方案： 基于数据库实现分布式锁 基于缓存（Redis等） 基于Zookeeper 每一种分布式锁解决方案都有各自的优缺点： 性能：redis最高 可靠性：zookeeper最高 这里，我们就基于redis实现分布式锁。 3.2.1. 基本实现 借助于redis中的命令setnx(key, value)，key不存在就新增，存在就什么都不做。同时有多个客户端发送setnx命令，只有一个客户端可以成功，返回1（true）；其他的客户端返回0（false）。 主要使用Redis Setnx 命令 在指定的 key 不存在时，为 key 设置指定的值 设置成功，返回 1 。 设置失败，返回 0 redis> EXISTS job # job 不存在 (integer) 0 redis> SETNX job "programmer" # job 设置成功 (integer) 1 redis> SETNX job "code-farmer" #

今天记录下图片的分布式存储和负载均衡实现原理。 对于Web服务器而言，用户对图片信息的访问是很消耗服务器资源的。当一个网页被浏览时,Web服务器与浏览器建立连接,每个连接表示一个并发。当页面包含多个图片时,Web服务器与浏览器会产生多个连接,同时发送文字和图片以提高浏览速度。因此,页面中图片越多Web服务器受到的压力也就越大。 一般小型网站是把所有页面和图片统一存放在一个主目录下,这样的网站对系统架构、性能要求都很简单。下面是原理图 一些稍有规模的网站都保存有大量图片资源。用户在访问这些站点网页时,网页中图片信息占到页面数据流量的大部分。由于受客户端浏览器限制,无法从一台服务器上同时下载页面中所有图片信息,因此即使服务器有很高带宽,用户的访问速度还是会受到很大影响。由于图片保存在物理硬盘上,访问图片需要频繁进行I/O 操作,因此当并发用户数越来越多时,I/O操作就会成为整个系统的性能瓶颈。这个时候我们就要考虑把这些图片信息进行分布式存储了。 下面说一个适用于中等规模商务网站的图片数据分布式动态存储及负载均衡的解决方案的思路。这种思想只需增加很少的硬件成本,即可提升网站的访问速度,并且可以根据需要动态调整图片服务器的数量及图片的存储目录,确保系统具有可扩展性和伸缩性。但对于大型的网站系统来说，他们可能会有更好的技术来实现数据的分布式存储。 增加了图片服务器后,对于客户端而言

引言 为什么写这篇文章? 博主的《分布式之消息队列复习精讲》得到了大家的好评，内心诚惶诚恐，想着再出一篇关于复习精讲的文章。但是还是要说明一下，复习精讲的文章偏面试准备，真正在开发过程中，还是脚踏实地，一步一个脚印，不要投机取巧。 考虑到绝大部分写业务的程序员，在实际开发中使用redis的时候，只会setvalue和getvalue两个操作，对redis整体缺乏一个认知。又恰逢博主某个同事下周要去培训redis，所以博主斗胆以redis为题材，对redis常见问题做一个总结，希望能够弥补大家的知识盲点。 复习要点? 本文围绕以下几点进行阐述 1、为什么使用redis 2、使用redis有什么缺点 3、单线程的redis为什么这么快 4、redis的数据类型，以及每种数据类型的使用场景 5、redis的过期策略以及内存淘汰机制 6、redis和数据库双写一致性问题 7、如何应对缓存穿透和缓存雪崩问题 8、如何解决redis的并发竞争问题 正文 1、为什么使用redis 分析:博主觉得在项目中使用redis，主要是从两个角度去考虑:性能和并发。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis。因此，这个问题主要从性能和并发两个角度去答。 回答:如下所示，分为两点 （一）性能

Hadoop 在大数据技术体系中的地位至关重要，Hadoop 是大数据技术的基础。这是一篇入门文章，以安装部署 Apache Hadoop2.7.7版本为主线. 一、安装环境说明 1、操作系统：这里我们使用的是centos 7，如果没有安装，自行安装。 centos 7安装链接 2、hadoop：Apache Hadoop2.7.7 3、java：这里我使用的是java8版本 百度云资源下载 提取码：xqzq 二、安装java 1、安装java 首先通过xshell等工具将包上传到Linux上 我们先解压包，我一般都解压到/opt下： [root@master ~]# tar -zxvf jdk-8u201-linux-x64.tar.gz -C /opt 2、配置环境 [root@master ~]# vim /etc/profile 然后添加以下代码： export JAVA_HOME="/opt/jdk1.8.0_201/" export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tool.jar 然后保存退出 配置生效：[root@master ~]# source /etc/profile 3、检验是否安装成功 [root@master ~]#

首先，Git不是github，Git和github的关系就像是 英雄联盟和对战游戏平台 其次，Xcode内置了Git，我们可以利用github或者国内的开源中国进行代码托管，直接在Xcode上进行团队协作 客户端（pc／mac）想要和github（码云等托管网站）链接，需要在终端生成用户的SSH公钥，而 项目的ssh key 和 用户的ssh key 两处地方有不同的地方（项目的sshkey只针对项目,且我们仅对项目提供了部署公钥,即 项目下的公钥仅能拉取项目 ,这通常用于生产服务器拉取仓库的代码。 而用户的key则是针对用户的,用户添加了key就对用户名下的项目和用户参加了的项目具有权限,一般而言,用户的key具有推送和拉取的权限,而项目的key则只具有拉取权限） 你可以按如下命令来生成sshkey: ssh-keygen -t rsa -C "xxxxx@xxxxx.com" # Generating public/private rsa key pair... # 三次回车即可生成 ssh key 查看你的public key，并把他添加到 Git @ OSC SSH key添加地址 cat ~/.ssh/id_rsa.pub # ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6eNtGpNGwstc.... 添加后，在终端（Terminal

1.MFS是什么？ mooseFS（moose 驼鹿）是一款网络分布式文件系统。它把数据分散在多台服务器上，但对于用户来讲，看到的只是一个源。MFS也像其他类unix文件系统一样，包含了层级结构（目录树），存储着文件属性（权限，最后访问和修改时间），可以创建特殊的文件（块设备，字符设备，管道，套接字），符号链接，硬链接。 2.MFS的特征 1：层析结构（目录树） 2：存储文件属性（权限，访问和修改时间） 3：支持特殊文件（块设备，字符设备，管道） 4：符号链接，软硬链接 5：对文件系统访问可以通过IP地址或者密码进行访问限制 6：高可靠（数据的多个拷贝存储在不同的计算机上） 7：通过附加新的计算机或者硬盘可以实现容量的动态拓展 8：删除文件可以根据一个可配置的时间周期进行保留 9：不受访问和写入影响的文件连贯快照 3.MFS的应用场景 谈及MooseFS的应用场景，其实就是去谈分布式文件系统的应用场景。 1）大规模高并发的数据存储及访问（小文件、大文件）， 2）大规模的数据处理，如日志分析 4.MFS官网 http://www.moosefs.com/是MFS官网，上面写了高可用性，低成本数据安全和可扩展性已经高性能等MFS的优点 5.MFS分布式文件系统部署方案 MooseFS 是一种分布式文件系统，MooseFS 文件系统结构包括以下四种角色： 1 管理服务器 managing

简介 随着系统规模的发展，定时任务数量日益增多，任务也变得越来越复杂，尤其是在分布式环境下，存在多个业务系统，每个业务系统都有定时任务的需求，如果都在自身系统中调度，一方面增加业务系统的复杂度，另一方面也不方便管理，因此需要有一个任务平台对分散的任务进行统一管理调度，基于目前的情况，任务平台需要支持以下几个方面： 1、任务统一管理，提供图形化界面对任务进行配置和调度。 2、任务并发控制，同一个任务在同一时间只能允许一个执行。 3、任务弹性扩容，可根据繁忙情况动态增减服务器分摊压力，对大任务进行分片处理。 4、任务依赖问题，能够处理任务包含子任务的情况，前一个完成后触发子任务执行。 5、支持多类型的任务，支持Spring Bean、Shell等。 6、任务节点高可用，任务节点异常或者繁忙时能够转移到其他节点执行。 7、调度中心高可用，支持集群部署，避免出现单点故障。 8、执行状态监控，方便查看任务执行状态，异常情况告警，支持多渠道通知。 发展史 定时任务随着技术发展，从单线程调度到多线程调度，从单机部署到集群部署，从独立执行到多任务协同执行。 第一阶段 单线程调度，在Java1.5之前，基于线程的等待(sleep或wait)机制定时执行，需要开发者实现调度逻辑，单个线程(Thread)处理单个任务有些浪费，但是一个线程(Timer)处理多个任务容易因为某个任务繁忙导致其他任务阻塞。

继上篇《 CentOS分布式部署Hadoop 》介绍分布式部署Hadoop2.8.5，本篇在上篇基础上介绍CentOS7下HBase2.2.3的分布式部署。 一、准备工作 部署好Hadoop2.8.5，节点如下： 192.168.23.211 hadoop.master NameNode,DataNode,ResourceManager,NodeManager 192.168.23.212 hadoop.slaver1 SecondaryNameNode,DataNode,NodeManager 192.168.23.213 hadoop.slaver2 DataNode,NodeManager HBase部署节点计划如下： 192.168.23.211 hadoop.master Zookeeper，HMaster(主)，HRegionServer 192.168.23.212 hadoop.slaver1 Zookeeper，HRegionServer 192.168.23.213 hadoop.slaver2 Zookeeper，HMaster(备)，HRegionServer 二、分布式部署Zookeeper HBase可以使用内置的Zookeeper，也可以使用独立部署的Zookeeper，此处使用独立部署Zookeeper方案。下载稳定版apache-zookeeper