节点服务器

分布式文件系统: 分布式文件系统 (Distributed File System) 是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机 / 服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以 " 发表 " 一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地 驱动器 一样。（服务器间的数据访问从一对多变为多对多） （1）原始的文件管理系统图： 一、MooseFS(MFS)文件系统 MFS 文件系统结构 : （1）包含 4 种角色 : 管理服务器 managing server (master) 元数据日志服务器 Metalogger server （ Metalogger ） 数据存储服务器 data servers (chunkservers) 客户机挂载使用 client computers （2） 4 种角色作用 : 管理服务器 : 负责各个数据存储服务器的管理 , 文件读写调度 , 文件空间回收以及恢复 . 多节点拷贝 元数据日志服务器 : 负责备份 master 服务器的变化日志文件，文件类型为 changelog_ml.*.mfs ，以便于在 master server 出问题的时候接替其进行工作

1.1. 一致性协议概述 前面已经讨论过，在分布式环境下，有很多不确定性因素，故障随时都回发生，也讲了 CAP 理论， BASE 理论 我们希望达到，在分布式环境下能搭建一个高可用的，且数据高一致性的服务，目标是这样，但 CAP 理论告诉我们要达到这样的理想环境是不可能的。这三者最多完全满足 2 个。 在这个前提下， P （分区容错性）是必然要满足的，因为毕竟是分布式，不能把所有的应用全放到一个服务器里面，这样服务器是吃不消的，而且也存在单点故障问题。 所以，只能从一致性和可用性中找平衡。 怎么个平衡法？在这种环境下出现了 BASE 理论： 即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性； BASE 由 Basically Avaliable 基本可用、 Soft state 软状态、 Eventually consistent 最终一致性组成，一句话概括就是：平时系统要求是基本可用，除开成功失败，运行有可容忍的延迟状态，但是，无论如何经过一段时间的延迟后系统最终必须达成数据是一致的。 其实可能发现不管是 CAP 理论，还是 BASE 理论，他们都是理论，这些理论是需要算法来实现的，今天讲的 2PC 、 3PC 、 Paxos 算法， ZAB 算法就是干这事情。 所以今天要讲的这些的前提一定是分布式，解决的问题全部都是在分布式环境下

Zookeeper 基础 由 xpproen 创建，youj 最后一次修改 2016-12-27 在深入了解ZooKeeper的运作之前，让我们来看看ZooKeeper的基本概念。我们将在本章中讨论以下主题： 1、Architecture（架构） 2、Hierarchical namespace（层次命名空间） 3、Session（会话） 4、Watches（监视） ZooKeeper的架构 看看下面的图表。它描述了ZooKeeper的“客户端-服务器架构”。 作为ZooKeeper架构的一部分的每个组件在下表中进行了说明。 部分 描述 Client（客户端） 客户端，我们的分布式应用集群中的一个节点，从服务器访问信息。对于特定的时间间隔，每个客户端向服务器发送消息以使服务器知道客户端是活跃的。 类似地，当客户端连接时，服务器发送确认码。如果连接的服务器没有响应，客户端会自动将消息重定向到另一个服务器。 Server（服务器） 服务器，我们的ZooKeeper总体中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。 Ensemble ZooKeeper服务器组。形成ensemble所需的最小节点数为3。 Leader 服务器节点，如果任何连接的节点失败，则执行自动恢复。Leader在服务启动时被选举。 Follower 跟随leader指令的服务器节点。

Redis 5.0.5 配置文件说明 一般配置 #修改daemonize为yes，即默认以后台程序方式运行（跟使用&号强制后台运行是一个意思） daemonize yes #修改默认监听端口(一般用默认的) port 6379 #修改生成默认日志文件位置 logfile "/home/logs/redis/redis.log" #配置持久化文件存放位置 dir /home/apps/redis/data #PID文件 pidfile /home/apps/redis/redis.pid #保护模式 protected-mode no #支持集群 cluster-enabled yes Redis 配置详解. # 请注意，为了读取配置文件，必须以文件路径作为第一个参数启动Redis： # ./redis-server /path/to/redis.conf # 内存大小单位 # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024 bytes # # 单位不区分大小写，因此 1GB 1Gb 1gB 是一样的. ###############################

微信公众号： IT一刻钟 大型现实非严肃主义现场 一刻钟与你分享优质技术架构与见闻，做一个有剧情的程序员 关注可了解更多精彩内容，定期有福利相送哟 文章目录 什么是负载均衡？ 负载均衡分类 二层负载均衡 三层负载均衡 四层负载均衡 七层负载均衡 负载均衡算法 静态均衡算法： 动态负债均衡算法： 说在后面话 什么是负载均衡？ 百度词条里的解释是：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个操作单元上进行执行，共同完成工作任务。 它的目的就通过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。 负载均衡分类 负载均衡可以根据网络协议的层数进行分类，我们这里以ISO模型为准，从下到上分为： 物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。 当客户端发起请求，会经过层层的封装，发给服务器，服务器收到请求后经过层层的解析，获取到对应的内容。 二层负载均衡 二层负债均衡是基于数据链路层的负债均衡，即让负债均衡服务器和业务服务器绑定同一个虚拟IP（即VIP），客户端直接通过这个VIP进行请求，那么如何区分相同IP下的不同机器呢？没错，通过MAC物理地址，每台机器的MAC物理地址都不一样，当负载均衡服务器接收到请求之后，通过改写HTTP报文中以太网首部的MAC地址，按照某种算法将请求转发到目标机器上，实现负载均衡。

分布式系统常用的负载均衡算法 最近在做的系统上使用ES比较多，出于对ES的学习，在了解了ES的负载均衡算法之后，也相应的了解了其它的负载均衡算法，在这里做一个分享。 1：轮询法： 轮询很容易实现，将请求按顺序轮流分配到后台服务器上，均衡的对待每一台服务器，而不关心服务器实际的连接数和当前的系统负载。使用轮询策略的目的是，希望做到请求转移的绝对均衡，但付出的性能代价也是相当大的。为了保证pos变量的并发互斥，引入了重量级悲观锁synchronized，将会导致该轮询代码的并发吞吐量明显下降。 2：随机法： 通过系统随机函数，根据后台服务器列表的大小值来随机选取其中一台进行访问。由概率统计理论得知，随着调用量的增大，其实际效果越来越仅仅与平均分配流量到后台的每一台服务器，也就是轮询法的效果。 3：随机轮询法： 随机轮询，就是将随机法和轮询法结合起来，在轮询节点时，随机选择一个节点作为开始位置的index，此后每次选择下一个节点来处理请求，即（index+1）%size。 这种方式只是在选择第一个节点使用了随机方法，其他与轮询法无异，缺点和轮询一样。 4：源地址哈希法： 源地址哈希的思想是根据服务消费者请求客户端的IP地址，通过哈希函数计算得到一个哈希值，将此哈希值和服务器列表的大小进行取模运算，得到的结果便是要访问的服务器地址的序号。采用源地址哈希法进行负载均衡，相同的ip客户端

ps.本文为《从Paxos到Zookeeper 分布式一致性原理与实践》笔记之一 ZooKeeper ZooKeeper曾是Apache Hadoop的一个子项目，是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等。 ZooKeeper是Google的Chubby一个开源的实现，由雅虎创建，是Hadoop和Hbase的重要组件。 ZooKeeper没有直接采用paxos算法，而是采用了一种被称为ZAB（Zookeeper Atomic Broadcast）的一致性协议 ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 ZooKeeper可以保证如下分布式一致性特性 顺序一致性：从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中； 原子性：所有事务的请求结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么在整个集群中所有机器上都成功应用了某一个事务，要么都没有应用，没有中间状态； 单一视图：无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。 可靠性：一旦服务端成功应用了一个事务，并完成对客户端的响应

为什么要有Zookeeper？ 电视里经常会有一些狗血的设定，队长和副队长一起出去执行任务，执行完任务后副队长回来报到了，但是队长可能因为天气原因导致航班延期了，暂时回不来，这个时候副队长左等右等还等不到队长回来，而且副队长担心队长如果出事了，下面的队员没有人约束，大家可能就会松懈下来，副队长等了一个星期后，自己当队长了。 结果过了两个星期后，队长回来了，这个时候就产生了连个队长，这个时候组员就麻烦了，他们 不知道听谁 的，假设 也有可能写一份报告时，都给两位 队长。 这里面如果还有一个支援保障小队，发现队长还没回来啊，那么这个支援保障小队就去查队长是不是遇到什么事了，结果一查，队长没出事，平安大吉，那么支援保障小队就告诉副队长，你不用担心了，他没事，我们会告知委员会，委员会会选举出一个队长，选到你了会正式通知你的。 什么是Zookeeper？ Zookeeper是一个Apache下的开源分布式协调框架，就是为分布式应用提供协调服务的。 Zookeeper从设计模式的角度来理解，是一个基于观察者模式设计的分布式服务管理框架，负责存储和管理都关心的数据(状态)，然后接受观察者的注册，一旦这些数据的状态发生了变化，Zookeeper就通知已经在Zookeeper上注册的那些观察者这做出相应的反应，从而实现集群中类似Master/Slave管理模式。 特点 1

CDN- 内容推送网络 前段时间介绍了 浏览器缓存机制 ，通过浏览器缓存一方面可以改善用户的体验，而不用漫长地等待从服务器下载资源；另一方面减轻服务器压力、节省流量。 CDN 是另一种可以大幅度优化用户体验，且减轻服务器压力的技术。下面就自己了解的 CDN 技术分享下。 CDN 的实现是一组技术的组合，每个技术都可以单独成文详细讨论，这里就不深入每个技术。内容目录： 1. 什么是CDN ？ 1 2. CDN 技术原理 ... 1 2.1. 分布式存储 ... 1 2.2. 内容管理 ... 2 2.3. 负载均衡 ... 2 2.4. 网络请求的重定向 ... 2 3. CDN 资源访问流程 ... 3 4. 关于 CDN 的疑问 ... 3 4.1. 使用 CDN 后，如何获取客户端真实 IP ？ ... 3 4.2. 采用 CDN 服务以后如何保证内容的更新和同步？ ... 4 1. 什么是 CDN ？ CDN 的全称是 Content Delivery Network ，即 内容分发网络 。其目的是通过在现有的 Internet 中增加一层新的网络架构，将网站的内容发布到最接近用户的网络 " 边缘 " （边缘服务器），使用户可以就近取得所需的内容，解决 Internet 网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大

目录 开始配置主从复制 开始配置Redis Sentinel 原文: http://blog.gqylpy.com/gqy/332 "@ *** 在开始之前，我们先来看看Redis的主从复制 主从复制原理： 从服务器向主服务器发送 SYNC 命令。 主服务器接到 SYNC 命令后，会调用 BGSAVE 命令，创建一个 RDB 文件，并使用缓冲区记录接下来执行的所有写命令。 当主服务器执行完 BGSAVE 命令后，会向从服务器发送 RDB 文件，而从服务器则会接收并执行这个文件。 主服务器将缓冲区存储的所有写命令发送给从服务器执行。 --------- Redis主从复制使用的是RDB备份方式来同步主从服务器的数据的。 同步开始之后，通过主库命令传播的方式，主动复制方式实现。 2.8以后实现PSYNC饿机制，实现断线重连。 Redis主从复制的背景问题 Reids主从复制可将主节点数据同步给从节点，从节点此时有两个作用： 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来. 扩展主节点的读能力，分担主节点的读压力. . 一旦主节点宕机，从节点上位，那么就需要人为修改所有应用方的主节点地址（指定新的master地址），还需要命令所有从节点复制新的主节点. 这个问题很麻烦，而redis-sentinel就可以很好的解决这个问题. * Redis-Sentinel **