集群服务器

前言 在 Redis Cluster集群 (一) 中了解了集群的相关概念，这一节我们将了解集群平台的搭建。 1. 简介 集群中至少应该有奇数个节点，所以搭建集群最少需要3台主机，同时每个节点至少有一个备份节点，所以下面最少要创建6台机器，才能完成Redis Cluster 集群（主节点，备份节点由redis-cluster集群确定） 真集群：六台服务器存在6个redis服务(这六台redis服务的主机号不同,端口号可以相同) 192.168.1.1.110: 6379 192.168.1.1.111: 6379 192.168.1.1.112: 6379 假集群: 一台服务器存在6个redis服务(这六台redis服务的主机号相同[因为使用同一台服务器]，端口号不相同) 192.168.1.111: 6379 192.168.1.111:6380 192.168.1.111:6382 2. 搭建集群环境 在这里由于我们自身设备有限，所以我们采用加集群进行搭建 [1] 创建Redis节点安装目录 mkdir /usr/local/redis_cluster //指定目录下 创建 redis_cluster [2] 在redis_cluster目录下，创建7001-7006 个文件夹下 mkdir 7001 7002 7003 7004 7005 7006 [3] 并将redis

文章目录 1.1、Keepalived简介 1.2、Keepalived是什么？ 1.3、VRRP协议与工作原理 1.4、Keepalvied的工作原理 1.5、Keepalived体系结构 1.1、Keepalived简介 Keepalived是Linux下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA)，其实两种不同的含义：广义来讲，是指整个系统的高可用行，狭义的来讲就是之主机的冗余和接管。 它与HeartBeat Rose HA 实现相同类似的功能，都可以实现服务或者网络的高可用，但是又有差别，HeartBeat是一个专业的、功能完善的高可用软件，它提供了HA 软件所需的基本功能，比如：心跳检测、资源接管，检测集群中的服务，在集群节点转移共享IP地址的所有者等等。HeartBeat功能强大，但是部署和使用相对比较麻烦。 与HeartBeat相比，Keepalived主要是通过虚拟路由冗余来实现高可用功能，虽然它没有HeartBeat功能强大，但是Keepalived部署和使用非常的简单，所有配置只需要一个配置文件即可完成。 1.2、Keepalived是什么？ Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态

mysql集群配置在网站负载均衡中是必不可少的； 首先说下我个人准备的负载均衡方式； 　　1、通过nginx方向代理来将服务器压力分散到各个服务器上； 　　2、每个服务器中代码逻辑一样； 　　3、通过使用redis缓存来保存内存中数据，使用redis同步功能来同步不同服务器内存中的数据； 　　4、在通过mysql的集群配置来实现数据库数据同步； 这里我整理了几种数据同步方式； 一：主从服务器同步； 　　顾名思义：主服务器负责数据的增删改查，从服务器负责同步数据； 　　主服务器建立二进制文件；每产生语句变化或磁盘变化写入日至； 　　从服务器读主服务二进制日至；将读到的日至转成从服务的relaylog，从服务读取relaylog同步主主服务器； 　　主服务器建立授权复制账号； 　　从服务器利用账号来监听主服务器； 　　步骤： 　　1、首先需要至少两台服务器，我这边118.xxx.xxx.1(主)，118.xxx.xxx.2(从)两台服务器；两台搭建mysql方式不同，一台安装mysql，和mysql-server;一台通过直接安装mariadb方式；没什么影响； 　　2、主服务器修改/etc/my.cnf;　　　　 #在[mysqld]下添加,建立二进制日至 #server-id一般用服务器后一位 server-id=1 log-binary=mysql-bin #监听变化方式

一文入门Es、Logstash、Kibana 前言 Elasticsearch是什么？既然它是英文的，我们不妨借助有道从 Elasticsearch 这几个字母出发来看看其字面上所表达的意思吧。其分为elastic和search两个独立的单词，既然如此，我们无脑有道一波，得到的解释如下： 从有道的解释来看，我们可以简单的对其理解为： Elasticsearch是及其具有弹性的、灵活的、像松紧带一样的且可供搜寻检索的一款工具。 o(*≧▽≦)ツ┏━┓ 百度百科对其解释如下： ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。ElasticSearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache、Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。 从如上信息我们可以得知，Elasticsearch是一款实时、分布式存储的搜索引擎，在实际开发过程中

本节内容： RabbitMQ介绍 RabbitMQ运行原理 RabbitMQ重要术语 三种ExchangeType RabbitMQ集群种类 集群基本概念 镜像模式部署集群 一、RabbitMQ介绍 消息系统通过将消息的发送和接收分离来实现应用程序的异步和解偶。 或许你正在考虑进行数据投递，非阻塞操作或推送通知。或许你想要实现发布／订阅，异步处理，或者工作队列。所有这些都属于消息系统的模式。 RabbitMQ是一个消息代理，一个消息系统的媒介。它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息再传输过程中的安全。 RabbitMQ是一个在AMQP协议标准上完整的、可复用的企业消息系统。它遵循Mozilla Public License开源协议，采用Erlang语言实现的工业级的消息队列。 二、RabbitMQ运行原理 RabbitMQ的两大核心组件是Exchange和Queue，以下是它的运行原理图： 三、RabbitMQ重要术语 Server(broker): 接受客户端连接，实现AMQP消息队列和路由功能的进程。 Vitual Host: 这是一个虚拟概念，类似于权限控制组，一个Vitual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Vitual Host。 Exchange: 接收生产者发送的消息

Sentinel 集群工作方式 Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。 　　　　例如： 　　　　 　　　　在Server1 掉线后： 　　　　升级Server2 为新的主服务器： 　　 Sentinel的作用： A、Master 状态监测 B、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave C、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换 详情见：https://www.cnblogs.com/jaycekon/p/6237562.html 来源： https://www.cnblogs.com/xunyi/p/10286052.html

01 引言 随着用户的增长、业务的发展，大型企业用户的业务系统的数据量越来越大，超大数据表的性能问题成为阻碍业务功能实现的一大障碍。其中，流水表作为最常见的一类超大表，是企业级用户经常碰到的性能瓶颈。 本文就以流水类的超大表，探讨基于SequoiaDB巨杉数据库存储的超大表进行的性能调优。SequoiaDB 巨杉数据库，作为新一代 OLTP 的分布式数据库，被广泛使用于海量数据存储与高并发操作场景中。对于海量数据的存储和高并发操作，分布式数据库相较于传统数据库有着天然的优势，合理利用SequoiaDB巨杉数据库多种特性，轻松解决超大表的性能问题。 02 数据存储规划很重要 对于流水类超大表，前期的数据存储规划尤为重要，合理的数据存储规划能有效利用数据库集群硬件资源，提供更高性能、更高效率的数据服务。 集群规模评估与硬件配置搭配 在数据库集群规划伊始，需要通过调研数据库集群支撑应用规模、系统定位和业务长期发展规划进行摸底，用以评估集群规模以及各服务器的CPU、内存、硬盘、网卡的合理搭配。 精准的评估一个数据库集群规模，是一个宏大且复杂的综合工程，需要有的业务需求评估数据加以支持。通常情况下，由于业务需求变化快、业务增长普遍高于预期，小集群规划可以按照业务调研信息的1.5~2倍进行评估，大集群规划可以按1~1.5倍进行评估。 集群规模需要通过业务规模、数据存储规模

ZooKeeper学习第一期---Zookeeper简单介绍 ZooKeeper学习第二期--ZooKeeper安装配置 ZooKeeper学习第三期---Zookeeper命令操作 ZooKeeper学习第四期---构建ZooKeeper应用 ZooKeeper学习第五期--ZooKeeper管理分布式环境中的数据 ZooKeeper学习第六期---ZooKeeper机制架构 ZooKeeper学习第七期--ZooKeeper一致性原理 ZooKeeper学习第八期——ZooKeeper伸缩性 一、Zookeeper的搭建方式 Zookeeper安装方式有三种， 单机模式 和 集群模式 以及 伪集群模式 。 ■ 单机模式：Zookeeper只运行在一台服务器上，适合测试环境； ■ 伪集群模式：就是在一台物理机上运行多个Zookeeper 实例； ■ 集群模式：Zookeeper运行于一个集群上，适合生产环境，这个计算机集群被称为一个“集合体”（ensemble） Zookeeper通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够保证服务继续。 为什么一定要超过半数呢 ？这跟Zookeeper的复制策略有关：zookeeper确保对znode 树的每一个修改都会被复制到集合体中超过半数的机器上。 1.1 Zookeeper的单机模式搭建 下载

1. 前言 本编主要记录Zookeeper写请求处理的一些流程，涉及到过半机制，数据同步。 2. 处理流程 这里假设4台服务器，server1(Follower),server2(Leader),server3(Follower),server4(Observer)。 由于我们Zookeeper客户端对于服务端的任何一台服务都是可以进行连接的，有可能是连接的是Leader，或Follower，甚至是Observer。 这里若有一个客户端Client连接的是Observer，并写入数据。但是由于只有写请求只能交与Leader处理，所以若是连接到的是Follower，Observer，就会发生请求的转发到Leader。 接下来，Leader会想所有的Follower发送提议请求，不对Observer发送。Follower收到来自Leader的提议后，会返回ack响应。 Leader收到ack请求后，会采用过半机制，即发送出去的提议有一半以上的ack响应，则就会发送commit提交数据，同时也会向Observer提交commit。 整个写流程就是如此，这样就保证了每个写入请求都会成功的写入到集群中，若有新的服务器加入进来，也会对Leader进行数据同步，来达到集群中数据的一致性。 3. 为何不向Observer发送提议？ 这个问题在Zookeeper单机和集群环境搭建中有提到过

使用kubeadm部署k8s集群08-配置LB指向kube-apiserver 2018/1/4 配置 LB 指向 kube-apiserver 小目标：在 3 个 master 节点前，还需配置一个 LB 来作为 apiserver 的入口 LB -> master x3 直接使用阿里云内网 SLB L4 proxy 资源（本次实例是 4 层而不使用 7 层的原因是：跳过了处理证书的环节） 申请下来资源后，将得到一个 vip 指向上述 3 个 master 节点的 IP 作为后端真实服务器 注意：做网络联通性测试时，不要在上述 3 个 master 节点上测试 vip 是否可用，因为这和负载均衡TCP的实现机制有关 利用 haproxy/nginx 来自建 LB（测试通过，但建议使用阿里云到基础组件，不要自己维护） 直接使用阿里云内网 SLB L4 proxy 资源 ### 申请的 SLB 资源 SLB instance id: lb-xxx, vip: 10.10.9.76 ### 网络联通性测试 [root@tvm-04 ~]# for i in $(seq 1 10);do echo "------------$i";curl -k -If -m 3 https://10.10.9.76:6443;done ------------1 curl: (22) NSS: