周日尝试一下登山，顺便锻炼下身体，6点多出发，近10点钟返回，从灵岩山行走至天平山，历时3个多小时。

临近结束，下山的时候，膝盖有些不舒服，之前跑步的扭伤的，还没有好，才知道下山挺伤膝盖的。

上图为领头的两位队员。

– 分割线 –

坎坷的人生，来自家乡的高逸峰：

傍晚去买3D眼镜，在回来的路上，偶然发现路边的书报亭有《独唱团》出售，遂买下。前些时候准备从淘宝上买，卡有些问题，一直耽搁至今。

——–分割线——–

看了这篇文章，就去买个3D眼镜（红蓝）玩玩，不是专业的那种，10-15块的而已，千万别戴时间长了，看多了眼睛会累。这里还有3D播放器和片源。这种眼镜不适合看3D电影，效果不好，想看，还是去影院看吧，偶尔看看图片还是可以的，Flickr上还有很多红蓝3D图片，请点击这里。

[ad]

周末的时候和team讨论了下如何用最简单的方式，提高数据文件的单位时间传输吞吐量。下面是一个简单的应用场景：

一个目录(DIR1)，有很多Producer向这个目录里面放文件，同时有很多的Consumer负责从这个目录里面消费这些文件，插入数据库或者做其他的操作，然后删除或者移走这些文件。

假设条件：

• 一个文件中转目录DIR1，这个目录位于一个网络存储上
• 一个生产者，每一秒钟向DIR1里面放一个文件
• 若干个消费者，假设有8个，其实是8个不同的服务器，都可以访问DIR1，多台服务器可以起负载均衡的作用，任何一台或者几台出问题，整个数据流不会中断
• 解析一个文件大约需要2-14秒
• 最后一点：位于网络存储上的目录DIR1，我们认为它是不会出问题的，它不是这里的问题核心

这个场景很普遍，很多公司大概都会用到，尤其是那么比较老的系统(Legacy System)，下面是两种方案：

方案一

Consumer循环扫描DIR1，一旦发现有文件，循环解析这些文件，这里有8台服务器，也就是说有8个Consumer一起这样做。代码如下：

	public void run() {
		System.out.println("Created consumer:" + threadName);

		while (true) {
			File file = new File(Constant.STAGING_FOLDER);
			File files[] = file.listFiles();
			for (int i = 0; i < files.length; ++i) {
				File f = files[i];
				parse(Constant.STAGING_FOLDER + "/" + f.getName());
			}

			Commons.sleep();
		}
	}

看起来很简单，可是上面的代码效率非常的差，多个Consumer有很大的几率拿到相同的文件，当某个Consumer尝试去解析一个文件时，却发现这个文件已经被别的Consumer解析过了，并且文件也都删除或者移走了。这样浪费的很多的CPU时间。

可以用下面的方案来替代：

方案二

	public void run() {
		System.out.println("Created consumer:" + threadName);

		while (true) {
			File file = new File(Constant.STAGING_FOLDER);
			File files[] = file.listFiles();

			int nCapacity = files.length > Constant.CAPACITY ? Constant.CAPACITY
					: files.length;
			System.out.println(this.threadName + " found " + nCapacity
					+ " files");

			for (int i = 0; i < nCapacity; ++i) {
				File f = files[i];
				f.renameTo(new File(Constant.TMP_FOLDER + "/" + f.getName()));
			}

			for (int i = 0; i < nCapacity; ++i) {
				parse(Constant.TMP_FOLDER + "/" + files[i].getName());
			}

			Commons.sleep();
		}
	}

它和方案一的不同之处在于：它每次扫描完目录后，最多只取前若干个文件，这里是10个。并且，它不急于去处理文件，而是把文件马上移动到一个临时工作目录，其他的的操作都是相同的。

对于这个方案，有个附加条件：这个临时工作目录tmp，一定要和staging目录在同一个文件系统(filesystem)，这样的话，mv操作就只是修改一下inode，几乎瞬间完成。

比较（Benchmarking)

为了测试两中方案的效率差别，我写了一个模拟程序(http://googlestop.com/download/SimConsumer.7z)，它有7个class：

1. App.java - 程序入口
2. Commons.java - 共享的函数
3. Constant.java – 配置参数
4. Producer.java - 生产者，每隔一秒向目录staging里丢一个文件
5. AbstractConsumer.java – 抽象消费者，定义消费者的一些基本属性和行为
6. Consumer1.java - 具体消费者，实现方案一
7. Consumer2.java - 具体消费者，实现方案二

在App.java中，你可以指定调用Consumer1还是Consumer2。

对于前者(Consumer1)，staging目录下的文件数目不停的增长，并且如log显示，有很多冲突：一个Consumer准备处理的文件已经被其他的Consumer处理完了，造成了很多无效的操作，由于消费速度更不上生产速度，DIR1被撑爆只是时间的问题。

对于后者(Consumer2)，staging目录下的文件几乎马上就会被移动到tmp目录下，大部分时间，文件数都为0。而tmp目录下，在程序稳定后大概保存在20多个文件左右，保持一个动态的平衡。用这种方式，你也会看到很多冲突，但是只会发生在程序刚开始，原因是，刚开始的时候，8个线程几乎是同时去访问staging目录，势必拿到很多相同的文件，待到稳定后，就很少有冲突发生了。

这两种方案都是最基本的，没有借助于第三方工具完成的，成本是最低的，其实还有一些其他的方案，可能会借助一些服务来实现，比如消息分发、数据库等。有时间的话，我继续补充。

[ad]

如果你是个Microsoft OneNote的用户，并且可能会在多台电脑上记录笔记，那么一定会遇到如何同步这些笔记的问题，标题中的两个服务可以为我们解决这个问题。一个是Drop Box，官网为：www.dropbox.com ，这个网站在中国大陆目前无法访问(原因大概是中国政府不希望网民使用它来分享信息，任何有利于信息自由流动和传播的服务都难逃此运)。另外一个是Microsoft出品的Live Sync。

方法极其简单：在需要同步的两台电脑上，安装DropBox或者Live Sync，然后将OneNote的目录设置在需要同步的目录里面即可。

对于Drop Box，你需要在hosts文件中添加如下项目：

# 下面的IP不保证长期有效

174.36.30.67    dropbox.com
174.36.30.71     www.dropbox.com
75.101.129.115   dl.dropbox.com
75.101.159.151 dl-web.dropbox.com
174.36.30.67      forums.dropbox.com

对于Live Sync，你要注意的是，如果你的两个系统都是Windows 7或者Vista，建议你安装最新版本的Windows Live Sync，如果其中有一个是Windows XP，那么你只能选择针对XP的老版本的Live Sync。

我会继续介绍一些提高工作效率的方法，即使方法简单的如这篇文章一样，总会有人用的到。

关键字：One Note、同步、笔记、Sync

[ad]