集群服务器

一. 何为session 用户使用网站的服务，基本上需要浏览器和web服务器进行多次交互，web服务器如何知道哪些请求是来自哪个会话的？ 具体方式为：在会话开始时，分配一个唯一的会话标识(sessionId)，通过cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉web服务器请求是属于哪个会话的。 如果遇到禁用cookie的情况，一般的做法就是把这个会话标识放到url的参数中。 二. 问题 因为会话信息保存在单机上，当我们的应用服务器从一台变成两台后，我们就会遇到session的问题了！ 当我们第一次访问网站时请求落到了A服务器，那么我的session就创建在A服务器上了，如果我们不做处理，就不能保证接下来的请求每次都落在同一台服务器上了，这就是session问题。 三. 解决办法： 1. session sticky 在web服务器变成多台后，如果我们可以保证同一个会话请求都能在同一个web服务器上处理，那么对于这个会话个体来说，和单机的情况是一样的。这就需要负载均衡器能够根据每次请求的会话标识来进行请求转发。 有何问题： ① 如果有一台web服务器宕机或重启，那么这台机器上的会话数据会丢失 ② 负载均衡器变成了一个有状态的结点，要保存会话到具体web服务器的映射，要消耗一定的内存。 2. session replication

1、ZooKeeper 概述 Zookeeper 是一个分布式协调服务的开源框架。 主要用来解决分布式集群中 应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。 ZooKeeper 本质上是一个分布式的小文件存储系统。 提供基于类似于文件系 统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维 护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达 到基于数据的集群管理。 诸如： 统一命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。 2、zookeeper的架构图 Leader: Zookeeper 集群工作的核心 事务请求（写操作） 的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。 对于 create， setData， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。 Follower: 处理客户端非事务（读操作） 请求， 转发事务请求给 Leader； 参与集群 Leader 选举投票 2n-1台可以做集群投票。 此外，针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。 Observer: 观察者角色，观察

三个核心选举原则： （1）Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作； （2）在集群正常工作之前，myid小的服务器给myid大的服务器投票，直到集群正常工作，选出Leader； （3）选出Leader之后，之前的服务器状态由Looking改变为Following，以后的服务器都是Follower。 zookeeper选举 来源： CSDN 作者： devcy 链接： https://blog.csdn.net/devcy/article/details/104247149

1.基本概念 下面介绍Elasticsearch的一些基本概念。 从一开始就理解这些概念将极大地帮助简化学习过程。 1.1.近实时（NRT） Elasticsearch是一个近实时搜索平台。 这意味着从索引文档到可搜索文档的时间有一点延迟（通常是一秒）。 1.2.集群 集群是一个或多个节点（服务器）的集合，它们共同保存整个数据，并提供跨所有节点的联合索引和搜索功能。 集群由唯一名称标识（集群的名字），默认情况下为“elasticsearch”。 此名称很重要，因为如果节点设置为按名称加入群集，则同名的Elasticsearch节点会加入同一个集群。 确保不要在不同的环境中重用相同的集群名称，否则最终会导致节点加入错误的群集。 例如，您可以使用 logging-dev ， logging-stage 以及 logging-prod 用于开发，生产集群。 请注意，拥有一个只包含单个节点的集群是完全正常的。 此外，您还可以拥有多个独立的集群，每个集群都有自己唯一的集群名称。 1.3.节点 节点是作为集群一部分的单个服务器（可以理解为单个Elasticsearch实例，一个进程），存储数据并参与集群的索引和搜索功能。 与集群一样，节点由名称标识，默认情况下，该名称是在启动时分配给节点的随机通用唯一标识符（UUID）。 如果不需要默认值，可以定义所需的任何节点名称。

硬件 五台服务器，一台master，三台slave，一台集群client 网络设置 机器名 IP 备注 Hadoop.mater ip1 Master,Namenode Hadoop.slave1 ip2 Slave Hadoop.slave2 ip3 Slave Hadoop.slave3 ip4 slave Hadoop.client ip5 集群client，thrift服务承载 系统设置 安装操作系统centOS6.4版本 每台机器均配置/etc/hosts文件，将除client以外的机器全部按照网络设置解析 安装sun公司的Java-jdk，要求版本至少1.6以上,安装路径:/usr/java/default 每台机器配置/etc/profile文件，添加内容如下: export JAVA_HOME=/usr/java/default export JRE_HOME=/usr/java/default export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH 每台机器添加用户组hadoopgroup,命令如下: groupadd hadoopgroup 每台机器添加用户hadoopuser useradd –G

硬件环境： 安装一个Hadoop集群时，需要专门指定一个服务器作为主节点。 三台虚拟机搭建的集群：（搭建集群时主机名不能一样，主机名在 /etc/hostname 修改） master机器：集群的主节点，驻留NameNode和JobTracker守护进程 ） dbrg1 192.168.0.102 slaves机器：（ 集群的从节点，驻留DataNode和TaskTracker守护进程 ） dbrg2 192.168.0.112 dbrg3 192.168.0.113 这三台机器都安装好了hadoop-0.20.2，JDK和ssh。 安装方法参考上一篇博文。 共有 3 台机器，均使用的 linux 系统， Java 使用的是 sun jdk1.7.0 。 1. 修改主机名和IP地址 vi /etc/hostname （分别给每一台主机指定主机名） vi /etc/hosts （分别给每一台主机指定主机名到 IP 地址的映射） 这里有一点需要强调的就是，务必要确保每台机器的主机名和 IP 地址之间能正确解析。一个很简单的测试办法就是 ping 一下主机名，比如在dbrg1 上 ping dbrg2 ，如果能 ping 通就 OK ！若不能正确解析，可以修改 /etc/hosts 文件，如果该台机器作 Namenode 用，则需要在 hosts 文件中加上集群中所有机器的 IP

调优概述 # 几乎在很多场景,MapRdeuce或者说分布式架构,都会在IO受限,硬盘或者网络读取数据遇到瓶颈.处理数据瓶颈CPU受限.大量的硬盘读写数据是海量数据分析常见情况. IO受限例子： 索引 分组 数据倒入导出 数据移动和转换 CPU受限例子： 聚类/分类 复杂的文本挖掘 特征提取 用户画像 自然语言处理 我们需要从硬件规划和软件规划等多方面结合实现性能和效率的提升。 硬件规划 # 评估集群规模 # 我们需要搭建多少节点的hadoop集群？回答这个问题考虑的因素比较多：预算？数据量？计算资源？ 需要多少计算资源可能不是特别好评估，推荐横向扩展，随业务规模和应用发展再考虑扩展。开始可以就按照数据量来评估数据规模，估计一下每天的数据增量？保存数据的周期是多少？有没有冷数据方案？ 假设每天增长的数据为600G、3备份存储，以一年规划为例,大概存储为600G 3 360天=633T, 再考虑增加%20的预留，考虑未来数据增长的趋势，考虑应用计算等空间需求。为节省空间可考虑压缩存储（大概可以节省70%空间）。 同时考虑一定冗余量，如果集群一部分节点不可用也要保证业务正常使用（根据集群规模评估冗余比例）。 然后结合节点硬件规划和预算，确定集群规模。假如我们需要650T存储，可以采用30台12 x 2TB的存储配置或者 60台6 x 2TB配置，但是节点数量翻翻

目录 · 大型网站软件系统的特点 · 大型网站架构演化发展历程 · 初始阶段的网站架构 · 需求/解决问题 · 架构 · 应用服务和数据服务分离 · 需求/解决问题 · 架构 · 使用缓存改善网站性能 · 需求/解决问题 · 架构 · 使用应用服务器集群改善网站的并发处理能力 · 需求/解决问题 · 架构 · 数据库读写分离 · 需求/解决问题 · 架构 · 使用反向代理和CDN加速网站响应 · 需求/解决问题 · 架构 · 使用分布式文件系统和分布式数据库系统 · 需求/解决问题 · 架构 · 使用NoSQL和搜索引擎 · 需求/解决问题 · 架构 · 业务拆分 · 需求/解决问题 · 架构 · 分布式服务 · 需求/解决问题 · 架构 · 大型网站架构演化心得 · 大型网站架构模式 · 综述 · 分层 · 概念 · 目的 · 举例 · 分割 · 概念 · 目的 · 举例 · 分布式 · 概念 · 目的 · 缺点 · 举例 · 集群 · 概念 · 目的 · 缓存 · 概念 · 目的 · 举例 · 异步 · 概念 · 目的 · 冗余 · 概念 · 目的 · 举例 · 自动化 · 目的 · 举例 · 安全 · 举例 · 大型网站核心架构要素 · 性能 · 网站性能测试 · 不同视角下的网站性能 · 性能测试指标 · 性能测试方法 · 性能测试报告 · Web前端性能优化 ·

服务器环境： ip client_port peer_port 10.20.48.107 2379 2380 10.20.48.108 2379 2380 10.20.48.109 2379 2380 安装etcd： 安装比较简单，我们只需要去 官方 下载包就可以 wget https://github.com/coreos/etcd/releases/download/v3.1.11/etcd-v3.1.11-linux-amd64.tar.gz tar zxvf etcd-v3.1.11-linux-amd64.tar.gz -C /usr/local/ 在 /usr/local/ 目录下 mv etcd-v3.1.11-linux-amd64.tar.gz etcdv3 ln -s /usr/local/etcdv3/etcd* /usr/local/bin/ 在 /etc/profile 中添加环境变量 export ETCDCTL_API=3 配置说明： 123456789 name: initial-advertise-peer-urls: #该成员的对等url列表，用于向集群的其他成员通告（告诉其他成员通过什么url和我通信）listen-peer-urls: # 本地监听，接收同等节点请求的端口listen-client-urls: # 本地监听

RocketMQ初步应用架构理论 写给RocketMQ架构应用入门，内容涉及它的设计机理以及推到出来的应用注意事项，入门人员请看。 稍微涉及技术细节，留以我设计中间件时参考，将来整理深度文档时会抽取走，入门人员可以无视。 以下RocketMQ简称为RQ，理论部分采用版本为3.2.4，测试部分采用版本为3.2.6。 MQ的需求 我们对MQ的需求，相比JMS标准有几点要求更高： 1. 必须优美灵活地支持集群消费。 2. 尽量支持消息堆积。 3. 服务高可用性和消息可靠性。 4. 有起码的运维工具做集群管理和服务调整。 其他 提供顺序消息、事务、回溯等面向特别场景的功能更好，目前暂不需要。 RQ架构 RQ的基本组成包括nameserver、broker、producer、consumer四种节点，前两种构成服务端，后两种在客户端上。 还有其他辅助的进程，不提。 NameServer的基本概念 在没有NameServer的中间件中，服务端集群就由干活的broker组成 ，其中的实例分主从两种角色。那么客户端就要知道，需要连接到哪个地址的broker上去做事情，于是客户端就需要配置服务端机器的IP地址，如果服务端部署结构复杂，客户端的配置结构也挺复杂，更讨厌的是甚至可能需要客户端也得更新地址配置。由于有了两种思路的方案： 一是引入NameServer，负责提供地址