集群服务器

Redis分片： 为什么要分片：随着Redis存储的数据越来越庞大，会导致Redis的性能越来越差！ 目前分片的方法： 1、客户端分片 在应用层面分片，程序里指定什么数据存放在那个Redis 优势：比较灵活 缺点：加个节点扩容就很费劲 2、代理Proxy分片 第三方的Twemproxy 使用代理的缺点，你代理什么性能，那么你整个Redis的性能就是什么样的！ 3、redis cluster 4、codis （豌豆荚）开源 Redis cluster： 这里摘录：http://redisdoc.com/topic/cluster-tutorial.html#id2 集群分片： Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。 集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中： * 节点 A 负责处理 0 号至 5500 号哈希槽。 * 节点 B 负责处理 5501 号至 11000 号哈希槽。

Zookeeper使用了Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息广播协议）的协议作为其数据一致性的核心算法。ZAB协议是为Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。 ZAB理论 ZAB协议的核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式，即： 所有事务请求必须由一个全局唯一的服务器来协调处理 ，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将一个客户端事务请求转化成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。 ZAB一些包括两种基本的模式： 崩溃恢复 和 消息广播 。 1、当整个服务框架启动过程中或Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式

1、部署两个tomcat节点，使用nginx实现集群（见 http://www.cnblogs.com/zhangzhi0556/articles/nginx.html ）； 2、redis安装（见 http://www.cnblogs.com/zhangzhi0556/articles/redis.html ） 3、建一个简单的web项目，打包发布到各个tomcat中，用于测试session是否真的实现了共享（自己想办法怎么建测试项目） 4、下载开源组件tomcat-redis-session-manager 下载方式一： https://github.com/jcoleman/tomcat-redis-session-manager/downloads (这个是早期的，不支持redis3.0集群) 下载方式二（推荐）： https://github.com/ran-jit/TomcatClusterRedisSessionManager （支持redis3集群和tomat8） 最好通过以下地址下载： https://github.com/ran-jit/TomcatClusterRedisSessionManager/wiki/Tomcat-Cluster-Redis-Session-Manager 可以下载TomcatRedisSessionManager-1.0.zip包

1.参见网址: http://spark.apache.org/docs/latest/spark-standalone.html 2.对自己的服务器做一个规划 3.准备工作 网络 免密钥 把spark的包四台电脑都复制一份 4.启动主服务器（haodoop102） sbin/start-master.sh 会产生log日志 – 要看日志 5.查看网页 6.启动小弟(在想当小弟的服务器上执行) # 参数是大哥的Url sbin/start-slave.sh spark://node7-2:7077 7.推荐的配置方法 要准备一个conf/slaves;写的全部是小弟(复制conf/slaves.template为conf/slaves) hadoop103 hadoop104 配置文件:(复制conf/spark-env.sh.template为spark-env.sh) 先停止服务器 sbin/stop-all.sh 再开启服务即可 sbin/start-all.sh 来源： CSDN 作者： T、X、M 链接： https://blog.csdn.net/weixin_45858664/article/details/103744140

redis配置、安装、集群 前言 Redis 是我们目前大规模使用的缓存中间件，由于它强大高效而又便捷的功能，得到了广泛的使用。单节点的Redis已经就达到了很高的性能，为了提高可用性我们可以使用Redis集群。 当然了，现在集群的方式有很多，隧道模式（还有更高级的虚拟隧道模式）、行星模型、智能路由、P2P模式，各种各样的，算是各有各的好处吧，也有官方给了一种cluster工具，不过本文不用官方的，因为他的官方的这个是在一个服务器上折腾。。。一台机器死了，直接全崩，有点没必要，本文主要讲 主从模式的redis. redis简介 分布式 - 所谓的分布式就是不是单独跑在一台服务器上的，不管公司花多少钱一台服务器多牛，它也是有极限的，1000t内存也是极限，所以单台服务器风险还是比较大的，万一它死了，整个公司完全瘫了也不合适。 所以分布式就是说让我这一个服务是部署在一个一个的服务器上，这样的话就算是有一个服务器因为各种各样的原因瘫了，没关系，继续跑，只不过整个系统性能会有所下降，然后过一段时间等这些节点重新恢复了它又可以接入分布式的系统当中。 内存数据存储 - noSQL 咱们知道跟数据库所有的打交道都需要用SQL语言来完成，结构化查询语言。 它有的时候也叫noSQL，因为咱们那个数据库，说实话它很强，各种关系，各种乱七八糟的东西，但是数据库，它更适合复杂的查询，对于简单的查询

1. ElasticSearch ES即为了解决原生Lucene使用的不足，优化Lucene的调用方式，并实现了高可用的分布式集群的搜索方案，其第一个版本于2010年2月出现在GitHub上并迅速成为最受欢迎的项目之一。 首先，ES的索引库管理支持依然是基于Apache Lucene™的开源搜索引擎。 ES也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的 RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。 不过，ES的核心不仅仅在于Lucene，其特点更多的体现为： 分布式的实时文件存储，每个字段都被索引并可被搜索 分布式的实时分析搜索引擎 KB-MB-GB-TB-PB 可以扩展到上百台服务器，处理PB级结构化或非结构化数据 高度集成化的服务，你的应用可以通过简单的 RESTful API、各种语言的客户端甚至命令行与之 交互。 上手Elasticsearch非常容易。它提供了许多合理的缺省值，并对初学者隐藏了复杂的搜索引擎理论。它拥有开瓶即饮的效果（安装即可使用），只需很少的学习既可在生产环境中使用。 1.1 ES的使用者及类似框架 典型使用案例 全球程序员github – 中国码云 ①Github(美国)使用Elasticsearch搜索20TB的数据，包括13亿的文件和1300亿行的代码.

一、Docker swarm简介 Docker swarm与 docker-compose 一样，都是docker官方推出的docker容器的编排工具。但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。 Docker swarm： 其作用就是把若干个Docker主机抽象为一个整体，并且通过一个入口统一管理这些Docker主机上的各种Docker资源。Swarm和Kubernetes比较类似，但是更加轻，具有的功能也较kubernetes更少一些。 从 Docker 1.12.0 版本开始，Docker Swarm 已经包含在 Docker 引擎中（docker swarm），并且已经内置了服务发现工具，我们就不需要像之前一样，再配置 Etcd 或者 Consul 来进行服务发现配置了。 Docker swarm中有三种角色： Manager node：负责执行容器的编排和集群的管理工作，保持并维护swarm处于期望的状态，swarm可以有多个manager node，他们会自动协商选举出一个leader执行编排任务；但相反，不能没有manager node； Worker node：接受并执行由manager

一、Docker swarm简介 Docker swarm与 docker-compose 一样，都是docker官方推出的docker容器的编排工具。但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。 Docker swarm： 其作用就是把若干个Docker主机抽象为一个整体，并且通过一个入口统一管理这些Docker主机上的各种Docker资源。Swarm和Kubernetes比较类似，但是更加轻，具有的功能也较kubernetes更少一些。 从 Docker 1.12.0 版本开始，Docker Swarm 已经包含在 Docker 引擎中（docker swarm），并且已经内置了服务发现工具，我们就不需要像之前一样，再配置 Etcd 或者 Consul 来进行服务发现配置了。 Docker swarm中有三种角色： Manager node：负责执行容器的编排和集群的管理工作，保持并维护swarm处于期望的状态，swarm可以有多个manager node，他们会自动协商选举出一个leader执行编排任务；但相反，不能没有manager node； Worker node：接受并执行由manager

Redis Cluster 集群中涉及到了数据分布问题，因为 redis cluster 是多 master 的结构，每个 master 都是可以提供存储服务的，这就会涉及到数据分布的问题，在新的 redis 版本中采用的是虚拟槽分区技术来解决数据分布的问题，关于什么是虚拟槽分区技术我们后面会详细的介绍。在集群中除了虚拟槽分区技术之外，还有几种数据分布的算法，比如哈希算法，一致性哈希算法，这篇文章我们就来一起聊一聊这几种数据分布算法。 因为是集群，所以我们需要一个大前提，在这篇文章中假设 redis cluster 集群中有三台 master，我们需要存储的数据集为： [{id:1,"name":"1"},{id:2,name:"2"},{id:3,name:"3"},{id:4,name:"4"},{id:5:"name":"5"},{id:6,"name":"6"}] ，在这个大前提下，我们来聊一聊集群中的数据分布算法。 哈希算法 哈希算法在分布式架构中应用广泛，不仅仅是数据存储，还有负载均衡等应用上有用的比较多，哈希算法的思想非常简单，也许你知道 HashMap 的哈希函数，哈希算法跟 HashMap 一样，也是通过一个哈希函数得到某一个数字，然后根据数字找到相应的服务器。哈希算法的哈希函数比较简单，一般是根据某个key的值或者key 的哈希值与当前可用的

实验环境 4台GFS节点服务器做GlusterFS集群,提供存储服务给KVM客户端做虚拟化 服务器角色 IP地址 磁盘空间 gfs-node1 192.168.142.152 40G+40G gfs-node2 192.168.142.154 40G+40G gfs-node3 192.168.142.162 40G+40G gfs-node4 192.168.142.163 40G+40G kvm-client 192.168.142.163 40G 第一步:部署GFS节点服务器 1.为四台GFS节点服务器服务器每台添加一个新磁盘 2.使用脚本一键部署GFS节点 #!/bin/bash systemctl stop firewalld.service setenforce 0 #格式化磁盘 echo "the disks exist list:" fdisk -l |grep '磁盘 /dev/sd[a-z]' echo "==================================================" PS3="chose which disk you want to create:" select VAR in `ls /dev/sd*|grep -o 'sd[b-z]'|uniq` quit do case $VAR in sda) fdisk -l