ZK

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本篇内容，依赖之前的3篇文章。 大规模机器集群-故障自动处理(一) 大规模机器集群-故障自动处理(二) 大规模机器集群-基础环境一致性 名词定义 ARS: AutoRepairSystem, 故障自动维修系统 服务树： 一个树形数据结构，记录着机器与业务线的对应关系 Deployer: 企业内部的CI/CD系统，记录和执行着所有的业务程序的变更和版本 Executor: 企业内部的机器作业系统，可登录机器执行任务 运维人员： 运维工程师 = SRE = OP，系统工程师 = sys 背景 在ARS上线运行一段时间之后，解决了SRE处理机器故障耗时费力的问题，同时也产生了新需求， web SRE ：既然机器故障自动修好了，能不能顺手帮我们把static/目录部署上？不大，几个G。 PaaS 平台SRE: 我们的机器修好后，需要部署一个PaaS agent，这服务不能简单地”随开机启动”，需要和当前线上各个机房的版本保持一致，你们的平台能搞吗？ 机器学习平台SRE: 我们的服务是有状态的，机器修好后，要部署服务，还要观察数据加载的进度，要追上master才能引流。 。。。 ARS 在规划设计之初，目标只是机器、系统环境的自动处理，不涉及服务，随着基础能力的提升，用户自然而然地提出了这些需求。所以，本篇以“需求驱动

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> https://v.youku.com/v_show/id_XNDQ4NDYyOTE5Mg==.html 上一期我们进行了 hint 的简单介绍和演示。我们的基本功能就介绍到这里，下面介绍一些进阶功能。 全局序列 我们先来介绍一下全局序列，我们DBLE目前支持四种全局序列。说是四种，如果按照他的内核区分是两种，只不过这两种方式放在不同的载体里面成为了四种。 我们先看这两种大概是一个什么概念。 snowflake 右上角这种是 snowflake 的算法是 twitter 最早提出的，通过 long 型数字分段实现的。DBLE 上面对它稍微有一些细节上的调整，但是不影响他的基本概念，他是通过时间戳做一个全局序列。首先他是一个 41 位的时间戳，大家可以先算一下 2 的 41 次方大概是多少？我们这边有个结论。这个数字大小应该足够 69 年的毫秒级别使用。对于我们一般的系统来说，能够存活 79 年应该不太可能。69 年其实已经够用了，计算机诞生也就刚过 70 年，然后我在每个毫秒中又有一个 12 位的序列号，12 位序列号就是 2 的 12 次方，就是 4096，也就是一毫米支持 4096 个并发。我们转换成 QPS 的话，就是乘以 1000，乘以 1000 以后应该是一个四百万的一个吞吐量

之前我们在搭建hadoop分布式环境的时候用到过Zookeeper注册hadoop服务。那么到底Zookeeper在分布式环境中发挥了什么作用呢，这次我们就来讨论这个问题。 在分布式系统中通常都会有多台机器构成一个集群来对外提供服务，对外来说有几台机器在提供服务它并不关心，那么对内而言组成集群的机器如何互相协调保持一致这是个问题。Zookeeper将提供这样的一个功能–分布式协调技术。 1. Zookerrper概述 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。 ZooKeeper性能上的特点决定了它能够用在大型的、分布式的系统当中。从可靠性方面来说，它并不会因为一个节点的错误而崩溃。除此之外，它严格的序列访问控制意味着复杂的控制原语可以应用在客户端上。ZooKeeper在一致性、可用性、容错性的保证，也是ZooKeeper的成功之处，它获得的一切成功都与它采用的协议——Zab协议是密不可分的。 ZooKeeper在实现这些服务时，首先它设计一种新的数据结构——Znode，然后在该数据结构的基础上定义了一些原语，也就是一些关于该数据结构的一些操作

Kafka初识 Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候，是否会遇到这样的一些问题： 我们想分析下用户行为（pageviews），以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计，分析出当前的流行趋势 有些数据，存储数据库浪费，直接存储硬盘效率又低 这些场景都有一个共同点： 数据是由上游模块产生，上游模块，使用上游模块的数据计算、统计、分析，这个时候就可以使用消息系统，尤其是分布式消息系统！ Kafka的定义 What is Kafka：它是一个分布式消息系统，由linkedin使用scala编写，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。 Kafka和其他主流分布式消息系统的对比 定义解释： Java 和 scala都是运行在JVM上的语言。 erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言，所以RabbitMQ天生就有很高的并发性能，但是 有RabbitMQ严格按照AMQP进行实现，受到了很多限制。kafka的设计目标是高吞吐量，所以kafka自己设计了一套高性能但是不通用的协议，他也是仿照AMQP（ Advanced Message Queuing Protocol 高级消息队列协议）设计的。 事物的概念：在数据库中

1.tar -xvf hbase-2.1.1-bin.tar.gz 解压Hbase 2.进入conf文件夹修改hbase-env.sh 2.1:export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.el7.x86_64,改为当前机器JDK路径 2.2:export HBASE_MANAGES_ZK=true,true使用Hbase自动ZK,false自己配置ZK 3.修改hbase-site.xml <configuration> <property> <name>hbase.rootdir</name> <value>file:///home/testuser/hbase</value> </property> <property> <name>hbase.zookeeper.property.dataDir</name> <value>/home/testuser/zookeeper</value> </property> <property> <name>hbase.master.info.port</name> 　　<value>60010</value> </property> <!--使用zk需要这个--> <property> <name>hbase.cluster.distributed<