heartbeat

参考链接： https://www.jianshu.com/p/f01f5f0309a9 一、旧版本Scala消费者客户端的缺陷 在kafka0.9及以前版本的consumer会在zookeeper上/consumers/groupId/ids、/consumers/groupId/topics、/consumers/groupId/owners下注册watch。一旦有变化，所有的consumer都得到通知，都进行rebanlace操作。 这种方式有几种缺陷： 1、zk压力很大 2、羊群效应，就是大量watch需要通知，可能会导致其他任务阻塞 3、脑裂效应，所有consumer都接收到通知，进行rebanlance，相互之间没法控制。 所以在kafka0.9版本引入了协调器Coordinator 二、协调器分类及功能 每个broker启动的时候都会创建一个GroupCoordinator，每个客户端都有一个ConsumerCoordinator协调器。 ConsumerCoordinator每间隔3S中就会和GroupCoordinator保持心跳，如果超时没有发送，并且再过Zookeeper.time.out = 10S中则会触发rebanlance 1、GroupCoordinator 1、接受ConsumerCoordinator的JoinGroupRequest请求 2

一、新旧API的区别 老版本（0.8及以前）Consumer会在zookeeper上记录和管理group信息，一旦consumer挂了，其他所有consumer都会接收到信息，会重新进行rebenlance 新版本（0.9及以上）kafka，每个broker都会有一个groupCoordinator，每个consumer都会有一个consumerCoordinator，并且引入了topic：__consumer_offsets来存储group信息，减轻zookeeper压力。 注意：__consumer_offsets topic不是broker集群启动就创建的，而是第一次消费时才会创建。service.properties中关于此topic的配置：partitions=50，offsets.topic.replication.factor=1 此时zookeeper上/consumers下没有group相关的信息了 二、分区分配算法 多个consumer同时消费一个topic，partition怎么分配？ ==> 不管新版本还是旧版本，都提供了两种分区分配算法，都能确保一个partition只能给一个consumer线程消费，多余的consumer线程无法拿到数据。 1、kafka.consumer.RangeAssignor.java （这个是默认的，代码就不贴出来了，太多

HA集群的开源实现方案 Message层： 1、hearbeat：主要有3个版本，v1和v2版与CRM集成在一起，v3版中CRM从heartbeat中独立出去，叫做pacemaker 2、corosync： 3、cman：RedHat研发，属于早期在corosync诞生之前RedHat在自己的企业版Linux系统上提供的解决方案 4、keepalived：上述三者实现方法是基于OpenAIS框架标准，而keepalived自己是基于VRRP协议实现心跳功能，专用于LVS集群 CRM层： 1、haresources：heartbeat v1自带，配置接口：配置文件，文件名为haresources 2、crm：heartbeat v2自带，在各节点运行一个crmd守护进程，监听在TCP 5560端口；配置接口，CLI接口：crmsh，或者GUI接口：hb_gui 3、rgmanager：RedHat研发，早期和cman配合使用，配置接口，配置文件：cluster.conf（xml文件），CLI接口：clustat、cman_tool等；GUI接口：conga（luci+ricci）、system-config-cluster 4、pacemaker：在heartbeat v3版后作为独立项目，可以单独运行或者以插件运行；配置接口，CLI接口：crmsh（Suse研发）、pcs

在分布式集群中，如何保证相同请求落到相同的机器上，并且后面的集群机器可以尽可能的均分请求，并且当扩容或down机的情况下能对原有集群影响最小。 round robin算法：是把数据mod后直接映射到真实节点上面，这造成节点个数和数据的紧密关联、后期缺乏灵活扩展。 一致性哈希算法：多增加一层虚拟映射层，数据与虚拟节点映射、虚拟节点与真实节点再映射。 一般都会采用一致性哈希或者hash slot的方法。一致性哈希的ketama算法实现在扩容或down的情况下，需要重新计算节点，这对之前的分配可能会有一些影响。所以可以引入hash slot的方式，即某些hash slot区间对应一台机器，对于扩容或down机情况下，就改变某个hash slot区间就可以了，改动比较小，对之前分配的影响也较小。 虚拟桶是取模和一致性哈希二者的折中办法。 采用固定节点数量，来避免取模的不灵活性。 采用可配置映射节点，来避免一致性哈希的部分影响。 先来看一下hash slot的基本模型： 记录和物理机之间引入了虚拟桶层，记录通过hash函数映射到虚拟桶，记录和虚拟桶是多对一的关系；第二层是虚拟桶和物理机之间的映射，同样也是多对一的关系，即一个物理机对应多个虚拟桶，这个层关系是通过内存表实现的。对照抽象模型章节，key-partition是通过hash函数实现的，partition

7月3日任务 18.1 集群介绍 18.2 keepalived介绍 18.3/18.4/18.5 用keepalived配置高可用集群 扩展 heartbeat和keepalived比较http://blog.csdn.net/yunhua_lee/article/details/9788433 DRBD工作原理和配置 http://502245466.blog.51cto.com/7559397/1298945 mysql+keepalived http://lizhenliang.blog.51cto.com/7876557/1362313 Linux集群概述 根据功能划分为两大类：高可用和负载均衡 高可用集群通常为两台服务器，一台工作，另外一台作为冗余，当提供服务的机器宕机，冗余将接替继续提供服务 - 高可用衡量标准，4个九，就是99.99%，表示一个比例，在一年时间内99.99%的时间都是在线的，不允许宕机，不允许服务不可用。另外还有的是5个9，6个9 实现高可用的开源软件有：heartbeat、keepalived heartbeat软件，在centos6中有很多bug，而且很久没有更新版本了，不建议继续使用 keepalived软件，不仅有高可用的功能，还有负载均衡的功效，配置也非常简单 负载均衡集群，需要有一台服务器作为分发器

上次进过GTID复制的学习记录，已经搭建好了主从复制的服务器，现在利用现有的主从复制环境，加上正在研究的Mycat，实现了主流分布式数据库的测试 Mycat就不用多介绍了，可以实现很多分布式数据库的功能，极大的减轻数据库服务器的压力，包括读写分离以及分库分表，本测试对这两种功能都进行了测试，进行相应记录 本文以Mycat官方给出的例子来进行解释总结 首先来看分库分表，分库分表一般来说都是一起说的，但是实际上分库跟分表是有区别的，简单来说有垂直和水平两种方式，垂直就是将表按字段进行拆分，水平就是将表按照数据分布来做行拆分。具体的肯定还是有区别，本文不再进行阐述，主要介绍按照字段的分布进行数据行的拆分 本身理解来说Mycat实现的应该是分库，也就是将一个表的行分开存储到不同的数据库中，这里不同的数据库可以有一下两种 1）不同的数据库服务器上的 两个数据库（此时db的名字可以相同，也可以不同） 2）相同的数据库服务器上的两个数据库（此时db的名字肯定是不同的） 当然对于实际使用分库来说肯定是使用不同的数据库服务器的，而且大多数都是在不同的服务器上使用相同的名字，这样能够比较正式的做法 分表的关键部分在mycat的配置文件schema.xml中，该文件中定义了数据库服务器，表的拆分规则等等重要信息 <table name="employee" primaryKey="ID"

目录 概述 环境准备 普罗米修斯简介 mysql安装 mysqld_exporter安装 启动参数列表 概述 prometheus( 普罗米修斯 ) 是一个开源系统监控和报警工具包，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。 环境准备 mysql 5.5以上 mysql_exporter 0.11.0 普罗米修斯简介 功能 根据指标名称和key/value标识组成一个多维度的时间序列数据模型 具有一种利用多维度数据模型灵活查询的一种语言PromQL 不依赖分布存储,每个服务节点都是独立的 时序数据收集通过http的pull模型 通过中介网关支持推送时间序列 通过服务发现或静态配置发现目标 图形化支持多种模式 组件 普罗修斯是开源的,它的生态中有很多可选组件,选用组件时需要注意它们的许可说明,大体组件有以下几类: 普罗米修斯服务 (整理存储数据) 客户端库(查询数据进行可视化等操作) 推送数据的jobs(收集数据) 推送数据的exporer(收集数据) 报警管理器(根据指标进行报警) 架构 此图来自官网,博主对架构图标注了注释 mysql搭建 这里可以参考博主以前的博文 centos 7下源码安装mysql5.7--一步一步亲测操作完成 mysql_exporter安装 查看系统版本

前面两篇博客介绍了HDFS客户端读写数据流程，本篇博主将带给小伙伴们namenode和datanode的工作机制的分享。 一、目标 理解namenode的工作机制尤其是元数据管理机制，以增强对HDFS工作原理的理解，及培养hadoop集群运营中“性能调优”、“namenode”故障问题的分析解决能力。 问题场景： 1、集群启动后，可以查看文件，但是上传文件时报错，打开web页面可以看到namenode正处于safemode状态，怎么处理？ 2、Namenode服务器的磁盘故障导致namenode宕机，如何挽救集群及数据？ 3、Namenode是否可以有多个？namenode内存要配置多大？namenode跟集群数据存储能力有关系吗？ 4、文件的blocksize究竟调大好还是调小好？ .... 诸如此类问题的回答，都需要基于对namenode自身的工作原理的深刻理解 二、namenode的职责 负责HDFS客户端请求的响应，元数据的管理（查询，修改） 三、namenode元数据管理 namenode对数据的管理采用了三种存储形式：内存元数据(NameSystem)、磁盘元数据镜像文件、数据操作日志文件（可通过日志运算出元数据） 1.元数据存储机制： A、内存中有一份完整的元数据(内存meta data) B、磁盘有一个“准完整”的元数据镜像（fsimage）文件

在 上篇文章 中,我们简单介绍了EurekaServer自动装配及启动流程解析，本篇文章则继续研究EurekaClient的相关代码 老规矩，先看 spring.factories 文件，其中引入了一个配置类 EurekaDiscoveryClientConfigServiceBootstrapConfiguration @ConditionalOnClass(ConfigServicePropertySourceLocator.class) @ConditionalOnProperty(value = "spring.cloud.config.discovery.enabled", matchIfMissing = false) @Configuration @Import({ EurekaDiscoveryClientConfiguration.class, EurekaClientAutoConfiguration.class }) public class EurekaDiscoveryClientConfigServiceBootstrapConfiguration { } 上方两个注解则是这个配置类是否能够开启的条件，这里就不再展开，直接看它引入的配置类吧 EurekaDiscoveryClientConfiguration 细心的读者可能会发现这里又注册了一个

Heartbeat ： UDP 694 heartbeat v2 ha web node1 , node2 节点名称， /etc/hosts 节点名称必须跟uname -n 命令的执行结果一致 ssh互信通信 时间同步 Heartbeat Heartbeat subsystem for High-Availability Linux heartbeat-devel Heartbeat development package heartbeat-gui Provides a gui interface to manage heartbeat clusters heartbeat-ldirectord 图形化管理界面 为ipvs高可用提供规则自动生成及后端realserver健康状态检查的组件 ； heartbeat-pils Provides a general plugin and interface loading library heartbeat-stonith Provides an interface to shoot The Other Node In the Head 来源： https://blog.51cto.com/14087650/2428139