节点服务器

CAP 定制： Eureka的优势 1、在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。 2、正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务，它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围（这点有点像ZooKeeper的做法）。这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的

一、分布式方案介绍 比较流行的两种方案： 1.取余分布： 计算key的哈希值，与服务器数量取余，得到目标服务器。优点：实现简单，当某台服务器不可用时，故障转移方便；缺点：当增减服务器时， Key与服务器取余变动量较大，缓存重组代价极大。 代码实现可参考开源组件Memcached.ClientLibrary下的SockIOPool，源码地址： https://sourceforge.net/p/memcacheddotnet/code/HEAD/tree/trunk/clientlib/src/clientlib/SockIOPool.cs 2.一致性哈希环分布： 其原理参考 https://www.cnblogs.com/lpfuture/p/5796398.html http://www.zsythink.net/archives/1182 这两位老哥写的很清楚和直白，很容易理解。 一致性哈希环分布需要物理节点和虚拟节点，且虚拟节点对应到物理节点的服务器上。 二、代码实现 由于Memcached.ClientLibrary的作者已出取余分布的实现，这里不再叙述，以下代码和测试均是一致性哈希分布的。 1.数据结构： 服务器列表：List<string> servers；//IP:PORT 服务器虚拟节点数：List<int> weights；//与servers一一对应

Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。这一切的基础，都是Zookeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。既然是一个文件系统，就不得不提Zookeeper是如何保证数据的一致性的。 Zookeeper集群是一个基于主从复制的高可用集群，通常 Master服务器作为主服务器提供写服务，其他的 Slave 服务器通过异步复制的方式获取 Master 服务器最新的数据，并提供读服务，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色，每个角色承担如下： Leader Follower Observer 为了保证写操作的一致性与可用性，Zookeeper专门设计了一种名为原子广播（ZAB）的支持崩溃恢复的一致性协议。基于该协议，Zookeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。 写数据时保证一致性：Zookeeper 客户端会随机连接到 Zookeeper 集群的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求且当前节点不是leader，那么节点就会向

Redis的集群方案大致有三种： 1）redis cluster集群方案；2）master/slave主从方案；3）哨兵模式来进行主从替换以及故障恢复。 一、sentinel哨兵模式介绍 Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。 sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。 其结构如下: <ignore_js_op> Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端

一、简介 FastDFS是一个开源的轻量级 分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。 FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。 FastDFS服务端有两个角色：跟踪器（tracker）和存储 节点（storage）。跟踪器主要做调度工作，在访问上起负载均衡的作用。 存储节点存储文件，完成文件管理的所有功能：就是这样的存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key value）方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是 文件属性列表，可以包含多个键值对。 跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。 为了支持大容量，存储 节点（服务器）采用了分卷（或分组）的组织方式。 存储系统由一个或多个卷组成

heartbeat快速部署： 高可用服务————将资源（IP及程序服务等资源）从一台已经故障的主机上快速转移到另一台正常运转的主机上继续提供服务 配置heartbeat软件的配置文件，指定哪一台heartbeat服务器作为主服务器，另一台作为热备服务器，在热备上配置heartbeat守护程序监听主服务器的心跳信息。（主备模式） 上面是主备模式，另外还可以做主主模式，即两台服务器互为主备，这时他们之间会相互发送报文来告诉对方自己当前的状态 如果在规定的时间内没有收到对方发送过来的心跳报文，就会认为对方挂了，此时就会启动程序接管运行在对方机器上的资源或服务。 heartbeat故障切换时间为5-20s 和keepalived一样。heartbeat也是服务器级别的，不是服务级别。 切换条件： 1、服务器宕机 2、heartbeat服务本身故障 3、心跳线故障 服务故障不会导致切换，但是可以通过服务故障，把heartbeat服务停掉，这样就符合切换条件了 heartbeat心跳连接： 1、串行线缆，即所谓的串口（缺点是两台主机之间不能距离太远） 2、以太网线两台主机上的网卡直连（推荐，但是需要在两台主机上各自做路由） 3、以太网电缆，通过交换机等网络设备连接（次选） 生产环境使用第二种或第一种，或是两种同时使用 脑裂： 两台高可用服务器对在指定的时间内

千万级 PV 规模高性能高并发网站架构 高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。 如果把来访用户比作来犯的"敌人"，我们一定要把他们挡在 800 里地以外，即不能让他们的 请求一下打到我们的指挥部（指挥部就是数据库及分布式存储）。 如：能缓存在用户电脑本地的，就不要让他去访问 CDN/cache。能缓存 CDN/cache 服务器上 的，就不要让 CDN/cache 去访问源（静态 web 服务器）了。能访问静态 web 服务器的，就 不要去访问动态服务器。以此类推：能不访问数据库和存储就一定不要去访问数据库和存储。 高性能高并发高可扩展网站架构访问的几个层次： 第一层： 首先在用户浏览器端，使用 Apache 的 mod_deflate 压缩传输，再比如： expires 功 能,deflate 和 expires 功能利用的好，就会大大提升用户体验效果及减少网站带宽，减少后端 服务器的压力。 提示：有关压缩传输及 expires 功能 nginx/lighttpd 等软件同样也有。 第二层： 静态页面内容缓存，如图片/js/css 等或静态数据 html，这个层面是网页缓存层,比 如 CDN（效果比公司自己部署 squid/nginx/varnish 要好，他们更专业，价格低廉，比如快网 /CC 等,而且覆盖的城市节点更多）。 自己架设 squid

1.安装 yum install epel-release.noarch -y yum install redis -y 2.配置主从 主： vim /etc/redis.conf #修改配置文件 bind 10.1.1.111 #修改监听IP requirepass 233233 #添加密码 masterauth 233233 #为什么要添加认证密码，假如主挂了，再次上线。此时主就变成从了，它需要认证其它服务器，其它服务器有密码会无法通过认证，所以预先设置好。 slave-priority 50 #增大选举权，保证主的挂了，再次线切换时候有足够权限拿到master 从： vim /etc/redis.conf #修改配置文件 bind 10.1.1.112 #修改监听IP requirepass 233233 #从 也要设置和主一样密码，假如主挂了，112提升为主，113认证的还是111的密码，这样112和113两台机器就无法连接。 slaveof 10.1.1.111 6379 #指定主的ip和端口 masterauth 233233 # 指定主的密码 另一台从也这个配置 systemctl start redis #同时启动三台主机 redis-cli -h 10.1.1.111 -a 233233 #登陆主服务器 10.1.1.111:6379> INFO

简介: Zookeeper是一个高可用的分布式管理与协调框架,基于Paxos算法(原子消息广播协议),能够很好地保证分布式环境中数据的一致性 顺序一致性 :从客户端发起的事务请求,最终会严格地按照其发起的顺序被应用到Zookeeper中 原子性 :所有事务请求的结果在集群环境中所有机器上的应用情况应该是一致的,也就是说要么集群中所有的机器都应用了这一事务,要么所有机器都没有应用这一事务. 单一视图 :无论客户端连接的是哪一个Zookeeper服务器,其获取的服务端数据都是一致的 可靠性 :一旦服务器成功地应用了某一事务,并完成了对客户端的响应,那么该事务引起的服务端状态将被一致地保留下来,除非有另一个事务对其进行更改. 树形结构! Zookeeper服务分三种角色:leader,Follower,Observer,其中Follower与Observer又统称为Learner Leader:负责客户端的writer请求类型 Follower:负责客户端的reader类型请求和leader选举等 Observer:特殊的Follower,可以接受客户端的reader请求,但不参与选举,不接受任何的同步写入请求,只负责与leader同步数据 典型应用场景: 配置管理 集群管理 发布订阅 数据库切换 分布式日志收集 分布式锁与队列管理 Zookeeper的安装: 结构：一共三个节点

Redis支持的数据类型？ String字符串： 格式: set key value string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。 string类型是Redis最基本的数据类型，一个键最大能存储512MB。 Hash（哈希） 格式: hmset name key1 value1 key2 value2 Redis hash 是一个键值(key=>value)对集合。 Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 List（列表） Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边） 格式: lpush name value 在 key 对应 list 的头部添加字符串元素 格式: rpush name value 在 key 对应 list 的尾部添加字符串元素 格式: lrem name index key 对应 list 中删除 count 个和 value 相同的元素 格式: llen name 返回 key 对应 list 的长度 Set（集合） 格式: sadd name value Redis的Set是string类型的无序集合。 集合是通过哈希表实现的，所以添加，删除