节点服务器

1、什么是Redis？ Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 2、Redis相比memcached有哪些优势？ (1) memcached所有的值均是简单的字符串，redis作为其替代者， 支持更为丰富的数据类型 (2) redis的速度比memcached快很多 (3) redis可以持久化其数据 3、Redis支持哪几种数据类型

讲述反向七层代理的配置文件以及解释 Nginx官网： https://www.nginx.com/ Centos yum安装nginx yum install nginx -y so，我们先提个问题，What？为何要用Nginx实现七层代理，什么是七层代理？ 1、有无nginx proxy的区别 传统无nginx web架构： 看下面一张图： 首先，我们有一个域名 www.test_app.com，后端有三台服务器，都运行PHP+Nginx服务，如果要实现三台服务器都提供网站服务，我们需要具备下面几个条件（缺点）。 1、每台web服务器都需要有固定的公网IP地址（成本高） 2、一个域名需要对应多个公网IP（扩展性差） 3、每添加一台web服务器都需要动用dns配置以及购买固定公网IP（灵活性差） so,缺点很明显了 nginx proxy架构： 这时，我们在前端部署一台nginx proxy（反向代理），就可以解决刚才上面所说的问题，可以在nginx proxy配置proxy pool，称为代理池，里面填写后端web节点的IP:PORT，每次扩展一台Web节点的时候，只需要在该proxy pool中添加IP:PORT，然后在reload一下nginx即可，并且该nginx proxy只需要有一个固定的公网IP即可，DNS只需要绑定该公网IP 2、Nginx Proxy简介

proxmox是一款开源的虚拟化管理平台，在服务器虚拟化方面有不俗的表现。曾经有个单cpu 4线程、16G内存、300G硬盘开20多个centos，并且上面的应用都是tomcat的交易系统，稳定运行大半年的记录（公司倒闭，服务器被下架）。后来，陆续迁移一些陈旧物理服务器上的应用到proxmox虚拟化平台，也是受益多多。从proxmox5.版本开始，整合了分布式文件系统ceph，并对其进行了改进。官方的用语是：Compute, network and storage in a single solution。字面理解是计算、网络、存储一体化解决方案。用流行的术语就是“超融合”嘛！不知道这个词是不是国人发明的，可能外国鬼子不晓得？ 没有比较就没有伤害，下边我来列举一些自己认为比较有用的特征： 去中心化 ：集群节点去中心化、分布式存储也去中心化。这意味着，只要节点之间能组成最基本的集群，哪个物理节点发生故障都不会影响可用性。比如三个节点的集群，可以任意死掉一个。而传统方式的虚拟化高可用方案，多采用昂贵的、高性能的外挂存储来解决问题，但是存储本身也是单点，一旦它发生故障，一定是全军覆没。 超融合 ：操作系统、存储、虚拟化平台、网络一体化，无需外挂共享存储。除此之外，还可以充分利用剩余的计算资源，用于桌面系统的虚拟化，外购云终端盒子，直接取代耗能、占空间、不易于维护的台式电脑主机。 易于实施

什么是分片 高数据量和吞吐量的数据库应用会对单机的性能造成较大压力，大的查询量会将单机的CPU耗尽，大的数据量对单机的存储压力较大，最终会耗尽系统的内存而将压力转移到磁盘IO上。 MongoDB分片是使用多个服务器存储数据的方法，以支持巨大的数据存储和对数据进行操作。分片技术可以满足MongoDB数据量大量增长的需求，当一台MongoDB服务器不足以存储海量数据或者不足以提供可接受的读写吞吐量时，我们就可以通过在多台服务器上分割数据，使得数据库系统能存储和处理更多的数据。 MongoDB分片优势 分片为应对高吞吐量与大数据量提够了方法 使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，群集可以提高自己的存储容量。比如，当插入一条数据时，应用只需要访问存储这条数据的分片。 使用分片减少了每个分片村存储的数据 分片的优势在于提供类似线性增长的架构，提高数据可用性，提高大型数据库查询服务器的性能。当MongoDB单点数据库服务器存储成为瓶颈、单点数据库服务器的性能成为瓶颈或需要部署大型应用以充分利用内存时，可以使用分片技术。 MongoDB分片群集的组成 Shard：分片服务器，用于存储实际的数据块，实际生产环境中一个shard server 角色可以由几台服务器组成一个Peplica Set 承担，防止主机单点故障。 Config Server：配置服务器

前言 相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 是个什么东西吗？如果别人/面试官让你给他讲讲 ZooKeeper 是个什么东西，你能回答到什么地步呢？ 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 solr 集群的时候，我使用到了 ZooKeeper 作为 solr 集群的管理工具。前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？想了半天，脑海中只是简单的能浮现出几句话：“①Zookeeper 可以被用作注册中心。 ②Zookeeper 是 Hadoop 生态系统的一员；③构建 Zookeeper 集群的时候，使用的服务器最好是奇数台。” 可见，我对于 Zookeeper 的理解仅仅是停留在了表面。 所以，通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。如果没有学过 ZooKeeper ，那么本文将会是你进入 ZooKeeper 大门的垫脚砖。如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 最后，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。 网上有介绍 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章

一、ZooKeeper简介 1. ZooKeeper是什么 ​ Apache ZooKeeper是一个开源的分布式服务框架，为分布式应用提供协调服务，用来解决分布式应用中的数据管理问题，如：配置管理、域名服务、分布式同步、集群管理等 官网 https://zookeeper.apache.org/ ZooKeeper视频教程 http://edu.51cto.com/course/16190.html 2. ZooKeeper组成 ​ 主要包括两部分：文件系统、通知机制 2.1 文件系统 ​ ZooKeeper维护一个类似Linux文件系统的数据结构，用于存储数据 数据模型结构是一种树形结构，由许多节点构成 每个节点叫做ZNode（ZooKeeper Node） 每个节点对应一个唯一路径，通过该路径来标识节点，如 /app1/p_2 每个节点只能存储大约1M的数据 ​ 节点类型有四种： 持久化目录节点 persistent 客户端与服务器断开连接，该节点仍然存在 持久化顺序编号目录节点 persistent_sequential 客户端与服务器断开连接，该节点仍然存在，此时节点会被顺序编号，如：000001、000002..... 临时目录节点 ephemeral 客户端与服务器断开连接，该节点会被删除 临时顺序编号目录节点 ephemeral_sequential

目前市场上的产品主要分为两种：一种是像花椒、映客、斗鱼、YY等的泛娱乐化直播，一种是思科、声网之类的实时互动直播。一般情况下实时互动直播会与PSTN网络相连，所以实时互动直播必须达到电话级别的传输要求，一般不超过400ms。 泛娱乐化直播架构 在泛娱乐化直播架构中有信令服务器集群来负责创建房间、聊天、赠送礼物…，当直播端需要直播时直接向信令服务器发送请求，信令服务器向请求端返回推流的地址，然后直播端开始像CDN网络推送数据流（流媒体CDN与传统CDN有些不同），然后当观众需要观看直播时，使用同样的方式请求直播地址，然后在流媒体CDN拉取数据流，具体如图所示： 实时互动直播架构 众所周知，实时互动直播架构对传输效率要求高，因此客户端使用UDP协议向媒体服务器推流，由于要保证服务器7x24小时的服务，所以通过私有网络建立了服务器集群，直播端向媒体服务器推流。由于使用了多个直播服务节点，所以需要控制中心来控制这些节点以达到负载均衡、健康评估等的目的。每个节点通过内总线向控制中心发送心跳包，控制中心通过心跳包来分析服务节点的健康状况来做出相应的决策。使用内总线的原因一是为了数据的安全性，二是为了数据的时效性。那么有时候实时互动也需要多人观看，所以上面讲解的泛娱乐化直播架构与实时互动直播架构进行融合

一、NFS应用场景 1、NFS（Network File system）是一种基于TCP/IP传输的网络文件系统协议 2、通过使用NFS协议，NFS客户机可以像访问本地目录一样访问远程NFS服务器中的共享资源。 3、在企业群集架构的工作场景中，特别是中小型网站公司，NFS网络文件系统一般被用来存储共享视频、图片等静态资源文件。列如将网站用户上传的文件放到NFS共享里面，通过网络共享，让网络上的其他服务器能够挂载访问共享目录内的数据 二、系统环境 1、一台Centos7作为NFS服务器绑定同一块网卡vnet1：192.168.80.100 2、两台Centos7分别作为Tomcat服务器且绑定同一块网卡vnet1。 对应的IP地址分别为：192.168.80.120 192.168.80.130 3、对应拓扑图如下： 其中测试终端为win10真机，NFS服务器上传商城项目，tomcat挂载到NFS服务器上，最在测试终端访问。 三、案列部署 部署NFS服务器 1、安装nfs-utils、rpcbind软件包 yum install nfs-utils rpcbind -y 2、设置共享目录 vi /etc/exports //编译配置文件 加入下面内容 /opt/tomcatpub *(rw,sync) //指定共享目录的路径和权限 mkdir /opt/tomcatpub /

一、概要 随着系统日益庞大、逻辑业务越来越复杂，系统架构由原来的单一系统到垂直系统，发展到现在的分布式系统。分布式系统中，可以做到公共业务模块的高可用，高容错性，高扩展性，然而，当系统越来越复杂时，需要考虑的东西自然也越来越多，要求也越来越高，比如服务路由、负载均衡等。此文将针对负载均衡算法进行讲解，不涉及具体的实现。 二、负载均衡算法 在分布式系统中，多台服务器同时提供一个服务，并统一到服务配置中心进行管理，消费者通过查询服务配置中心，获取到服务到地址列表，需要选取其中一台来发起RPC远程调用。如何选择，则取决于具体的负载均衡算法，对应于不同的场景，选择的负载均衡算法也不尽相同。负载均衡算法的种类有很多种，常见的负载均衡算法包括轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接法、Latency-Aware等，应根据具体的使用场景选取对应的算法。 1、轮询（Round Robin）法 轮询很容易实现，将请求按顺序轮流分配到后台服务器上，均衡的对待每一台服务器，而不关心服务器实际的连接数和当前的系统负载。使用轮询策略的目的是，希望做到请求转移的绝对均衡，但付出的代价性能也是相当大的。为了保证pos变量的并发互斥，引入了重量级悲观锁synchronized，将会导致该轮询代码的并发吞吐量明显下降。 轮询法适用于机器性能相同的服务，一旦某台机器性能不好，极有可能产生木桶效应

Dubbo 初步认识dubbo及基本应用 官方网址：http://dubbo.apache.org 由于业务的复杂度公司服务不断增多，那么远程服务之 间的调用才是实现分布式的关键因素。 服务与服务之间的调用无非 就是跨进程通信而已，我们可以使用 socket 来实现通信，我们也可以使用 nio来实现高性能通信。我们不用这些开源的RPC框架，也可以完成通信的过程。 官方图解： 图解说明： 节点 角色说明 Provider 暴露服务的服务提供方 Consumer 调用远程服务的服务消费方 Registry 服务注册与发现的注册中心 Monitor 统计服务的调用次数和调用时间的监控中心 Container 服务运行容器 但是为什么要用现成的框架呢？ 1. 底层网络通信协议的处理 ； 2. 序列化和反序列化的处理工作 ； 3. 网络请求之间的负载均衡、容错机制、服务降级机制等等要一一处理太麻烦； 大规模服务化对于服务治理的要求 ？ 我认为到目前为止，还只是满足了通信的基础需求，但是当企业开始大规模 的服务化以后，远程通信带来的弊端就越来越明显了。比如说 1. 服务链路变长了，如何实现对服务链路的跟踪和监控呢？ 2. 服务的大规模集群使得服务之间需要依赖第三方注册中心来解决服务的 发现和服务的感知问题 3. 服务通信之间的异常，需要有一种保护机制防止一个节点故障引发大规模 的系统故障