写代码解小学数学题,这数学真不是好做的

回到家,小乐有道数学题做不出,惯例需要我出马了。题目很简单,用0..9的十个数字将两个三位数相加得到一个四位数,数字不能有重复。

math

不过我凑了半天,除了知道和的第一位应该是1外,其他没啥进展。有点懊恼,1000 * 1000,百万挑一,这不要累死啊!(当然可以做些排除)算了,我还是写个程序的了,顺便练习一下ruby的语法。以下是ruby代码:

  1 a=[]
  2 for i in 100..999
  3     for j in i..999
  4         k = i + j
  5         if k > 1000
  6             a[0] = i / 100
  7             a[1] = (i / 10) % 10
  8             a[2] = i % 10
  9             a[3] = j / 100
 10             a[4] = (j / 10) % 10
 11             a[5] = j % 10
 12             a[6] = k / 1000
 13             a[7] = (k / 100) % 10
 14             a[8] = (k / 10) % 10
 15             a[9] = k % 10
 16 
 17             found = 1
 18             for m in 0..9
 19                 for n in 0..9
 20                     if m != n && a[m] == a[n]
 21                         found = 0
 22                         break
 23                     end
 24                 end
 25                 if found == 0
 26                     break
 27                 end
 28             end
 29             if found == 1
 30                 puts "#{i} + #{j} = #{k}"
 31             end
 32         end
 33     end
 34 end
`</pre>

最终计算的结果,答案还挺多,一共有48个,给小乐演示了,算编程启蒙不?不过貌似她很淡定。放几个在后面,需要的家长随便挑吧。

<pre style="padding:14px;font-family:Monaco, 'Andale Mono', 'Courier New', monospace;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;margin:0 0 18px;line-height:16px;font-size:11px;border:1px dashed rgba(0,0,0,0.148438);white-space:pre-wrap;word-wrap:break-word;color:#737373;">`246 + 789 = 1035
249 + 786 = 1035
264 + 789 = 1053
269 + 784 = 1053
284 + 769 = 1053
286 + 749 = 1035
289 + 746 = 1035
289 + 764 = 1053
324 + 765 = 1089
325 + 764 = 1089
342 + 756 = 1098
346 + 752 = 1098
347 + 859 = 1206
349 + 857 = 1206
352 + 746 = 1098
356 + 742 = 1098
357 + 849 = 1206
359 + 847 = 1206
364 + 725 = 1089
365 + 724 = 1089
423 + 675 = 1098
425 + 673 = 1098
426 + 879 = 1305
429 + 876 = 1305
432 + 657 = 1089
437 + 589 = 1026
437 + 652 = 1089
439 + 587 = 1026
452 + 637 = 1089
457 + 632 = 1089
473 + 589 = 1062
473 + 625 = 1098
475 + 623 = 1098
476 + 829 = 1305
479 + 583 = 1062
479 + 826 = 1305
483 + 579 = 1062
487 + 539 = 1026
489 + 537 = 1026
489 + 573 = 1062
624 + 879 = 1503
629 + 874 = 1503
674 + 829 = 1503
679 + 824 = 1503
743 + 859 = 1602
749 + 853 = 1602
753 + 849 = 1602
759 + 843 = 1602

如果有更好的解题方法思路,还希望不吝赐教。

更新:第二个for循环修改从i开始,否则由于加数可以互换,答案会重复,所有结果应该只有48个。从最后的结果看有一个规律很有意思,所有的数字都能被3整除。

《高可用性的HDFS-HADOOP分布式文件系统深度实践》读书笔记

最近有项目在用HADOOP,比较关心NameNode的HA机制,翻了《高可用性的HDFS》,感觉整体内容并不多,较多的是代码、环境安装和测试,不过对于我这个门外汉来说,快速入门吧。以下是笔记:

HDFS的HA主要由NameNode的HA决定,NameNode的可靠性主要取决于自身计算机硬件系统的可靠性、系统软件以及HDFS软件的可靠性;NameNode的可维护性则取决于元数据的可靠性以及NameNode服务恢复时间。

比较成熟的HA解决方案有:

  • Hadoop的元数据库备份方案
  • Hadoop的Secondary NameNode方案
  • Hadoop的Checkpoint Node方案
  • Hadoop的Backup Node方案
  • DRDB方案
  • Facebook的Avatarnode方案
    元数据备份方案和DRRB方案不能单独使用,因为在系统的运行期间,没有相应的checkpoint机制,会造成日志的无限制增长。

Hadoop的元数据库备份方案

hadoop的自身failover机制,配置dfs.name.dir,将元数据保存到多个目录(一个本地,一个远程,通过NFS进行共享)

  • hadoop自带机制,成熟可靠,元数据有多个备份,写多份效率低;
  • 没有做到热备,需要重启NameNode,恢复时间与文件系统规模成正比;

Hadoop的Secondary NameNode方案

启动一个Secondary NameNode节点,定期从NameNode下载元数据信息(元数据镜像fsimage和操作日志edits),然后将fsimage和edits进行合并,生成新的fsimage,本地保存再推送到NameNode,再重置edits。

  • 定期做checkpoint,Secondary NameNode不是最新数据,存在一致性问题;
  • 没有热备;

Hadoop的Checkpoint Node方案

原理同上,但采用checkpoint机制进行备份。

Hadoop的Backup Node方案

不成熟,0.21以上版本支持,特性开发中

最终目标是为HDFS提供NameNode的热备节点,减少服务恢复时间,实现原理:通过同步更新机制,在BackupNode节点中保存一份与NameNode完全一致的内存镜像,并且当NameNode无法提供服务时,能自动接管。

三个阶段:

  • Checkpoint Node,定期checkpoint到磁盘;
  • Backup Node,改进checkpoint机制,同步更新backup node内存,backup node利用自身镜像做checkpoint;
  • Standby Node,实现热备。
    目前0.21.0实现了第一、二阶段。

在第二阶段的Backup Node中,采用了日志池(journal spool)的机制,用于缓存NameNode发送过来的来不及处理的日志记录。

DRDB方案

  • 元数据有多个备份,并且保持最新状态
  • 备份工作由DRDB完成,NameNode无需同步写多个备份目录,效率由于hadoop元数据备份方案;
  • 没有热备,备份节点切换时间长

Facebook的AvatarNode方案

Facebook提出并实现了HDFS的热备。Active Node作为Primary NameNode对外提供服务,Standby Node处于Safe mode模式,内存中保存Primary NameNode最新的元数据信息。Active Node和Standy Node通过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。

  • 提供热备,切换时间短;
  • facebook的代码版本;
  • Primary AvatarNode和Standby Node都继承自NameNode,Primary AvatarNode对外提供服务;
  • Standyby AvatarNode也运行一个NameNode进程,并与Primary AvatarNode的内存元数据保持同步,两者通过NFS进行元数据同步;
  • DataNode将Primary AvatarNode和Standby AvatarNode视之为两个NameNode,分别上报Block信息等;
  • Clients是Facebook提供的AvatarNode客户端;
  • NFS理论上是一个新的单一故障点(应该可以用SYMANTEC CFS代替
    注:BackupNode类似于同步写,日志要等待BackupNode更新后再将日志记录写到磁盘;而AvatarNode则是异步写,将日志写入NFS共享目录即结束。

Block更新同步问题:客户端写入一个文件A,写入成功后,Data Node分别向Primary和Standby报告Block位置信息,但由于同步周期未到,Standby里没有文件A的信息,此时Standby会循环检查对应关系,直到收到Primary送过来的日志有关于文件A与Block的对应关系信息。

关于源代码:

  • Patch方式,直接作用于hadoop官方版,支持0.20;
  • Facebook维护的hadoop分支;

元数据解析

元数据有三类重要信息:

  • 文件和目录自身的属性信息,例如文件名,目录名,父目录信息,文件大小,创建时间,修改时间等;
  • 文件内存存储相关信息,例如文件分块,副本个数,每个副本所在的DataNode信息等;
  • HDFS中素有DataNode的信息,用于DataNode管理;
    从来源上讲,元数据主要来源于NameNode磁盘上的元数据文件,包括元数据镜像fsimage和元数据操作日志edits两个文件。

INode

文件和目录的抽象,所有INode信息完全位于内存。(类FSImage是内存元数据和磁盘元数据文件之间的桥梁,做内存数据持久化和磁盘文件加载)。

  • HDFS没有采用定期导出元数据的办法,而是采用FSImage+edits的备份机制。
  • HDFS启动时会读取元数据镜像文件和日志文件到内存,进行合并形成最新的内存元数据,再保存到磁盘,形成新的磁盘镜像文件和日志文件。需要消耗一定的时间做合并
  • 运行过程中HDFS不再从内存中到处元数据,而只是记录日志文件。

Block

按照文件大小划分成块,默认Block大小为64MB。

磁盘元数据文件

  • fsimage:元数据镜像文件,存储的是某一时刻NameNode内存元数据信息,包括所有的INode信息、正在写入的文件信息以及其他的一些状态信息;
  • edits:日志文件,保存了该时刻以后元数据的操作记录;
  • fstime:保存了最近一次Checkpoint的时间;
  • VERSION:标志性文件,最后创建,表明前三个文件创建成功。
  • fsimage, edits都有两个状态,以文件名区分。fsimage.ckpt表示checkpoint过程中上传到NameNode的fsimage文件,checkpoint结束时重明明;edits.new同样如此。

几个统计数据

  • facebook集群存储了1.5亿个文件,加载namenode元数据和等待块位置映射信息上报这两个阶段各自耗费的时间大概都在20分钟左右;
  • 在yahoo运行的15个集群中,三年时间内,只有3次NamoNode的故障与硬件问题有关。

关于hadoop的版本

hadoop version

  • Facebook Hadoop分支的版本是再0.20-append基础上,加入自身特性发展起来的;
  • Clourera CDH3
    BTW. 这是第一篇用Mou编写的markdown格式的文章,挺方便的,要是支持直接发布到wordpress上就更好了。

一早使用QQ邮箱体验的好与坏

其实我并没在用QQ邮箱,只是偶尔看看订阅的朋友QQ空间。今天打开的时候看到有一封新邮件,看了一下,居然是我的生日祝福。其实挺普通,但与众不同的是这是第一个产品在农历生日时给我祝福的,这对于象我这样只知道农历生日,而完全无视公历的人来说,还是带来一丝暖意。远远超出了众多银行按我身份证发的短信或邮件了,因为身份证日期对于象我们这一代的人来说出错太多了。
一下子有想使用QQ邮箱的冲动,第一感觉是设置农历日期的提醒,并看看是否能同步到手机上。我就点开了日历,弹出来一个对话框:

奥运赛程日历提醒定制。
一下子有吃了苍蝇的感觉。我的老天,今天是9月13日,奥运都是记忆了。你还提醒啊!难道没人运营的吗?
于是我就停下了,写了上面这段文字。
BTW. 本来截图是准备上传到skitch的,可skitch自从给Evernote收购后,mac 客户端闪退,也无法上传,网页打不开,打开了上传又半天不见动静。NND,这Evernote买了是打算放弃的吗?

小学教育中的磁带什么时候才能与时俱进

10年开学的时候小乐一年级,领回了一盒磁带,只好又翻出了一个古董

不过最后基本也没听。

3年过去了,又要开始学习英语了,果然又领回两盒磁带,这都啥年代了啊!这上头的领导都是白痴吗?不能发电子版的吗?还是这磁带背后也有众多利益啊?

去淘宝上搜索了一下,有n多的店铺在卖电子版的,不过貌似提供2012最新版的不多。5元钱买了一个,就直接放在这里下载吧,人教版加拿大PEP小学英语(三年级起点)三年级上,需要的家长朋友可以直接取。