节点服务器

常见的 Web集群调度器 目前常见的 Web 集群调度器分为软件和硬件，软件通常使用开源的LVS、Haproxy、Nginx，硬件一般使用比较多的是 F5，也有很多人使用国内的一些产品，如梭子鱼、绿盟等 Haproxy应用分析 ■LVS在企业应用中抗负载能力很强，但存在不足 LVS不支持正则处理，不能实现动静分离 对于大型网站，LVS的实施配置复杂，维护成本相对较高 ■Haproxy是一款可提供高可用性、负载均衡、及基于TCP和HTTP应用的代理的软件 特别适用于负载特别大的Web站点 运行在当前的硬件上可支持数以万计的并发连接连接请求 Haproxy 调度算法原理 Haproxy 支持多种调度算法，最常用的有三种: ●RR (Round Robin) RR算法是最简单最常用的一-种算法，即轮询调度 理解举例 有三个节点A、B、C,第一个用户访问会被指派到节点A,第二个用 户访问会被指派到节点B，第三个用户访问会被指派到节点 第四个用户访问继续指派到节点A，轮询分配访问请求实现负载均衡效果 ●LC (Least Connections) LC算法即最小连接数算法，根据后端的节点连接数大小动态分配前端请求 理解举例 有三个节点A、B、C,各节点的连接数分别为A:4、B:5、 C:6, 此时如果有第 一个用户连接请求，会被指派到A上，连接数变为A:5、B:5、 C:6

[一曲广陵不如晨钟暮鼓] 通过前面的一系列文章，我们给大家介绍了RabbitMQ的基本用法。从本文开始，我们将介绍关于RabbitMQ的服务器配置的相关内容，鉴于英语水平比较渣，建议各位看官在学习的时候最好对比官方文档一起看，如果发现不合适的地方，欢迎积极留言！ 官方文档：http://www.rabbitmq.com/configure.html#configuration-file -------------------------------------------------------------------------------------------------------------------------------------------------------- RabbitMQ configuration 概述 RabbitMQ本身内置了一份配置信息，并且很大程度上能够很好的满足大多数的应用场景。如果其能够正常运行的，那么你可能就不在需要配置其他任何信息了。 RabbitMQ提供3种通用的方式来满足服务器上个性化的需求： 环境变量（environment variables）：默认端口，文件未知，节点名称（或者在shell上进行设置，或者在环境配置文件中配置，rabbitmq-env.conf/rabbitmq-env-conf.bat） 配置文件（a

Leader选举 Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。 (1) 服务器初始化启动。（集群的每个节点都没有数据 → 以SID的大小为准） (2) 服务器运行期间无法和Leader保持连接。（集群的每个节点都有数据 ,或者Leader 宕机→ 以ZXID 和 SID 的最大值为准） 1. 服务器启动时期的Leader选举 若进行Leader选举，则至少需要2台机器，两台的高可用性会差一些，如果Leader 宕机，就剩下一台，自己没办法选举。这里选取3台机器组成的服务器集群为例。 在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下 (1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。 (2) 接受来自各个服务器的投票

第2章 理解消息通信 2.2 此底部开始构造：队列 信道(channel)是建立在TCP连接上的虚拟连接。因为如果每个生产者/消费者都使用真实的TCP连接的话，每一个线程连接到RabbitMQ，都会建立一个TCP连接，不仅会造成TCP连接的巨大浪费(创建和销毁TCP回话开销很大)，而且操作系统每秒也就只能建立这点数量的连接，很快就会碰到性能瓶颈。 如图，一条电缆(TCP连接)有许多光纤束(信道)，运行所有连接的线程通过多条光纤束同时进行传输和接收。 当一个RabbitMQ队列有多个消费者时，队列收到的消息将以循环的方式发送给消费者，每个消息只发送给一个订阅的消费者。 消费者接收到的每一条消息都必须进行确认 或者在订阅到队列的时候讲auto_ack参数设置为true 当设置了auto_ack时，一旦消费者接收消息，RabbitMQ会自动视其确认了消息。消费者通过确认命令告诉RabbitMQ它已经正确接收了消息，此时RabbitMQ才能安全地把消息从队列中删除。 如果消费者收到一条消息，但是确认之前从Rabbit断开连接(或者从队列上取消了订阅)，RabbitMQ会认为这条消息没有分发， 然后重新分发给下一个订阅的消费者 。另一方面，如果消费者没有确认消息， Rabbit讲不会给该消费者发送更多消息 ，这是因为在上一条消息被确认之前，Rabbit会认为这个消费者没有准备好接收下一条消息

Config Server是干嘛的 配置服务器保留有所有分片节点的元数据，这些元数据包括所有分片节点状态，副本节点的组织结构以及副本节点数据存储位置。 元数据包括,每个分片节点的chunk信息以及这些chunk对应的range区间定义。 通过这些数据将读写操作正确的路由到对应的分片节点上。 如果集群的元数据信息变化，管理程序mongod将会进行更新操作:chunk分裂,添加分片节点。 分片节点同样需要从配置服务器读取这些数据。 配置服务器同样保存授权信息，比如:用户访问授权，和内部授权等。 使用配置服务器来管理分布式锁机制。 每一个分片集群都应该有自己的配置服务器，不要使用多个集群使用同一个。 授权操作可能会影响到分片节点的性能和使用，如果配置服务器被影响的数量较多，可能会导致分片节点仅仅只能进行读操作，或者是下线一段时间。 配置服务器副本集 以前mongo是使用镜像快照的方式进行备份。 配置服务器可以使用分片节点副本集机制来提高配置服务间的同步性能。 因为有多副本配置服务器，所以可以允许不同的分片节点选择访问某一个配置服务器，形成了n:m的格局，而不是1:1，减轻了压力，也提高了性能。 副本集配置服务器有如下三原则: 不能有决策者。 不能有短板成员，(延迟高)。 必须创建索引。 配置服务器的读写操作 admin数据库保存着授权和认证，和其他的数据库系统的system数据库一样。

Config Server是干嘛的 配置服务器保留有所有分片节点的元数据，这些元数据包括所有分片节点状态，副本节点的组织结构以及副本节点数据存储位置。 元数据包括,每个分片节点的chunk信息以及这些chunk对应的range区间定义。 通过这些数据将读写操作正确的路由到对应的分片节点上。 如果集群的元数据信息变化，管理程序mongod将会进行更新操作:chunk分裂,添加分片节点。 分片节点同样需要从配置服务器读取这些数据。 配置服务器同样保存授权信息，比如:用户访问授权，和内部授权等。 使用配置服务器来管理分布式锁机制。 每一个分片集群都应该有自己的配置服务器，不要使用多个集群使用同一个。 授权操作可能会影响到分片节点的性能和使用，如果配置服务器被影响的数量较多，可能会导致分片节点仅仅只能进行读操作，或者是下线一段时间。 配置服务器副本集 以前mongo是使用镜像快照的方式进行备份。 配置服务器可以使用分片节点副本集机制来提高配置服务间的同步性能。 因为有多副本配置服务器，所以可以允许不同的分片节点选择访问某一个配置服务器，形成了n:m的格局，而不是1:1，减轻了压力，也提高了性能。 副本集配置服务器有如下三原则: 不能有决策者。 不能有短板成员，(延迟高)。 必须创建索引。 配置服务器的读写操作 admin数据库保存着授权和认证，和其他的数据库系统的system数据库一样。

1、ZooKeeper介绍与核心概念 1.1 简介 ZooKeeper最为主要的使用场景，是作为分布式系统的分布式协同服务。在学习zookeeper之前，先要对分布式系统的概念有所了解，否则你将完全不知道zookeeper在分布式系统中起到了什么作用，解决了什么问题。 1.2分布式系统面临的问题 我们将分布式系统定义为：分布式系统指的是同时跨越多个物理主机，将一个完整的系统划分为多个独立运行的子系统，这些子系统之间互相协作构成一个完整的系统功能。类比一下，分布式系统就是将一个完整的任务细分为多个子任务，一群人分别完成一个子任务，最终完成整个任务。人多力量大，每个服务器的算力是有限的，但是通过分布式系统，由n个服务器组成起来的集群，算力是可以无限扩张的。 说起分布式就要谈谈集群，两者很相似，都是通过网络协同多台主机服务器节点完成整体的功能。 但不同点在于： 集群中的每个服务器节点都完成的是同一个功能，比如mysql数据库集群、redis集群； 而分布式系统则是各个服务器节点所负责的是不同的子系统（任务或者说功能），比如电商系统的分布式系统会分为订单系统、支付系统、数据库系统、缓存系统等等。 所谓分布式集群系统，就是将一个完整的系统进行拆分多个子系统，每个子系统都进行集群部署，各系统集群之间互相协作，就能构成一个分布式集群系统。 优点显而易见，人多干活快，并且互为备份。但是缺点也很明显

多级缓存的分层架构 前言 在互联网高速发展的今天，缓存技术被广泛地应用。无论业内还是业外，只要是提到性能问题，大家都会脱口而出“用缓存解决”。 这种说法带有片面性，甚至是一知半解，但是作为专业人士的我们，需要对缓存有更深、更广的了解。 缓存技术存在于应用场景的方方面面。从浏览器请求，到反向代理服务器，从进程内缓存到分布式缓存。其中缓存策略，算法也是层出不穷，今天就带大家走进缓存。 正文 缓存对于每个开发者来说是相当熟悉了，为了提高程序的性能我们会去加缓存，但是在什么地方加缓存，如何加缓存呢？ 假设一个网站，需要提高性能，缓存可以放在浏览器，可以放在反向代理服务器，还可以放在应用程序进程内，同时可以放在分布式缓存系统中。 从用户请求数据到数据返回，数据经过了浏览器，CDN，代理服务器，应用服务器，以及数据库各个环节。每个环节都可以运用缓存技术。 从浏览器/客户端开始请求数据，通过 HTTP 配合 CDN 获取数据的变更情况，到达代理服务器（Nginx）可以通过反向代理获取静态资源。 再往下来到应用服务器可以通过进程内（堆内）缓存，分布式缓存等递进的方式获取数据。如果以上所有缓存都没有命中数据，才会回源到数据库。 缓存的请求顺序是：用户请求 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 进程内缓存 → 分布式缓存 → 数据库。 看来在技术的架构每个环节都可以加入缓存

本篇包含 1、 RabbitMQ 的可靠性消息的发送 2、 RabbitMQ 集群的原理与高可用架构的搭建 3、 RabbitMQ 的实践经验 上篇包含 1、MQ 的本质，MQ 的作用 2、RabbitMQ 的特性，工作模型，交换机详解 3、Java API 编程，UI 管理界面 4、进阶知识：TTL、死信队列、延迟队列，服务端流控和消费端限流 5、Spring AMQP 核心组件 1. RabbitMQ 可靠性投递与高可用架构 1.1. 可靠性投递 在代码里面一定是先操作数据库再发送消息。避免因为数据库回滚导 致的数据不一致。 但是如果先操作数据，后发送消息，发送消息出了问题，那不是一样 会出现业务数据的不一致？ 分析 RabbitMQ 的可靠性投递，也就是在使用 RabbitMQ 实现异步通 信的时候， 消息丢了怎么办，消息重复消费怎么办？ 在 RabbitMQ 里面提供了很多保证消息可靠投递的机制，这个也是 RabbitMQ 的一 个特性。 我们在讲可靠性投递的时候，必须要明确一个问题，因为效率与可靠性是无法兼得 的，如果要保证每一个环节都成功，势必会对消息的收发效率造成影响。所以如果是一 些业务实时一致性要求不是特别高的场合，可以牺牲一些可靠性来换取效率。 比如发送通知或者记录日志的这种场景，如果用户没有收到通知，不会造成业务影 响，只要再次发送就可以了。

LVS简介 LVS（Linux Virtual Server）即Linux虚拟服务器 ，是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如图1所示，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器，比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模式、TUN模式、以及DR模式。 了解负载均衡群集的原理 群集的含义 **Cluster,集群，群集** 由多台主机构成，但对外只表现为一个整体 在互联网应用中，随着站点对硬件性能，响应速度，服务稳定性，数据可靠性等要求越来越高，单台服务器力不从心 ** 解决方法** 使用价格昂贵的小型机，大型机 使用普通服务器构建服务群集 群集的分类 根据群集所针对的目标差异，可分为三种类型 负载均衡群集