节点服务器

一、 heartbeat的概念 Linux-HA的全称是High-Availability Linux，它是一个开源项目，这个开源项目的目标是：通过社区开发者的共同努力，提供一个增强linux可靠性（reliability）、可用性 （availability）和可服务性（serviceability）（RAS）的群集解决方案。其中Heartbeat就是Linux-HA项目中 的一个组件，也是目前开源HA项目中最成功的一个例子，它提供了所有 HA 软件所需要的基本功能，比如心跳检测和资源接管、监测群集中的系统服务、在群集中的节点间转移共享 IP 地址的所有者等，自1999年开始到现在，Heartbeat在行业内得到了广泛的应用，也发行了很多的版本，可以从Linux-HA的官方网站www.linux-ha.org下载到Heartbeat的最新版本。 二、 HA集群中的相关术语 1．节点（node） 运行heartbeat进程的一个独立主机，称为节点，节点是HA的核心组成部分，每个节点上运行着操作系统和heartbeat软件服务，在 heartbeat集群中，节点有主次之分，分别称为主节点和备用/备份节点，每个节点拥有唯一的主机名，并且拥有属于自己的一组资源，例如，磁盘、文件 系统、网络地址和应用服务等。主节点上一般运行着一个或多个应用服务。而备用节点一般处于监控状态。 2．资源

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。本文简单分析zookeeper的工作原理，对于如何使用zookeeper不是本文讨论的重点。 1 Zookeeper的基本概念 1.1 角色 Zookeeper中的角色主要有以下三类，如下表所示： 系统模型如图所示： 1.2 设计目的 1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。 2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。 3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 4 .等待无关（wait-free）

一、ZooKeeper 基本概念 1、ZooKeeper 是什么？ Zookeeper官网地址： http://zookeeper.apache.org/ Zookeeper官网文档地址： http://zookeeper.apache.org/doc/trunk/index.html ZooKeeper 是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，简单示例图如下： 2、ZooKeeper设计目标： ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。 名称空间由ZooKeeper中的数据寄存器组成 - 称为znode，这些类似于文件和目录。 与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

1. Ceph简介 所有的 Ceph 存储集群的部署都始于一个个 Ceph节点、网络和 Ceph存储集群。Ceph 存储集群至少需要一个 Ceph Monitor、一个 Manager和一个Ceph OSD 守护进程。在运行 Ceph 作为文件存储时，还需要 Ceph 元数据服务。 Monitors ： Ceph监视器（ceph-mon） 维护集群状态的映射，包括监视器映射、管理器映射、OSD映射和 CRUSH 映射。这些映射是Ceph守护进程相互协调所需的关键集群状态。Monitor还负责管理守护进程和客户机之间的身份验证。为了冗余和高可用性，通常至少需要三个监视器。 Managers: Ceph 管理进程（ceph-mgr） 守护进程负责跟踪Ceph集群的运行指标和当前状态，包括存储利用率、当前性能指标和系统负载。Ceph Manager 守护进程还托管基于python的模块来管理和公开Ceph集群信息，包括基于web的Ceph dashboard 和 REST API 高可用通常需要至少两个管理器。 Ceph OSDs: 对象存储守护进程（ceph-osd） 存储数据，处理数据复制，恢复，重新平衡并通过检查其他Ceph OSD 守护进程的心跳来为Ceph Monitor 和 Manager 提供一些监控信息，至少3 Ceph OSDs通常需要冗余和高可用性。 MDSs ：

在国内，服务器放国外的平台有不少，我们公司就是，有些视频资源就是一直放国外，不知道为啥，但访问速度确实不行，最近就在处理这个问题，发现了个小窍门，在这里跟大家分享一下： 我们公司用的CDN是猫云的，访问速度提升了不少，但有时候还是会出问题，比如下面这个： 视频打不开了~~~ 吓得我赶紧跟猫云的技术沟通，问咋回事： 处理完以后~~~ 很快就可以播放了，猫云的技术说，出这种情况主要是我把域名解析到服务器的IP上，直接跳到源站导致的。 优化方案主要有两步，第一步就是看有没有解析到cname，就是在添加加速域名的时候，把原来的A记录替换成cname。 第二步就是让CDN服务商优化一下回源链路。这个原理很简单，就是原来的链路可能是从美国节点到澳洲节点再到日本节点再到中国；优化后，链路可能变成美国节点到日本节点再到中国，这样物理距离近了，访问速度也就快了。 重点说下优化一下链路，这个需要CDN服务商去操作，猫云这边的技术支持还比较及时，不用走工单，所以还比较方便。 总之，是个使用CDN过程中的一点经验，希望在用CDN的童鞋别再犯这种错误。 来源： https://www.cnblogs.com/maocloud/p/11891184.html

本文Apache+Tomcat集群配置 基于最新的Apache和Tomcat，具体是2011年4月20日最新的Tomcat和Apache集群和负载均衡配置。 准备环境 Apache Apache 是 http 服务器，我们利用其对 Tomcat 进行负载均衡。目前最新版本为 2.2.17 ，下载地址为 http://httpd.apache.org/download.cgi#apache22 。如下图： 目前已经出现 Apache2.3.11 ，但是为 beta 版本，所以没有使用。 下载后直接安装 msi 即可，如果没有其他的 http 服务器 ( 如 iis) 则应该可以成功安装，端口即为 80 ，能够访问 http://localhost/ 说明安装成功。 Tomcat Tocmat7 目前已经出现稳定版本的 7.0.12 ， Tomcat6 则为 6.0.32 。经我测试，这 2 个版本的 Apache 负载均衡配置过程都是一样的，因此下面的配置在 Tomcat6 或 7 集群是通用的。 但是按照下面的配置，集群中 Tomcat 不能既有 Tomcat6 又有 Tomcat7 ，否则虽能够负载均衡，但不能进行 session 复制，不知其他方式配置的集群是否可以。 Tomcat 就不用怎么介绍了。既然在本地需要多个节点，那么需要下载 ZIP 版本的 Tomcat 。 JK

1. 为啥在项目里要用缓存呢 用缓存，主要是俩用途，高性能和高并发 高性能 image.png 高并发 image.png 2.介绍 Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。 传统数据库（关系型数据库）遵循 ACID 规则。而 Nosql（非关系型数据库）（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式，而分布式一般遵循 CAP 定理。 CAP理论 C:consistency(一致性) A:avalibility(可用性) P:Partition(分区)-tolerence to partition(分区容忍度) 分区：一个分布式系统，网络不通讯，导致连接不通，系统被分割成几个数据区域 原因：数据不连通了，产生数据分区 影响： 查还好一点 数据修改时，必须要求数据一致--加锁，实现数据一致性【需求要求数据一致性】 数据修改时，可以数据不一致--不用加锁【需求不要求数据一致性】 分区容忍度 数据的一致性要求高，容忍度高，加锁 数据的一致性要求低，容忍度低，可以不加锁 预期结果，保持数据的一致 可用性 请求在一定时间段内都应该有响应 为了解决锁一直加着 CP理论：【一致性+分区

#0 系列目录# Zookeeper系列 【Zookeeper系列一】Zookeeper应用介绍与安装部署 【Zookeeper系列二】ZooKeeper典型应用场景实践 【Zookeeper系列三】ZooKeeper Java API使用 【Zookeeper系列四】ZooKeeper 分布式锁实现 【Zookeeper系列五】ZooKeeper 实时更新server列表 【Zookeeper系列六】Zookeeper 工作原理 Zookeeper源码 【Zookeeper源码一】Zookeeper 源码环境搭建 【Zookeeper源码二】Zookeeper 客户端创建连接过程分析 【Zookeeper源码三】Zookeeper 单机版服务器介绍 【Zookeeper源码四】Zookeeper 集群版服务器介绍 【Zookeeper源码五】Zookeeper 集群版建立连接过程 Zookeeper应用 基于ZooKeeper的分布式Session实现 #1 Zookeeper概述# ZooKeeper是一个为分布式应用所设计的分布的、开源的协调服务，它主要是 用来解决分布式应用中经常遇到的一些数据管理问题，简化分布式应用协调及其管理的难度，提供高性能的分布式服务 。ZooKeeper本身可以 以Standalone模式安装运行 ，不过

由于 ROS 系统的组织架构比较复杂，简单从一个方面来说明很难说清楚。按照 ROS 官方的说法，我们可以从 3 个方面来理解 ROS 系统整体架构，这 3 个方面分别是文件系统级、计算图级、开源社区级。 1. 从文件系统级理解 ROS 架构 如果你是刚刚接手 ROS 方面的开发或项目，你肯定会觉得 ROS 中的各种概念非常奇怪，但是当你对 ROS 的使用熟练之后，你就觉得这些概念很好理解了。与其他操作系统相似，一个 ROS 程序的不同组件要被放在不同的文件夹下，这些文件夹是根据不同的功能来对文件进行组织的，如图 3 。 （图 3 ）文件系统级理解 ROS 架构 （ 1 ）工作空间 工作空间是一个包含功能包、可编辑源文件和编译包的文件夹，当你想同时编译不同的功能包时非常有用，并且可以保存本地开发包。当然，用户可以根据自己的需要创建多个工作空间，在每个工作空间中开发不同用途的功能包。不过作为学习，我们先以一个工作空间为例。如图 3 ，我们创建了一个名为 catkin_ws 的工作空间，该工作空间下会有 3 个文件夹： src 、 build 、 devel 。 src 源文件空间 ：这个文件夹放置各个功能包和一个用于这些功能包的 CMake 配置文件 CMakeLists.txt 。这里做一下说明，由于 ROS 中的源码采用 catkin 工具进行编译，而 catkin 工具又是基于

以下部分想看懂得有一定的redis基础，且步骤是连贯的，错一步都不行。redis运行多个实例，不懂得自行百度。 1. redis主从同步 原理： 从服务器向主服务器发送 SYNC 命令。 接到 SYNC 命令的主服务器会调用BGSAVE 命令，创建一个 RDB 文件，并使用缓冲区记录接下来执行的所有写命令。 当主服务器执行完 BGSAVE 命令时，它会向从服务器发送 RDB 文件，而从服务器则会接收并载入这个文件。 主服务器将缓冲区储存的所有写命令发送给从服务器执行。 ------------- 1、在开启主从复制的时候，使用的是RDB方式的，同步主从数据的 2、同步开始之后，通过主库命令传播的方式，主动的复制方式实现 3、2.8以后实现PSYNC的机制，实现断线重连 2. redis主从同步实验 2.1 准备三个redis数据库配置文件 背景： 一主两从 6380为主，6381和6382 为从 cd /opt/redis_conf vim redis-6380.conf 写入以下配置 port 6380 daemonize yes pidfile /data/6380/redis.pid loglevel notice logfile "/data/6380/redis.log" dbfilename dump.rdb dir /data/6380 protected-mode