big data decode club

今天在批量生成命令的时候，需要使用一个类似嵌套变量的东西，(注意这个嵌套变量，一开始并不知道shell中有这个东东) 具体场景是这样的： 有一堆命名比较规则的变量，例如conf_1、conf_2、conf_3…这些变量需要在一个循环中根据循环的次数输出，伪代码如下： 12345678conf_1='conf1'conf_2='conf2'conf_3='conf3'for i in {1..3}do # 想要的效果是当i=1时，echo $conf_1 echo ${conf_${i}}done 上面的代码会报语法错误。 于是就尴尬了，这要怎么搞，硬编码？这不符合前人的思维呀，于是google之。 既然要google就要给人家一个关键词，这看效果是变量里嵌套了变量，那关键字就是嵌套变量吧。果然顺利搜出结果。demo如下： 123456title3='查找固件中的⼝令⽂件'i=3title=title${i}eval temp ...

这是区块链系列的开篇文章，随后会陆续写一些blog。看了两本区块链的书，有了一些初步的了解，最近打算实践下，就想着先弄个读代码的环境，本以为挺简单但也折腾了好久，所以就打算备注下。 两本区块链相关的书分别是区块链开发指南和精通比特币，随后会写些读后感 虽然网上也有很多相关的文章但大都比较笼统或者记录的比较含糊，导致像我这样的新手得花大量的时间去摸索去踩坑。下面就开始流水账了。。。 build bitcoin 从github上clone源码，git clone https://github.com/bitcoin/bitcoin.git clone到本地的代码是最新的代码也就是master分支上的，前人一般都推荐阅读0.12版本的代码，所以在build代码之前要切换下tag，命令git checkout v0.12.0 选择tag为v0.12.0进行build之后，在qt文件中并不出会出现bitcoin-qt这个文件，随后切换到branch为remotes/origin/0.12的版本进行build成功出现，所以这里应该切换的代码版本是git checkout remotes ...

之前对HDFS更或者说是对Linux中文件的权限没有进行一个完整的学习，只是知道有所有者、所属组和其它权限，具体到某个人的权限有读(r)、写(w)和可执行(x)。遇到没有权限的问题就chmod加个权限，加完之后如果还有问题就给父目录也加一样的权限，如果还不行就给777。这其中应该给什么权限，给什么权限最合适都是一头雾水。今天就说说文件和目录权限的那些事。。。。 HDFS基于Linux的POSIX model HDFS的权限虽然是基于Linux的POSIX model，但是HDFS中其实并没有真正的用户和组的概念，只是从主机上拿到用户的信息然后对其存储的文件权限进行检查。 HDFS中每个文件和目录都有一个owner和group，并对owner、owner同一个组的user和其它user的权限进行了分离，权限分为rwx。对于文件来说，有r权限则可对此文件可读，有w权限则可对文件进行写和追加，x权限对文件来说没有实际的意义。对于目录来说，拥有r权限可以查看目录中内容，比如此目录下的文件或者子目录，拥有w权限可以在此目录中新建或者删除文件和子目录，但不可以改变此目录的名字，因为改变此目录 ...

首先来看一张官方的状态转换图：首先zk客户端会创建一个连接请求，此时会创建一个session，用于标识此次与服务器进行连接的一次生命周期。session创建之后，客户端的连接状态变为connecting，当与服务器建立成功之后变为connected状态。 由上面的状态图可以看出客户端会接受到服务端返回的两个错误码，分别为CONNECTION_LOSS和SESSION_EXPIRED，收到这两个错误码，客户端是怎么处理的呢？先看下CONNECTION_LOSS。 CONNECTION_LOSS当客户端与服务端的连接发生异常时，会返回CONNECTION_LOSS。当客户端收到此返回码时，并不能盲目的认为是网络连接失败还是服务端挂了。因为返回CONNECTION_LOSS的情况可能有如下几种： 客户端创建了一个请求，并且服务端已正常接收到了该请求，只是在返回时发生了异常(可能是网络异常) 客户端创建了一个请求，服务端根本没有收到(可能是网络也可能是服务端挂了) 因此在客户端收到这样的返回码时，不能新建一个session。假如客户端与服务端A正常连接时，发生了异常，此时应该尝试与服务 ...

Druid初期是由metamarkets的技术人员开发，用于向买家、卖家、广告主进行广告展示的底层实时分析平台，为OLAP的事件查询而设计。目前已发展成一个开源的实时数据库。 时序数据库（TSDB）是一种特定类型的数据库，主要用来存储时序数据。 架构Druid的架构比较灵活，是一个集群模式，由多个不同类型的节点组成，并且各个节点也能组成自己的小集群以增加可用性和扩展性。 Druid中每类节点都只完成一小部分事情，节点分类如下： Historical节点Historical节点是Druid集群的骨干，用于负责存储和查询历史数据。它从Deep Storage下载segments到本地，响应从broker节点上分发到查询请求，并将结果数据返回给broker节点。Historical节点采用shared nothing的架构，所以每个节点能够独自加载segments、删除segments、以及为segments提供查询服务。 Historical节点与Zookeeper进行通信(Historical节点之间并不通信)，将该节点上已加载的segments和正在提供服务的segment ...

之前一篇文章介绍了Synchronized的用法，本篇从实现原理上更进一步了解下。 查看带有Synchronized语句块的class文件可以看到在同步代码块的起始位置插入了moniterenter指令，在同步代码块结束的位置插入了monitorexit指令。(JVM需要保证每一个monitorenter都有一个monitorexit与之相对应，但每个monitorexit不一定都有一个monitorenter)但是查看同步方法的class文件时，同步方法并没有通过指令monitorenter和monitorexit来完成，而被翻译成普通的方法调用和返回指令，只是在其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过 ...

*查看用户名和邮箱git config user.namegit config user.email 首先是配置帐号信息git config --global user.name xxxgit config --global user.email xxx@bigdatadecode.top 查看配置的信息 git config --list 禁止自动换行转换 git config --global core.autocrlf input 查看远程分支 git branch -a 查看本地分支 git branch 创建本地分支并切换 git checkout -b dev，也可使用git branch dev和git checkout dev这两条命令 将本地分支推送到远程 git push origin dev:dev ，第一个dev是本地的分支名字，第二个dev是远程分支的名字，远程分支名字可以不存在，会自动创建 拉取远程分支 git pull origin dev 合并远程分支， 先创建一个与远程分支同名的本地分支git checkout -b test，执 ...

前面几篇关于ApplicationMaster的文章，把ApplicationMaster与RM之前的相关的流程已梳理完毕了(ApplicationMaster与NM之前的流程随后梳理)，其中有几个关键类ApplicationMaster(以MRAppMaster为例)、AMLivelinessMonitor、ApplicationMasterLauncher和ApplicationMasterService，本篇重点介绍下这4个类之间的关系。 先看下这4个类之间的整体架构图： 简单描述下整个流程： 首先client向RM提交一个application请求，RM创建一个application，然后再创建一个appattempt，后期的调度和任务的拆解都是对这个appattempt进行的。随着appattempt的状态变化，会触发AMLauncherEventType.LAUNCH事件类型的事件，由ApplicationMasterLauncher.handle进行处理，通过RPC调用containerMgrProxy.startContainers来启动一个Application ...

上一篇提到RMContainerAllocator既是一个service也是一个eventHandle，并且简单介绍了下作为eventHandle的功能，现在来介绍下作为service服务的功能。 RMContainerAllocator继承RMContainerRequestor类，RMContainerRequestor又继承自RMCommunicator，RMCommunicator类在代码中的注释是Registers/unregisters to RM and sends heartbeats to RM. RMContainerAllocator是一个服务，在MRAppMaster.serviceInit中添加到MRAppMaster中，并且在serviceStart中启动该服务，启动时首先调用init，然后调用start。RMContainerAllocator.serviceInit主要是一些属性值的设置，重点看下serviceStart方法: 123456789101112131415161718192021222324252627protected void se ...

上一篇介绍了MRAppMaster启动时的一些流程。当MRAppMaster启动成功之后，job的状态已由INITED变为SETUP，并且在StartTransition.transition中构建了CommitterEventType.JOB_SETUP事件类型，由CommitterEventHandler.handle进行处理。 CommitterEventType.JOB_SETUP事件类型的处理器在MRAppMaster中作为一个服务添加到MRAppMaster服务中。 来看下具体的流程 123456789101112// StartTransition.transition 构建CommitterEventType.JOB_SETUP事件类型对象job.eventHandler.handle(new CommitterJobSetupEvent(job.jobId, job.jobContext));// CommitterEventHandler.handlepublic void handle(CommitterEvent event) { try &# ...