如何实现集群技术

1)强扩展能力

其他扩展技术，通常仅能支持儿十个CPU 的扩展，扩展能力有限。而采用集群技术的集群系统则可以扩展到包括成百上千个CPU的多台服务穗，扩展能力具有明显优势。集群服务还可不断进行调整，以满足不断增长的应用需求。当集群的整体负荷超过集群的实际能力时，还可以添加额外的节点。

2)实现方式容易

服务器集群技术相对其他扩展技术来说更加容易实现，主要是通过软件进行的。在硬件上可以把多台性能较低、价格便宜的服务器，通过集群服务集中连接在一起即可实现整个服务器系统成倍，甚至几十、几百倍地增长。无论是从软硬件构成成本上来看，还是从技术实现成本上来看都较其他扩展方式低。

3)高可用性

使用集群服务拥有整个集群系统资源的所有权。如磁盘驱动器和IP地址将自动地从有故障的服务器上转移到可用的服务器上。当集群中的系统或应用程序出现故障时，集群软件将在可用的服务器上，重启失效的应用程序，或将失效节点上的工作分配到剩余的节点上。在切换过程中，用户只是觉得服务暂时停顿了一下。

4)易管理性

可以使用集群管理器来管理集群系统的所有服务器资源和应用程序，就像它们都运行在同一个服务器上一样。可以通过拖放集群对象，在集群里的不同服务器间移动应用程序，也可以通过同样的方式移动数据，还可以通过这种方式来手工地平衡服务器负荷、卸载服务器，从而方便地进行维护。同时，还可以从网络的任意地方的节点和资源处，监视集群的状态。当失效的服务器连回来时，将自动返回工作状态，集群技术将自动在集群中平衡负荷，而不需要入工干预。

服务器集群：

服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。

服务器负载均衡：

负载均衡

（Load

Balancing）

建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

分布式服务器：

所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库操作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS

中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。

这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。

纯手工打字，希望可以帮的到你！

 一套好的日志分析系统可以详细记录系统的运行情况，方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式，那么日志记录下来，相关人员就需要对日志数据进行处理与分析，基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。

  作为微服务集群，必须要考虑当微服务访问量暴增时的高并发场景，此时系统的日志数据同样是爆发式增长，我们需要通过消息队列做流量削峰处理，Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列，但其各项功能显示不如单一实现的消息队列，所以通常情况下并不使用它的消息队列功能；Kafka的性能要优于RabbitMQ，通常在日志采集，数据采集时使用较多，所以这里我们采用Kafka实现消息队列功能。

  ELK日志分析系统中，数据传输、数据保存、数据展示、流量削峰功能都有了，还少一个组件，就是日志数据的采集，虽然log4j2可以将日志数据发送到Kafka，甚至可以将日志直接输入到Logstash，但是基于系统设计解耦的考虑，业务系统运行不会影响到日志分析系统，同时日志分析系统也不会影响到业务系统，所以，业务只需将日志记录下来，然后由日志分析系统去采集分析即可，Filebeat是ELK日志系统中常用的日志采集器，它是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。

软件下载：

  因经常遇到在内网搭建环境的问题，所以这里习惯使用下载软件包的方式进行安装，虽没有使用Yum、Docker等安装方便，但是可以对软件目录、配置信息等有更深的了解，在后续采用Yum、Docker等方式安装时，也能清楚安装了哪些东西，安装配置的文件是怎样的，即使出现问题，也可以快速的定位解决。

Elastic Stack全家桶下载主页： https://wwwelasticco/cn/downloads/

我们选择如下版本：

Kafka下载：

  安装前先准备好三台CentOS7服务器用于集群安装，这是IP地址为：1721620220、1721620221、1721620222，然后将上面下载的软件包上传至三台服务器的/usr/local目录。因服务器资源有限，这里所有的软件都安装在这三台集群服务器上，在实际生产环境中，请根据业务需求设计规划进行安装。

  在集群搭建时，如果能够编写shell安装脚本就会很方便，如果不能编写，就需要在每台服务器上执行安装命令，多数ssh客户端提供了多会话同时输入的功能，这里一些通用安装命令可以选择启用该功能。

新建/usr/local/java目录

将下载的jdk软件包jdk-8u64-linux-x64targz上传到/usr/local/java目录，然后解压

配置环境变量/etc/profile

在底部添加以下内容

使环境变量生效

备注：后续可通过此命令停止elasticsearch运行

  新建kafka的日志目录和zookeeper数据目录，因为这两项默认放在tmp目录，而tmp目录中内容会随重启而丢失,所以我们自定义以下目录:

修改如下：

在data文件夹中新建myid文件，myid文件的内容为1（一句话创建：echo 1 > myid）

kafka启动时先启动zookeeper，再启动kafka；关闭时相反，先关闭kafka，再关闭zookeeper。

1、zookeeper启动命令

后台运行启动命令：

或者

查看集群状态：

2、kafka启动命令

后台运行启动命令：

或者

3、创建topic，最新版本已经不需要使用zookeeper参数创建。

参数解释:

复制两份

--replication-factor 2

创建1个分区

--partitions 1

topic 名称

--topic test

4、查看已经存在的topic（三台设备都执行时可以看到）

5、启动生产者：

6、启动消费者：

添加参数 --from-beginning 从开始位置消费，不是从最新消息

7、测试：在生产者输入test，可以在消费者的两台服务器上看到同样的字符test，说明Kafka服务器集群已搭建成功。

Logstash没有提供集群安装方式，相互之间并没有交互，但是我们可以配置同属一个Kafka消费者组，来实现统一消息只消费一次的功能。

  Filebeat用于安装在业务软件运行服务器，收集业务产生的日志，并推送到我们配置的Kafka、Redis、RabbitMQ等消息中间件，或者直接保存到Elasticsearch，下面来讲解如何安装配置：

1、进入到/usr/local目录，执行解压命令

2、编辑配置filebeatyml

  配置文件中默认是输出到elasticsearch，这里我们改为kafka，同文件目录下的filebeatreferenceyml文件是所有配置的实例，可以直接将kafka的配置复制到filebeatyml

后台启动命令

停止命令

2、测试logstash是消费Kafka的日志主题，并将日志内容存入Elasticsearch

自动新增的两个index，规则是logstash中配置的

数据浏览页可以看到Elasticsearch中存储的日志数据内容，说明我们的配置已经生效。

Gitee: GitEgg: GitEgg 是一款开源免费的企业级微服务应用开发框架，旨在整合目前主流稳定的开源技术框架，集成常用的最佳项目解决方案，实现可直接使用的微服务快速开发框架。

GitHub: https://githubcom/wmz1930/GitEgg

国内用GFS不少，但是压力大的案例不多。有几个问题：1 3个机器OS版本是？ 2 关于你的模型，第一种情况，使用GFS，AB写入大量小文件，C同时删除某些小文件，写入慢；如果换成GFS2,写入快删除慢对吧？ 你描述的慢，能具体描述一下吗？2 你的“优化”参数，哪里得到的？什么理由要加入这些参数？ 去掉这些参数是否有变化？ 查看更多答案>>

采纳哦

随着单台服务器优势的减弱，相信越来越多的人开始逐渐耳闻“集群”这个概念，很大站长学会香港站群服务器，终于把网站搞上去了，对于热备份服务器系统来说同样有优势，服务器集群技术

上图为百度中资料截图，个人理解应该有一个主、从关系。应该是在安装集群软件的服务器或PC电脑上操作。

无论多少台服务器做集群，对外的IP地址，应该也只有一个主IP，通过一些软件可以通过此IP对集群进行操作。

负载均衡和高可用性的侧重点不同。负载均衡不一定意味着高可用性。

假设我们在机房里建起了一个访问量很高的网站，然后我们用一个负载均衡器，三台完全相同的Tomcat服务器，实现了负载均衡，所有流量都会被按某种算法分配给三台服务器。

那么，这个系统是高可用的吗？并不一定。如果只考虑Tomcat服务器的话，我们使用了三台服务器，比只用一台服务器的确既增加了负载平衡又增加了可用性。但是，从整个系统的角度来看，增加服务器的数量，只能算提高系统可用性的一个方面。

高可用性意味着高MTBF（平均故障间隔）和低故障恢复时间，也就是系统连续长时间运行，且能从当机状态快速恢复运行的能力。很明显，上述系统没达到这两个条件。

首先，它有多个单点故障点：

一个负载均衡器，一套网络设备、供电设备，等（软件方面）。

这注定使系统MTBF受到极大制约。

提高MTBF的方法很直观：备份。为了消除第二个单点故障，备份组件还需要处于不同地理位置。这样的话，就算一个位置断网、停电，其他位置的系统都能继续运行。如果再考虑到地震、洪水等自然灾害和其他因素，备份组件甚至需要处于不同城市、不同国家。

其次，虽然有了备份，系统还是有当机的可能性，所以我们还需要考虑系统当机之后快速恢复系统功能，也就是缩短故障恢复时间。这需要缩短故障反应时间并合理保存系统状态等，不再详述。

所以，负载均衡只能提高部分系统可用性（以服务器热备的形式），为了提高系统的可用性，我们还需要综合考虑其他因素。

Mongodb集群搭建过程及常见错误

Replica Sets

MongoDB 支持在多个机器中通过异步复制达到故障转移和实现冗余。多机器中同一时刻只 有一台是用于写操作。正是由于这个情况，为 MongoDB 提供了数据一致性的保障。担当 Primary 角色的机器能把读操作分发给 slave。

Replica Sets的结构非常类似一个集群。因 为它确实跟集群实现的作用是一样的， 其中一个节点如果出现故障， 其它节点马上会将业务接过来而无须停机操作。

下面以本机为例介绍一下集群的部署过程，以及部署过程中常见的注意点及错误

本例环境是Linux操作系统，mongodb版本:mongodb-linux-x86_64-261tgz，Vmwre虚拟机，虚拟机IP:192168169129,集群以本机不同端口模拟三台服务器。

1集群主要分为三个节点master主节点，slaver备用节点，arbiter仲裁节点

建立数据文件夹

1

2

3

mkdir -p /mongodb/data/master

mkdir -p /mongodb/data/slaver

mkdir -p /mongodb/data/arbiter

ps:三个目录分别对应主，备，仲裁节点

2建立配置文件夹

1)masterconf

打开编辑器:

1

vi /etc/masterconf

按i 输入下列配置

1

2

3

4

5

6

7

dbpath=/home/mongodb/data/master

logpath=/home/mongodb/log/masterlog

logappend=true

replSet=rep1

port=10000

fork=true

journal=true

完成之后按esc 》》 : >>wq>>回车

2）slaverconf

编辑器打开和保存按上边的步骤，下边只写详细内容

1

2

3

4

5

6

7

dbpath=/home/mongodb/data/slaver

logpath=/home/mongodb/log/slaverlog

logappend=true

replSet=rep1

port=10001

fork=true

journal=true

3）arbiterconf

1

2

3

4

5

6

7

8

dbpath=/home/mongodb/data/arbiter

logpath=/home/mongodb/log/arbiterlog

logappend=true

replSet=rep1

port=10002

fork=true

journal=true

smallfiles=true

参数解释：

dbpath：数据存放目录

logpath：日志存放路径

logappend：以追加的方式记录日志

replSet：replica set的名字

port：mongodb进程所使用的端口号，默认为27017

fork：以后台方式运行进程

journal:写日志

smallfiles:当提示空间不够时添加此参数

其他参数

pidfilepath：进程文件，方便停止mongodb

directoryperdb：为每一个数据库按照数据库名建立文件夹存放

bind_ip：mongodb所绑定的ip地址

oplogSize：mongodb操作日志文件的最大大小。单位为Mb，默认为硬盘剩余空间的5%

noprealloc：不预先分配存储

3启动Mongodb

1

cd /home/mongodb/bin

启动服务

1

2

3

4

5

/mongod -f /etc/masterconf

/mongod -f /etc/slaverconf

/mongod -f /etc/arbiterconf

有这样的提示说明启动成功

如果是下列的提示说明启动失败

启动失败的原因有很多，检查完配置文件，如果没有错误，可打开相应的配置文件查看详细的错误信息

cat /etc/masterconf

最常见的一个错误就是磁盘空间不足，会提示这样的错误

因为Mongodb的日志文件是成2g的增长，所以所需空间比较大，这时你可以在配置文件里添加这样的一个配置

smallfiles=true。

全部三个服务全部启动成功之后

4配置主(master)，备(slaver)，仲裁(arbiter)节点

可以通过客户端连接mongodb，也可以直接在三个节点中选择一个连接mongodb。

/mongo 192168169129:10000 #ip和port是某个节点的地址

>use admin

>cfg={ _id:"rep1", members:[ {_id:0,host:'192168169129:10000',priority:2}, {_id:1,host:'192168169129:10001',priority:1},

{_id:2,host:'192168169129:10002',arbiterOnly:true}] };

>rsinitiate(cfg) #使配置生效

{

"set" : "rep1",

"date" : ISODate("2014-09-05T02:44:43Z"),

"myState" : 1,

"members" : [

{

"_id" : 0,

"name" : "192168169129:10000",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 200,

"optime" : Timestamp(1357285565000, 1),

"optimeDate" : ISODate("2013-01-04T07:46:05Z"),

"self" : true

},

{

"_id" : 1,

"name" : "192168169129:10001",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 200,

"optime" : Timestamp(1357285565000, 1),

"optimeDate" : ISODate("2013-01-04T07:46:05Z"),

"lastHeartbeat" : ISODate("2013-01-05T02:44:42Z"),

"pingMs" : 0

},

{

"_id" : 2,

"name" : "192168169129:10002",

"health" : 1,

"state" : 7,

"stateStr" : "ARBITER",

"uptime" : 200,

"lastHeartbeat" : ISODate("2013-01-05T02:44:42Z"),

"pingMs" : 0

}

],

"ok" : 1

}

配置过程中可能还会出现其他的一些错误，不过都可以去查看相应的日志文件，去解决。