ZooKeeper

引言 为什么要学习分布式锁？ 最简单的理由就是作为一个社招程序员，面试的时候一定被面啦，你看怎么多公众号都翻来覆去的发分布式锁的主题，可见它很重要啦，在高考里这就是送分题，不要怪可惜的。 那应届生也会问吗？这就不一定了，但是，如果你会，面试官肯定会多给你那点分（钱） 第三，分布式锁在稍微有丢丢规模大系统里是必备技能啦。认真看看吧。 分布式锁要解决的问题 分布式锁是一个在分布式环境中的重要原语，它表明不同进程间采用互斥的方式操作共享资源。常见的场景是作为一个sdk被引入到大型项目中，主要解决两类问题： 提升效率：加锁是为了避免不必要的重复处理。例如防止幂等任务被多个执行者抢占。此时对锁的正确性要求不高； 保证正确性：加锁是为了避免Race Condition导致逻辑错误。例如直接使用分布式锁实现防重，幂等机制。此时如果锁出现错误会引起严重后果，因此对锁的正确性要求高。 Java里的锁： 锁是开发过程中十分常见的工具，你一定不陌生，悲观锁，乐观锁，排它锁，公平锁，非公平锁等等，很多概念，如果你对java里的锁还不了解，可以参考这一篇：不可不说的Java“锁”事（https://tech.meituan.com/2018/11/15/java-lock.html），这一篇写的很全面了，但是对于初学者，知道这些锁的概念，由于缺乏实际工作经验，可能并不了解锁的实际使用场景

在配置yarn-HA高可用集群后，执行yarn-start.sh，发现nodemanager启动成功，而resourcemanager却没有启动，于是： 检查logs： tail -n 100 hadoop-root-resourcemanager-hadoop01.log 发现resourcemanager启动过程中出现这样的报错： org.apache.hadoop.service.ServiceStateException: org.apache.hadoop.yarn.exceptions.YarnException: Failed to initialize queues at org.apache.hadoop.service.ServiceStateException.convert(ServiceStateException.java:105) at org.apache.hadoop.service.AbstractService.init(AbstractService.java:173) at org.apache.hadoop.service.CompositeService.serviceInit(CompositeService.java:109) at org.apache.hadoop.yarn.server.resourcemanager

本文源码： GitHub·点这里 || GitEE·点这里 一、幂等性概念 1、幂等简介 编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。就是说，一次和多次请求某一个资源会产生同样的作用影响。 2、HTTP请求 遵循Http协议的请求，越来越强调Rest请求风格，可以更好的规范和理解接口的设计。 GET：用于获取资源，不应有副作用，所以是幂等的； POST：用于创建资源，重复提交POST请求可能产生两个不同的资源，有副作用不满足幂等性； PUT：用于更新操作，重复提交PUT请求只会对其URL中指定的资源有副作用，满足幂等性； DELETE：用于删除资源，有副作用，但它应该满足幂等性； HEAD：和GET本质是一样的，但HEAD不含有呈现数据，仅是HTTP头信息，没有副作用，满足幂等性； OPTIONS：用于获取当前URL所支持的请求方法，满足幂等性； 二、场景业务分析 1、订单支付 实际开发中，经常会面对订单支付问题，基本流程如下： 客户端发起订单支付请求 ； 支付前系统本地相关业务处理 ； 请求第三方支付服务执行扣款； 第三方支付返回处理结果； 本地服务基于支付结果响应客户端； 该业务流程中要处理相当复杂的问题，比如事务，分布式事务，接口延迟超时，客户端重复提交等等，这里只基于幂等接口角度来看该流程，其他问题后续再聊。 2、幂等接口

zookeeper 集群搭建 tar zxvf zookeeper-3.4.14.tar.gz cd zookeeper-3.4.14/conf cp zoo_sample.cfg zoo.cfg vi zoo.cfg 在文件末尾加上 server.1=192.168.1.1:3181:3182 server.2=192.168.1.2:3181:3182 server.3=192.168.1.3:3181:3182 说明 ： server. 数字=IP:port1:port2 例如server.1=192.168.1.1 :3181:3182 # server.A=B：C：D 其 中 # A 是一个数字，表示这个是第几号服务器，叫做myid或sid； # B 是这个服务器的 ip地址； # C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口； # D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader， 而这个端口就是用来执行选举时服务器相互通信的端口。 即在192.168.1.1服务上 cd /tem/zookeeper 目录下 vi myid 创建这个文件该文件填写 数字 1 其他服务依此类推 启动zookeeper cd zookeeper/bin sh zkServer.sh start

一、总体效果图 这里是将集群全部放在一起，可以根据自己的审美看怎么放 二、监控指标 其中有些指标与第一篇 Zookeeper通过四字命令基础监控（Zabbix） 的四字命令的指标是有重复的，二者选一个则可 三、实现 1、influxdb的安装 1）设置yum源 cat <<EOF | sudo tee /etc/ yum .repos.d/ influxdb.repo [influxdb] name = InfluxDB Repository - RHEL \$releasever baseurl = https: // repos.influxdata.com/rhel/\$releasever/\$basearch/stable enabled = 1 gpgcheck = 1 gpgkey = https: // repos.influxdata.com/influxdb.key EOF 2）安装influxdb yum install influxdb systemctl start influxdb 3）修改配置文件（元数据以及数据存放目录） [root@ip- 172 - 0 - 0 - 7 influxDB]# cat /etc/influxdb/influxdb.conf | grep " ^\s*[^# \t].*$ " [meta] dir = "

算法比较简单，每个id-generator负责生成的ID由3部分组成，41位时间戳可以表示到毫秒，10bit worker-id内部可自行划分，比如3位表示IDC，7位表示机器。最后12位是在一毫秒的递增id，也就是每毫秒算法可以产生2^12 = 4096个id，QPS 400多万； snowflake保证1）产生的id分布式系统内全局唯一，2）id趋势递增；不是严格递增，因为集群的机器时间不同步问题 该算法存在一个最严重的问题，是时间回退。比如一台机器A，在t产生一个id，但时钟被调回了t-15，则再次生成的id存在重复的可能。 思考了一个解决这个问题的方法， 在单一id-generator服务上，每ms生成id时，检测current_ms，或<= last_ms则等待last_ms-current_ms后，再开始正常服务。这样若id-generator重启后依然有问题，因为没有地方记录last_ms。并且因为400w的高qps，也无法将其持久化。 我们引入一个第3方，如zookeeper或redis，id-generator服务启动时atomic increase一个key，并将结果用作worker-id。。。 oops！貌似不行，只支持重启1024次 来源： oschina 链接： https://my.oschina.net/u/4367530/blog/4280303

一、下载匹配hadoop-3.x.y 版本的hive 3.1.2 下载地址 ： http://mirror.bit.edu.cn/apache/hive/ 二、上传至安装目录 /home/apache-hive-3.1.2-bin.tar.gz 解压：tar -zxvf apache-hive-3.1.2-bin.tar.gz 后重命名目录：/home/hive-3.1.2 三、编辑 /etc/profile 文件 ...... if [ -n "${BASH_VERSION-}" ] ; then if [ -f /etc/bashrc ] ; then # Bash login shells run only /etc/profile # Bash non-login shells run only /etc/bashrc # Check for double sourcing is done in /etc/bashrc. . /etc/bashrc fi fi export JAVA_HOME =/usr/java/jdk1.8.0_131 export JRE_HOME = ${JAVA_HOME}/jre export HADOOP_HOME =/home/hadoop-3.3.0 export HIVE_HOME=/home/hive-3.1.2 export

RocketMQ是阿里出品的一款开源的消息中间件，让其声名大噪的就是它的事务消息的功能。在企业中，消息中间件选择使用RocketMQ的还是挺多的，这一系列的文章都是针对RocketMQ的，咱们先从RocketMQ的一些基本概念和环境的搭建开始聊起。 RocketMQ由4部分组成，分别是：名称服务（Name Server）、消息队列（Brokers）、生产者（producer）和消费者（consumer）。这4部分都可以进行水平扩展，从而避免单点故障，如下图， 这是RocketMQ官网上的一张图，非常清晰的列出了4个部分，并且都是集群模式。下面我们就分别说一说这4部分。 名称服务（NameServer） Name Server扮演的角色是一个注册中心，和Zookeeper的作用差不多。它的主要功能有两个，如下： broker的管理：broker集群将自己的信息注册到NameServer，NameServer提供心跳机制检测每一个broker是否正常。 路由管理：每一个NameServer都有整个broker集群和队列的信息，以便客户端（生产者和消费者）查询。 NameServer协调着分布式系统中的每一个组件，并且管理着每一个Topic的路由信息。 Broker Broker主要是存储消息，并且提供Topic的机制。它提供推和拉两种模式，还有一些容灾的措施，比如可以配置消息副本

分布式概念简单了解：数据一致性、CAP、BASE、分布式事务、分布式锁 版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 今天对分布式相关的一些概念与理论进行学习。 1.集群与分布式 集群 ：相同的应用部署在多台服务器。 分布式 ：不同的应用部署在多台服务器。 1.数据一致性 在分布式环境中，为了提高系统整体性能，数据以多副本冗余机制存储，副本之间通过数据复制进行同步。 数据副本与数据复制必然引入新的问题：如何处理副本数据的一致性？ 总的来说，无法找到一种能够满足所有分布式环境的一致性解决方案，很多时候要在系统性能与数据一致性之间权衡。 由此，分布式一致性常见以下三种一致性： 1.1.强一致性 强一致性 ：数据写以后，任意时刻，所有数据副本中的数据都是一致的。 强一致性，也可以称为：原子一致性、线性一致性。 强一致性，是非分布式环境中主要被采用的一致性原则。 在非分布式环境中，数据可以集中存储，例如整个系统就一个数据库，这种情况下容易保证数据的强一致性。 在分布式环境中，数据存在多个副本，分布在不同的服务器上，数据副本之间的同步会经过网络通讯，这种情况下，很难保证强一致性。 1.2.顺序一致性 顺序一致性 ：任何一次读都能读取到数据的最近一次写的数据，系统的所有进程的顺序一致，而且是合理的。 顺序一致性，其实本人接触也不多

为什么会有ZooKeeper 我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。有可能是收到消息以后发生了网络故障，也有可能是没有收到消息，又或者可能接收方的进程死了。发送方唯一的确认方法就是再次连接发送消息，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。所以大部分应用需要开发私有的协调程序，协调程序的反复编写浪费时间，这个时候就需要一个通用的、伸缩性好的协调器。就是因为这样的场景，ZooKeeper应运而生，ZooKeeper的设计目的，就是为了减轻分布式应用程序所承担的协调任务。 ZooKeeper常用的应用场景 01 / 分布式协调 分布式协调简单说就是有人对ZooKeeper中的数据做了监听，如果修改了ZooKeeper中被监听的数据，ZooKeeper反过来会告诉给发起监听的人数据的变更。比如在Kafka的设计中，Kafka的一个节点在ZooKeeper中创建了一个数据，Kafka的策略是谁创建了这个数据谁就是Kafka集群的主节点，其余的节点都会去监听这个数据。如果主节点宕机了，这ZooKeeper对应的数据就会发生变更，既而监听这个数据的其余节点就会感知到主节点宕机了