用惯了Vim后，也会有一种尝试新Editor的冲动，这回Sublime Text 2满足了我的这个需求。据说Sublime Text是目前最火的代码编辑器之一，我周围为数不多的几个比较Geek的同事都已经开始使用Sublime Text 2或用了很长时间了，其官方网站首页的Feature Demo也的确非常地炫。

安装Sublime Text 2

我的实验环境Ubuntu 12.04.1 32-bit Desktop版，默认Ubuntu Unity桌面，iBus拼音输入法。

Sublime Text 2的安装极其简单，遵循着download（http://www.sublimetext.com/2） -> unzip -> add path -> start and use的经典路线。我下载的Sublime Text 2是2.0.1版本，启动后一切正常。

安装后目录结构

安装后的Sublime Text 2的目录结构非常简洁：

$ ls
Icon/  PackageSetup.py   Pristine Packages/
lib/   sublime_plugin.py   sublime_text*

lib下是自带的Python26环境；Pristine Packages下是各种编程语言的插件包。

在我的环境下Sublime Text 2的用户配置与包环境放在了~/.config/sublime-text-2/下面，

$ ls
Installed Packages/  Packages/  Pristine Packages/  Settings/

这里面最重要的目录就是Packages目录了，这里是Sublime Text 2用第三方包扩展自身Feature的包存储路径。

安装package control

package control包之于Sublime Text 2就好比apt工具之于Ubuntu，它是一个方便第三方包安装、卸载和管理的第三方包。在其官网(http://wbond.net/sublime_packages/package_control)上明示了其安装方法：

* 敲入 ctrl + ` 调出命令行窗口
* 在命令行窗口中输入下面的代码，回车执行。

import urllib2,os; pf='Package Control.sublime-package'; ipp=sublime.installed_packages_path(); os.        makedirs(ipp) if not os.path.exists(ipp) else None; urllib2.install_opener(urllib2.build_opener(urllib2.   ProxyHandler())); open(os.path.join(ipp,pf),'wb').write(urllib2.urlopen('http://sublime.wbond.net/'+pf.replace(' ','%20')).read()); print('Please restart Sublime Text to finish installation')

* 重启Sublime Text 2。

注意：如果需要代理访问外网的话，需要正确设置http_proxy环境变量。

敲入"ctrl + shift + p"可打开命令窗口，输入"Package Control"，你会看到窗口下拉提示中Package Control支持的功能，常用的我们会选择：“Package Control: Install Package”。

安装中文支持

中国程序员每每在尝试一种国外程序员新开发的编辑器时，都会遇到中文字符集编码的问题，这次Sublime Text 2也不例外，它原生就不支持中文显示。还好中国程序员是无比聪明的，开发了ConvertToUTF8这样的第三方包，让我们可以看到中文并用中文编辑。

最简单的安装ConvertToUTF8的方法就是用Package Control安装，选择Package Control: Install Package后，搜素ConvertToUTF8，找到后，点击即可安装。安装后，你会在~/.config/sublime-text-2/Packages下面看到ConvertToUTF8包目录。

再次启动Sublime Text 2后，打开一个GBK编码的中文文档，居然提示ConvertToUTF8工作不正常。后发现ConvertToUTF8主页上有提示，Python 2.6下的ConvertToUTF8需要一个Codecs26的Package才能正常运行。下载Codecs26后，解压安装到Packages下面，重新启动Sublime Text 2，Sublime Text 2直接dump core。从Packages目录下将Codecs26删除后，Sublime Text 2恢复正常。

又细致读了ConvertToUTF8作者的README文件，发现master branch上的Codecs26是for 64位版本的，我需要下载x32 branch上的包。的确，下载并安装x32 branch上的Codecs26后，Sublime Text 2启动OK，转换中文OK了。

注意：不要与其他支持GBK转换的包（比如GBK Encoding Support）混用，否则ConvertToUTF8无法works。

解决中文输入问题

好不容易能看GBK编码的中文文件了，却发现无法输入中文，无论如何切换输入法和重启输入法，都无法输入中文。网上介绍可通过"Input Helper Package（cd .config/sublime-text-2/Packages; git clone http://github.com/xgenvn/InputHelper.git）"解决问题。问题的确可以解决，不过输入中文时太麻烦了：需要先敲入"ctrl+shift+z"调出中文输入框，再在这个框里输入中文。

网上都说这是iBus输入法与Sublime Text 2的兼容问题，要想解决就要换fcitx。以前用过fcitx感觉默认输入法比较弱，不过现在fcitx有google pinyin了，体验一定会提高不少。通过下面命令一键安装fcitx：

sudo apt-get install fcitx fcitx-googlepinyin

安装后，在“语言支持”中用fcitx替换掉iBus。在“启动应用程序”中加入：

名称: Fcitx
命令: /usr/bin/fcitx -d
注释t: Fcitx启动

注销再登录后，再打开Sublime Text 2，终于可以输入中文了。

功能

用了一遭儿，Sublime Text 2最吸引我的Feature包括：“Goto Anything”和“Multi-Selection”。在一个工程中，通过ctrl + p调出一个输入框，Sublime Text 2首先在文件名级别对你输入的文本进行匹配；待选择好文件后，继续输入@，可看到下拉列表中显示这个文件中所有函数名的名称列表；如果输入的是#，那么下拉列表中将显示该文件中的所有符号。选择某个函数名或符号后，光标将停留在某个符号上，这时我们可以用Multi-Selection这个功能了，如果你要将这个文件中同名符号全选出来，直接Alt+F3即可；如果要选择接下来的N个同名符号，那么敲入N次ctrl + D即可。

不过要想实现ctags那种在符号上跳转到符号定义或符号调用者的功能，Sublime Text 2还无法原生支持，可考虑安装Sublime Text 2的Ctags插件实现：直接在Packages目录下git clone https://github.com/SublimeText/CTags.git。之后：
- “ctrl +t, ctrl+ r"会重新生成tags文件(前提：系统内安装了ctags程序)
- "ctrl +t, ctrl + t"会跳到光标所在符号的定义处;
- "ctrl + t, ctrl + b"会跳回上次的位置;

感受

Sublime Text 2给我的最大感受就是“快”！你在搜索、切换符号、选择文件列表中文件或符号的同时，整个文件会同步的展现你的屏幕上。

这是我无意中想到的一个方法，估计这个方法已经不是什么新鲜的东西了，很可能在类似的问题场景中早已经被使用了。不过这里还是要说说我的思维过程。

近期在学习一些Linux性能查看和分析方面的工具，比如top、iostat、vmstat以及sar等。在学习过程中我发现这些工具有个共同的特点，那就是她们采集的Linux运行数据都是从/proc下的文件中实时获取并计算而得出的。众所周知，/proc是Linux内核维护的一个虚拟文件系统，他允许用户在Linux运行时查看内核运行数据（用户可以像查看普通文件一样查看/proc下的目录和文件），甚至是运行时实时改变内核设置。Linux实现/proc的细节不是这里要关注的，吸引我的是Linux的这种提取运行数据的设计。这个设计将Linux运行数据的产生实现细节与第三方性能采集工具间的耦合最大化地解开，这样一来/proc就像是一种Linux的基础服务，为用户提供一种实时的运行数据信息。而用户侧的运行数据查看工具也可以根据用户的需求自由定制，因此有了top、iostat、vmstat、iotop、sar等关注点不同的工具。

好了，说完/proc后，再来说说我们的产品。用户长期以来一直在抱怨我们的产品监控和维护方面手段太过单一，产品就像是一个黑盒，没有提供一种自我运行观察的能力，让客户看不清阿看不清，用户无法实时获取当前某个节点上的业务运行状况，无法采集到这些业务运行的实时基础数据，这的确是我们长期以来的短板（以前这块受重视度也的确不足）。虽然这两年我们在改善运维手段方面的投入已经加大，并收到一些显著的效果，但方案都是集中的，且相对重量级的，不那么敏捷灵活 – 在单节点上依旧无法简单地获取该节点的运行数据。

结合/proc的设计以及我们所遇到的问题，我有了一个大胆的想法：是否可以给我们的业务系统也加上一种类似Linux /proc这样的可提供基础运行数据的服务能力呢？于是就有了下面的解决方法。

Linux /proc下面的数据文件是Linux Kernel维护的，并允许用户层的进程实时查看和配置数据。而对于我们的产品而言，提供基础数据的产品实例与提取基础数据的第三方程序是两个独立的用户level的进程，显然我们需要找到一种让这两个进程实时通信、低耦合的且性能代价极低的方法。

我首先想到的是文件，这似乎和/proc的方式一样。你查看一下sysstat源码会发现，像iostat、sar等工具都是用fopen以"r"方式打开/proc/下的各种stat文件，匹配和读取指标项后再统计的。但在User层，两个无亲缘关系进程共同操作一个文件 – 一个读，一个写，the file position indicator是很难控制的，可能涉及文件锁(flock/fcntl)，还要考虑使用的库函数是否是带缓冲的（fread/fgets都是带缓冲 的，不能用），写端需要及时fsync/fflush。总而言之，这么做是甚为自讨没趣的，会给两个程序的实现都带来很大的复杂性以及各种“坑”的。

那用named fifo如何呢？一但用named fifo，这两个进程就会产生启动依赖，如果一端没有启动，另一端会一直阻塞；而且通过fifo传递多种业务数据还可能存在打包和解包的过程，实现起来复杂的很。这显然是耦合十分严重的糟糕方案。

两个进程既要有共同的识别目标，就像/proc/cpuinfo这样的已知路径，一个进程还要能及时地得到另外一个进程运行时的数据，我们不妨尝试一下内存文件映射这个方案：运行数据提供的进程映射一个已知目标文件，比如perf/xxstat，然后在映射后的地址上创建和更新指标数据。比如我们建立一个整型数组，数组的每个元素都代表一种运行指标；而运行数据提取进程同样映射该文件，并在映射后获得数组中的各个元素值。下面是一个示例程序：

/* producer */
int
main()
{
    FILE *fp = NULL;

    errno = 0;
    fp = fopen(STAT_FILE, "w+");
    if (fp == NULL) {
        printf("can not create stat file , err = %d\n", errno);
        return -1;
    }

    errno = 0;
    long size = sysconf(_SC_PAGESIZE);
    if (ftruncate(fileno(fp), size) != 0) {
        printf("can not set stat file size, err = %d\n", errno);
        fclose(fp);
        return -1;
    }

    errno = 0;
    char *p = NULL;
    p = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_SHARED, fileno(fp), 0);
    if (p == MAP_FAILED) {
        printf("can not mmap file, error = %d\n", errno);
        fclose(fp);
        return -1;
    }

    errno = 0;
    if (fclose(fp) != 0) {
        printf("can not close file, error = %d\n", errno);
        return -1;
    }

    /* round up to 8 */
    while((int)p % 8 != 0) {
        p++;
    }

    long long *q = (long long*)p;
    q[0] = 1;
    q[1] = 1000;
    q[2] = 10000;
    q[3] = 100000;

    while(1) {
        q[0] += 1;
        q[1] += 10;
        q[2] += 100;
        q[3] += 1000;
        usleep(200);
    }

    return 0;
}

该producer程序首先尝试以"w+"方式打开xxstat文件，并设置文件的大小，然后调用mmap做内存文件映射，理论上来说mmap成功时返回的地址一定是按该平台下最严格内存系数对齐的地址，但这里为了安全起见，又做了一次内存地址的圆整。producer以映射的地址为首地址，建立了一个包含四个元素的、每个元素大小为8字节的整型数组，其中每个元素模拟一个运行指标。在while(1)循环中，producer模拟更新这四个指标数据。

下面是提取producer运行数据的例子程序，其映射过程与producer类似，这里就不贴出完整代码了，完整代码可在这里下载。

/* reader.c */

int
main()
{
    FILE *fp = NULL;
    … …

    char *p = NULL;
    p = mmap(NULL, size, PROT_READ,
             MAP_SHARED, fileno(fp), 0);
    if (p == MAP_FAILED) {
        printf("can not mmap file, error = %d\n", errno);
        fclose(fp);
        return -1;
    }

    … …

    long long *q = (long long*)p;

    while(1) {
        printf("%lld\t\t%lld\t\t%lld\t\t%lld\n", q[0], q[1], q[2], q[3]);
        sleep(1);
    }

    return 0;
}

在producer执行一段时间后，我们可以用reader去提取producer的实时运行数据了。

$ reader
2583        26820        268200        2682000
5793        58920        589200        5892000
9142        92410        924100        9241000
12431        125300        1253000        12530000
15586        156850        1568500        15685000
… …

需要注意的是两个进程映射的虽然是同一个文件，但各自进程空间映射的地址是不同的。如果在指标里存储地址数据，那另外一个进程在访问该地址时必然会出现问题。

在这个方案中，由于两个进程是读写同一块内存(虽然在各自进程空间的地址是不同的），因此数据是实时的。但由于两个进程间并没有任何同步机制，可能会产生误差，就好比一个进程中的两个线程对进程中某块地址空间一读一写这种情况一样。不过对于我们这种场景，这个问题是一般是可以被容忍和接受的，毕竟我们通过运行数据只是想了解一种运行趋势而已。如果producer中存在多个有亲缘关系的子进程或多线程要同时更新基础运行数据，那势必是要用锁或其他原子操作做数据操作的同步的。另外我们用的是内存映射具名的文件，OS会定期将数据刷到磁盘上，不过这个消耗对于小文件来说，对整体性能影响可忽略不计。

一旦业务系统具备了提供基础运行数据的能力，我们就可以根据我们的需求按照数据的格式打造我们所需要的各类数据提取和分析工具了。如果需要长期记录业务系统的运行情况，我们也可以实现类似sar这样的工具，以在后台定期对系统的运行数据进行记录，并提供历史查询等相关功能。

这种基于内存映射文件的方法还有一个好处，那就是我们可以用任何支持mmap调用的编程语言来实现数据提取工具，而不一定非得用C/C++这种原生适配Linux API的语言。

如果你觉得这种方案可行，那后续的重点就是基础运行数据的设计问题了。罗马不是一天建成的，/proc下的基础数据也不是一天就设计到位的。在基础数据设计这方面也是需要有很多考虑的，比如是文本还是二进制，用什么类型数据，还可能需要考虑一些数据对齐问题等。当然这就不是本文的重点了，就不细说了。