之前对HDFS更或者说是对Linux中文件的权限没有进行一个完整的学习，只是知道有所有者、所属组和其它权限，具体到某个人的权限有读(r)、写(w)和可执行(x)。
遇到没有权限的问题就chmod加个权限，加完之后如果还有问题就给父目录也加一样的权限，如果还不行就给777。
这其中应该给什么权限，给什么权限最合适都是一头雾水。
今天就说说文件和目录权限的那些事。。。。
Zookeeper session过期和connection超时
首先来看一张官方的状态转换图：
首先zk客户端会创建一个连接请求，此时会创建一个session，用于标识此次与服务器进行连接的一次生命周期。session创建之后，客户端的连接状态变为connecting，当与服务器建立成功之后变为connected状态。
Hello World
Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.
Quick Start
Create a new post
|
|
More info: Writing
Run server
|
|
More info: Server
Generate static files
|
|
More info: Generating
Deploy to remote sites
|
|
More info: Deployment
Druid调研
Druid初期是由metamarkets的技术人员开发，用于向买家、卖家、广告主进行广告展示的底层实时分析平台，为OLAP的事件查询而设计。目前已发展成一个开源的实时数据库。
时序数据库（TSDB）是一种特定类型的数据库，主要用来存储时序数据。
Java Synchronized实现原理
之前一篇文章介绍了Synchronized的用法，本篇从实现原理上更进一步了解下。
查看带有Synchronized语句块的class文件可以看到在同步代码块的起始位置插入了moniterenter指令，在同步代码块结束的位置插入了monitorexit指令。(JVM需要保证每一个monitorenter都有一个monitorexit与之相对应，但每个monitorexit不一定都有一个monitorenter)
但是查看同步方法的class文件时，同步方法并没有通过指令monitorenter和monitorexit来完成，而被翻译成普通的方法调用和返回指令，只是在其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。
moniterenter和moniterexit指令是通过monitor对象实现的。
Synchronized的实现不仅与monitor对象有关，还与另一个东西密切相关，那就是对象头。
git常用命令
*查看用户名和邮箱git config user.namegit config user.email
- 首先是配置帐号信息
git config --global user.name xxxgit config --global user.email xxx@bigdatadecode.club - 查看配置的信息
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，执行合并命令git merge dev(此时的当前分支是test，将dev合并到test分支)，然后push到远程git push origin test - 查看tag
git tag - 切换tag
git checkout tagName # 类似branch
YARN源码分析之ApplicationMaster架构
前面几篇关于ApplicationMaster的文章，把ApplicationMaster与RM之前的相关的流程已梳理完毕了(ApplicationMaster与NM之前的流程随后梳理)，其中有几个关键类ApplicationMaster(以MRAppMaster为例)、AMLivelinessMonitor、ApplicationMasterLauncher和ApplicationMasterService，本篇重点介绍下这4个类之间的关系。
YARN源码分析之RMContainerAllocator
上一篇提到RMContainerAllocator既是一个service也是一个eventHandle，并且简单介绍了下作为eventHandle的功能，现在来介绍下作为service服务的功能。
YARN源码分析之MR创建container请求
上一篇介绍了MRAppMaster启动时的一些流程。当MRAppMaster启动成功之后，job的状态已由INITED变为SETUP，并且在StartTransition.transition中构建了CommitterEventType.JOB_SETUP事件类型，由CommitterEventHandler.handle进行处理。
CommitterEventType.JOB_SETUP事件类型的处理器在MRAppMaster中作为一个服务添加到MRAppMaster服务中。
YARN源码分析之MRAppMaster启动
由YARN源码分析之ApplicationMaster启动流程中得知MR的AppMaster是由MRAppMaster启动的，在脚本中调用了AppMaster的main方法。
本文就顺着代码来对MRAppMaster进行解析下。