摘要：
JobClient JobClient是提交job的客户端，当创建一个实例时，构造函数里面要做的事情是： public JobClient(JobConf conf) throws IOException { setConf(conf); init(conf); } public void init(JobConf conf) throws IOException { String tracker = conf.get("mapred.job.tracker", "local"); tasklogtimeout = conf.getInt( TASKLO 阅读全文
摘要：
看了许久的代码，把map的流程熟悉了下，不追求最准确的理解，记录下来以免忘记。 对于JobTracker和TaskTracker等大层面有控制和通讯的代码暂时不表 map过程俗气的先上一个图：map这一端基本是这样的流程：input split分解成map个数量的部分输入==》RecordReader分解成Mapper需要的(key,value)记录==》执行map方法==》执行的结果起初在内存当中==》当内存记录过多的时候spill到硬盘上面，如果有分区(Partitioner的话)，spill的文件会记录分区的信息，单个spill文件首先按分区排序，然后按key排序==》如果有多个spi. 阅读全文
摘要：
在HDFS中可能同时有多个客户端在同一时刻写文件，如果不进行控制的话，有可能多个客户端会并发的写一个文件，所以需要进行控制，一般的想法是用一个互斥锁，在某一时刻只有一个客户端进行写操作，但是在分布式系统中有如下问题： 1.每次写文件前，客户端需要向master获取锁情况，他们之间的网络通讯太频繁。 2.当某个客户端获取锁之后和master失去联系，这个锁一直被该客户端占据，master和其他客户端不能获得锁，后续操作中断。在HDFS中使用了租约解决上面的问题： 1.当写一个文件时，客户端向NameNode请求一个租约，租约有个时间期限，在时间期限内客户端可以写租约中管理的文件，一个文件只... 阅读全文
摘要：
DFSClient代码很复杂，但是不外乎几种情况：和NameNode的通讯，和DataNode的通讯，写入数据到DataNode和从DataNode读到数据DFSClient和NameNode的通讯就是通过上文分析的RPC.getProxy()获得NameNode的代理进而和NameNode进行通讯DFSCLient和DataNode的通讯就不是这样了，狗血的不明白为什么要这样做，DFSCLient和DataNode之间使用DFSOutputStream和DFSInputStream进行数据写入和读取DFSCLient.DFSOutputStream：DFSCLient和DataNode的通讯 阅读全文
摘要：
HDFS中简单的分为：Client，DataNode，NameNode三大类，其中他们之间的通讯一共有这么几种：Client <=====>NameNode;Client <=====>DataNode;NameNode <======>DataNode;DataNode<=====>DataNode几种，其中涉及到很多网络通讯的封装，也涉及到Hadoop的IPC机制。 他们的通讯如下： 主要类的类图：HDFS的通讯方面的代码写的不是很优雅，相互依赖太多，只有一点点进行分析总体DFSClient与NameNode的通讯使用了Hadoop自身的ip 阅读全文
摘要：
这里将给出HDFS一些主要类的关系图：NameNode后面的一些类的关系：NameNode背后的类图：DataNode存储相关的类图：Block：HDFS内部以Block的形式保存数据，Block的大小比较大，默认64M。BlockInfo：继承了Block，额外包含INodeFile信息，这个在namenode是持久化在磁盘里面的，同时包含了Block所属的DatanodeDescriptor信息以及Block的前后Block信息BlockMap：定义了一个Map结构，是Block到BlockInfo的映射，Map的接口是自定义的轻量级接口，没有使用标准的java.util.Map接口INo 阅读全文
摘要：
HDFS是以最少的钱买最烂的机器实现最安全的难度很高的分布式文件系统，可以看出HDFS认为机器故障是种常态，所以设计时充分考虑到单个机器故障，单个磁盘故障，单个文件丢失的情况。 HDFS主要分为client，namenode，datanode三大主题，这里的client更像传统的C/S结构中的C，因为必要时client需要维护一系列的状态，验证数据完整性等；namenode在HDFS中是个单点，是整个HDFS的心脏，他管理着HDFS的文件命名空间，管理整棵文件树的添加，修改，删除，这些都是持久化在硬盘之上的，文件里面的内容包含block的元数据；block和datanode的映射则是放在... 阅读全文
摘要：
redis初略的看了下源代码，其中的数据结构对我的感触比较深，和自己项目用到的cache比较了一下，写下此文。 redis数据结构很丰富：String,List,Hash,Set,SortSet,而一般的cache只是个kv，也就是个hash。 redis支持这些数据结构很简单，把一般cache系统的key也进行了管理，把key也放在一个数据结构里面，这样可以对key进行一些计算，比如hash很难做到的范围查找等。redis String可以认为是一般cache的hash。其他的数据结构一般都是key-subkey-value的形式，这样做的话通过key可以得到subkey-value,而s. 阅读全文
摘要：
最近读了Amazon Dynamo的论文，记录几个关键点，说明大致的原理，不追求语言的准备下和严谨性。CAP，在Dynamo论文发布后开始流行，CAP在这之前已经被提出来，大致的意思是这样的：C:Consistent，一致性：任何一个读操作总是能够读取之前完成的写操作结果A:Available，可用性：每一个操作总是能够在确定的时间内返回P:Partition-tolerance，分区容忍性，在网络出现分区时，任然满足一致性和可用性CAP理论认为三者无法同时满足，当网络分区时，一致性就得不到满足了。Dynamo也是以CAP为指导思想进行设计的，在论文中提到引入了NWR可以配置策略，N代表系统存 阅读全文
摘要：
最近一次，有个需求，需要给3kw的用户发系统消息，按照以往的设计是这样的： 后台输入系统消息--->从用户系统得到用户的id--->根据用户id给每个用户生成一个存储消息的key，进行消息存储，更新用户的未读消息数--->用户登录系统，看到未读消息数，点击进入阅读页面--->读取系统消息，更新未读消息数为0 这个方案在用户数非常少的情况下面是完全ok的，但是在用户数很大的时候，出现了以下问题： 1.系统消息对于每个用户是一样的，即使有可能有一些差别，但是通过用户系统的数据可以组装出不一致的消息，这样的话，如果存储一份数据用的存储大大小于存储3kw数据用户的存储 2.给每 阅读全文