API

每次与Java组的同事们坐下来谈技术、谈理想、谈人生时，Java组的同事总会向我们投来羡慕的眼光：卧槽！又是自己开发的工具，太NB了。这时C程序 员们的脸上就会洋溢出自豪的笑容，然后内心骂道：谁让我们没有现成的呢。另一个空间里的某些“无C不欢”们或者某些“C Guru”们会骂道：靠，有了也不用，自己写！ ...

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

近期一直在做一个项目架构演化的讨论交流，为了解决产品中存在的某些问题，我们有意引入某种类Memcached的开源产品，但我们的应用场景并非经典Memcached的“Cache”场景，这里也不详述细节了，大致就是这么一件事儿。 我们的第一选择是日本小伙儿Mikio Hirabayashi实现的Tokyo Tyrant，主要基于三点原因： -> 支持数据的持久化 -> 快！（性能数据来自于网上的第三方资料） -> 无商业许可证束缚 ...