集群服务器

背景 作为中国最大的在线教育站点，目前沪江日志服务的用户包含网校，交易，金融，CCTalk 等多个部门的多个产品的日志搜索分析业务，每日产生的各类日志有好十几种，每天处理约10亿条（1TB）日志，热数据保留最近7天数据，冷数据永久保存。 为什么做日志系统 首先，什么是日志？ 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 我认为，日志数据在以下几方面具有非常重要的作用： 数据查找 ：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断 ：通过对日志信息进行统计、分析

Mongodb安全认证在单实例和副本集两种情况下不太一样，单实例相对简单，只要在启动时加上 --auth参数即可，但副本集则需要keyfile。 一、单实例 1.启动服务（先不要加auth参数） 2.登陆后切换到admin库并添加管理员账号 2.1 创建系统管理员用户 默认条件下，超级管理员只能用于帐号管理，不能进行其他数据库操作，可以通过自己给自己授权实现。生产环境中的管理员，如果某个帐号包含了角色userAdminAnyDatabase或者userAdmin，就应该仅仅用于帐号和角色管理，不应该再授予别的角色了。 （1）我们首先就要建立一个超级管理员，然后再用超级管理员建立其他帐号： use admin db.addUser( { user: "superman", pwd: "talent", roles: [ "userAdminAnyDatabase" ] } ) （2）为帐号启用admin数据库认证,这样他就可以操作admin数据库了。 db.auth("root", "123456") //为账号授权 db.system.users.find(); //查看当前已有的用户信息 （3）使用用刚才的超级帐号登录数据库(admin)mongo localhost:27017admin -u superman -p superman 现在，我们就可以为其他数据库添加用户了：

基于springsession构建一个session共享的模块。 这里，基于redis的集群（Redis-5.0.3版本），为了解决整个物联网平台的各个子系统之间共享session需求，且方便各个子系统使用，将这个模块设计为一个pom组件，直接在pom.xml文件里面配置为dependency。 今天的主题，就是redis 5.0.3环境的构建。 和我之前介绍过的redis 3.2.8 （https://www.cnblogs.com/shihuc/p/7882004.html）有些类似，只是redis 5里面，不再依赖ruby脚本进行集群配置，而是直接用c程序实现，直接基于redis-cli指令完成。这些就不做介绍，直接介绍如何配置。 首先，需要修改的配置项如下： bind 10.95.200.12 protected-mode no port 7380 daemonize yes pidfile /var/run/redis_7380.pid dbfilename dump-7380.rdb appendonly yes appendfilename "appendonly-7380.aof" cluster-enabled yes cluster-config-file nodes-7380.conf cluster-node-timeout 15000 notify

摘要：实际生产应用中都会采用消息队列的集群方案，如果选择RabbitMQ那么有必要了解下它的集群方案原理 一般来说，如果只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就可以了，但是出于MQ中间件本身的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑，在生产环境上一般都会考虑使用RabbitMQ的集群方案。 对于RabbitMQ这么成熟的消息队列产品来说，搭建它并不难并且也有不少童鞋写过如何搭建RabbitMQ消息队列集群的博文，但可能仍然有童鞋并不了解其背后的原理，这会导致其遇到性能问题时无法对集群进行进一步的调优。本篇主要介绍RabbitMQ集群方案的原理，如何搭建具备负载均衡能力的中小规模RabbitMQ集群，并最后给出生产环境构建一个能够具备高可用、高可靠和高吞吐量的中小规模RabbitMQ集群设计方案。 一、RabbitMQ集群方案的原理 RabbitMQ这款消息队列中间件产品本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的magic cookie来实现）。因此，RabbitMQ天然支持Clustering。这使得RabbitMQ本身不需要像ActiveMQ、Kafka那样通过ZooKeeper分别来实现HA方案和保存集群的元数据。集群是保证可靠性的一种方式

转( http://www.jianshu.com/p/f8e968e57863 ) 一. 应用场景 redis 作为数据结构存储引擎，有着很多优点 高性能 单机引擎可以达到5-10W qps 数据结构全面，支持快速开发业务 string，list，set，sorted set， hashes 问题： 存储容量受限单机最大容量即为单机内存最大容量 单机数据的持久化依赖aof和rdb机制，如果机器整个down掉，服务不可用 二. redis集群选型 正是由于单机redis引擎有着这样的问题，所以，基本每个互联网公司都有自己的redis集群化方案。 在redis客户端lib中实现数据的分片并主从部署redis实例 优点：简单，性能损耗小 缺点：扩容方案复杂 集群化候选方案 1、NetFlix对Dynamo的开源通用实现Dynomite Dynomite是NetFlix对亚马逊分布式存储引擎Dynamo的一个开源通用实现，使用C/C++语言编写、以代理的方式实现的Redis缓存集群方案。Dynomite不仅能够将基于内存的Redis和Memcached打造成分布式数据库，还支持持久化的MySQL、BerkeleyDB、LevelDB等数据库，并具有简单、高效、支持跨数据中心的数据复制等优点。Dynomite的最终目标是提供数据库存储引擎不能提供的简单、高效、跨数据中心的数据复制功能

某厂面试归来，发现自己落伍了！>>> 集群技术是构建高性能网站架构的重要手段，试想在网站承受高并发访问压力的同时，还需要从海量数据中查询出满足条件的数据，并快速响应，我们必然想到的是将数据进行切片，把数据根据某种规则放入多个不同的服务器节点，来降低单节点服务器的压力。 上一篇我们讲到了 Redis 的主从复制技术，当实现了多节点的 master-slave 后，我们也可以把它叫做集群，但我们今天要讲的集群主要是利用切片技术来组建的集群。 集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点，这里我们需要一个规则或者算法，通常的做法是获取 key 的哈希值，然后根据节点数来求模，但这种做法有其明显的弊端，当我们需要增加或减少一个节点时，会造成大量的 key 无法命中，这种比例是相当高的，所以就有人提出了一致性哈希的概念。 一致性哈希有四个重要特征： 均衡性：也有人把它定义为平衡性，是指哈希的结果能够尽可能分布到所有的节点中去，这样可以有效的利用每个节点上的资源。 单调性：对于单调性有很多翻译让我非常的不解，而我想要的是 当节点数量变化时哈希的结果应尽可能的 保护已分配的内容不会被重新分派到新的节点。 分散性和负载：这两个其实是差不多的意思，就是要求一致性哈希算法对 key 哈希应尽可能的避免重复。 但一致性哈希不是我们今天要介绍的重点，因为 Redis

某厂面试归来，发现自己落伍了！>>> Cluster 1、Redis 集群的分片特征在于将键空间分拆了16384个槽位，每一个节点负责其中一些槽位 2、Redis提供一定程度的可用性,可以在某个节点宕机或者不可达的情况下继续处理命令. 3、Redis 集群中不存在中心（central）节点或者代理（proxy）节点 集群的最大节点数量也是 16384 个（推荐的最大节点数量为 1000 个），同理每个主节点可以负责处理1到16384个槽位。 集群中的每个节点都与其他节点建立起了“集群连接（cluster bus）”， 该连接是一个 TCP 连接， 使用二进制协议进行通讯。 节点之间使用 Gossip 协议 来进行以下工作： a).传播（propagate）关于集群的信息，以此来发现新的节点。 b).向其他节点发送 PING 数据包，以此来检查目标节点是否正常运作。 c).在特定事件发生时，发送集群信息。 HASH_SLOT = CRC16(key) mod 16384 目前redis支持的cluster特性 1):节点自动发现 2):slave->master 选举,集群容错 3):Hot resharding:在线分片 4):进群管理:cluster xxx 5):基于配置(nodes-port.conf)的集群管理 6):ASK 转向/MOVED 转向机制. Master

大数据基础 定义 大数据是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。 大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。 大数据的意义不在于数量，在于挖掘数据的价值，探究海量数据间的相关性 基本特征 容量（Volume） ：数据的大小决定所考虑的数据的价值和潜在的信息 种类（Variety） ：数据类型的多样性 速度（Velocity） ：获得数据的速度 可变性（Variability） ：妨碍处理和有效管理数据的过程 真实性（Veracity） ：数据的质量 复杂性（Complexity） ：数据量巨大，来源多渠道 价值（Value） ：合理运用大数据，以低成本创造高价值 Hadoop Hadoop是一个由Apache基金会所开发的分布式系统基础架构，是一个开源框架，允许使用简单的编程模型在跨计算机集群的分布式环境中存储和处理大数据。 它的设计是从单个服务器扩展到千数个机器，每个提供本地计算和存储。 Hadoop框架实现分布式最核心的设计： HDFS 和 MapReduce 其中HDFS为海量的数据提供了存储，MapReduce为海量的数据提供了计算。以及在Hadoop2.x内，YARN框架实现了分布式资源调度。 Hadoop 1.0到Hadoop 2.0架构的变化图如下

Oracle 参考文档： https://docs.oracle.com/middleware/1221/wls/ELAST/toc.htm 什么是按需缩放？ 按需扩展允许您根据需要从活动动态集群中手动添加或删除正在运行的动态服务器实例。例如，如果动态集群成员中的平均用户请求积压趋势呈上升趋势，表明需要更高的处理能力，则可以将正在运行的动态服务器实例添加到动态集群中。当用户请求的待办事项大幅下降时，您可以关闭空闲的动态服务器实例。 基于日历的缩放 基于日历的缩放概述 WLDF提供了一些操作，以便在特定时间，一定时间后或在一定时间间隔内根据日历计划触发策略。基于日历的缩放将根据定义的时间表执行缩放操作。 仅Harvester使用Java表达式语言（EL）作为表达式语言的规则才支持基于日历的规则计划。以下策略类型支持基于日历的规则计划： 基于日历 基于智能规则 基于收集的指标 配置基于日历的缩放 要配置基于日历的缩放，请创建一个策略并定义该策略的计划，然后创建一个缩放操作并将其分配给该策略。可以基于以下条件将策略计划设置为执行： 每N秒 每N分钟 每N小时 一周中的特定日期（在特定时间） 每月的特定日期（在特定时间）。 什么是基于策略的扩展？ 基于策略的扩展基于策略和关联的操作，并利用WebLogic Diagnostics Framework（WLDF）的“策略和操作”组件

1.Zookeeper简介 Zookeeper是一个分布式服务框架，以前是Apache Hadoop 的一个子项目，现在是Apache的一个独立顶级项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。有关分布式的相关问题请查阅上篇博客： 分布式系统问题及解决方案 2.设计目标 ZooKeeper简单。ZooKeeper允许分布式进程通过共享的分层名称空间相互协调，该命名空间的组织方式类似于标准文件系统。名称空间由数据寄存器（在ZooKeeper看来，称为znode）组成，它们类似于文件和目录。与设计用于存储的典型文件系统不同，ZooKeeper数据保留在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟数。 ZooKeeper特性还包括高性能、高可用性、严格有序。ZooKeeper的性能方面意味着它可以在大型的分布式系统中使用。可靠性方面使它不会成为单点故障。严格有序意味着可以在客户端上实现复杂的同步原语。 ZooKeeper可复制。像它协调的分布式进程一样，ZooKeeper本身也可以在称为集合的一组主机上进行复制。组成ZooKeeper服务的服务器都必须彼此了解。它们维护内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper服务将可用