Architecture

仅供复制 修改配置文件 <!–修改conf/core-site.xml–> <configuration> <property> <name>fs.default.name</name> <value>hdfs://localhost/</value> <!–默认的文件系统是本机hdfs系统–> </property> </configuration> <!–修改conf/hdfs-site.xml–> <configuration> <property> <name>dfs.replication</name> <value>1</value> <!–pseudo-distributed模式下没法做replication–> </property> </configuration> <!–修改conf/mapred-site.xml–> <configuration> <property> <name>mapred.job.tracker</name> <value>localhost:8021</value> </property> </configuration> 使本机可以免密码登录本机 $ssh-add $ssh localhost #测试一下要不要输入密码 格式化HDFS文件系统 $hadoop namenode -format #经测试，文件系统创建在/tmp/hadoop-kent/dfs/name中 启动Hadoop后台服务 $start-dfs.sh $start-mapred.sh 通过浏览器察看状态 http://localhost:50070/ http://localhost:50030/ 操纵一下hdfs中的文件 $hadoop fs -copyFromLocal 1k.log hdfs://localhost/firsttry/1k.log $hadoop fs -ls / #列出hdfs的根目录 停止hadoop服务 $stop-dfs.sh $stop-mapred.sh

1. Map的输入数据一般放在HDFS中 2. Map的输出数据放在本地硬盘上，因为它们只是中间结果，不需要冗余，所以不需要用HDFS 3. Reduce的输出数据放在HDFS中，以实现冗余

基本抄自象书，我只是加了几条线 读 注： NameNode只提供元数据，数据交换在客户端和DataNode之间直接发生，以免NameNode成为瓶颈 写 注：默认情况下，写入的数据会有三份复本，分布在两个机架上(鸡蛋不放在同一个篮子里)

无任何干货，仅供复制 程序说明：   1. 分析一个应该的访问日志文件，找出每个用户ID的访问次数。日志格式基本上是："2012-10-26 14:41:30,748  userNameId-777 from IP-10.232.25.144 invoked URL-http://xxx/hello.jsonp"   2. Standalone模式，但直接用maven项目所依赖的hadoop库，你不必再另装hadoop <!– pom.xml –> <dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-core</artifactId> <version>1.0.4</version> </dependency> //Mapper public class Coupon11LogMapper extends Mapper<LongWritable, Text, Text, LongWritable> { @Override protected void map(LongWritable key, Text value, Context context) throws java.io.IOException, InterruptedException { String line = value.toString(); String accessRegex = ".*userNameId\\-(\\d+).*"; Pattern pattern …

hadoop map-reduce 入门示例代码 Read More »

Brewer最早的ppt讲得太泛了，看了还是不明白。后来看了很多相关的文章，才明白了这个东西。 为了不走弯路，首先你要明白Partition是 指什么。它不是“分区容忍性”，而是对“系统内部结点间通信失败的容忍性”。 其次，CAP所针对的分布式系统是跟数据相关的，要么这个系统直接存储了数据，要么它会把数据存储到另外的系统中，这样才有必要谈C(数据一致性)。无状态的分布式应用是没有资格谈CAP的。 再次，3″取”2 这种说法是很含混的，不要过分纠结。以mysql服务为例， 1. 如果说舍弃P,那仅仅意味着你的mysql是单机版的；单库可以利用事务直接保证C，而且你可以通过scale up来获得A. 这种情况下，你的应用并不是一个分布式应用。 2. 如果要保留P，也仅仅是指mysql使用了读写分库或者其他分拆方案。什么叫耐受，什么叫不耐受，并没有明确的定义。它只是给你提供一个将讨论持续下去的基础，也就是说，在分拆之后，你才可以开始谈“在A和C之间取舍”。 以读写分库为例，当主备库之间网络断裂时， a.如果你仍然允许主库写、备库读，则主备库都是高可用的，但主备库数据却由于无法同步而出现了不一致，也就是说，有A无C. b.如果你不允许主库写，则在用户眼里写操作就不是可用的了，但是主备库的数据却保证了一致性，也就是说，有C无A. 总结一下：在分布式应用中，P是天然存在的，而所谓的Trade-Off是指A和C之间的取舍。 最后要说明一下，“有A无C”、”有C无A”以及“无法同步”都是比较极端的情况，在实践中，尤其是高并发的应用中，你面临的更多是“A强C弱“、”C强A弱“(A的强弱即系统响应的快慢)、“同步时延很高”这些灰色的东西。

“分区”是个中性词，不好也不坏。而CAP定理中的Partition代表的是一种“坏”的情况。 这里介绍说： 引用 A partition happens when, say, a network cable gets chopped, and Node A can no longer communicate with Node B. 可以看出，partition指的是两个结点之间无法互通，这可能是因为网络线路断开，也可能是因为其中一个结点出了故障。 这跟我们平常说的分区完全不是一回事。"partition"译成“阻断“才比较合适，或者干脆译成”结点间互联失败“；也只有这样译，它跟tolerance连起来用才有意义： “对网络通信的容忍度”可以理解， 而“对分区的容忍度”。。。这什么玩意？　 这个错误的译法会让人坠入云里雾里，在阅读相关文献时抓破脑袋。从这个意义上说，第一个把"Partition Tolerance"译成“分区耐受性”的人，应该主动切腹以谢国人。

1.对于跨数据库的业务操作，如果追求强一致性，就要走2PC(two-phase commit) 协议。而这个协议在Availability方面可能表现不佳：    a.只要一个库回滚，大家都得回滚    b.导致多处的资源上锁，影响性能 2.按不同的语境，弱一致性有两种含义：   a. 不要求所有子操作原子地执行。可以容忍有的操作成功，有的操作失败，比如用于估算的数据，可以允许零星的失败   b. 不要求在甲方扣款后乙方在同一瞬间收到款，可以允许乙方隔一段时间后（最终）收到款（即最终一致性） 3.“最终一致性”一般可以通过消息队列来实现：完成一个子操作后，发出一个消息，这个消息将被异步地处理   a. 即使一个系统挂了，也不会影响上游系统继续工作   b. 如果系统处理一个消息失败，可能需要重复处理这个消息。 所以最好把消息消费设计成Idempotent 参考资料： http://queue.acm.org/detail.cfm?id=1394128

有了第4层负载均衡（比如lvs)，为什么还要做第7层的(比如nginx, squid)？ 第4层负载确实已经能做到比较全面了，但不方便做app-specific的均衡策略。 比如“凡是URL以detail.*开头的请求都导到A1-A10结点”，用lvs等就不方便做。然而，用nginx等就比较好实现。  也就是说 第7层负载可以实现更加灵活的、与应用层信息相关的均衡策略。

答：keepalived. 在lvs集群中它提供了两种结点健康相关的应用：   1. 监视server pool里各结点的状态，以供load balancer略过不健康的server   2. 通过VRRP协议实现loader balancer之间的主备切换（failover）

源自林昊的《分布式JAVA应用》 由于机器多， 1. 机柜要足够多 2. 电力、网络消耗高 3. 运维复杂性高，要做一些管理工具，提升管理效率或者进行自动化管理