思考

这是一个很有意思的话题：随着计算机技术的发展，客户端的计算能力越来越强。想要提高在服务器端运行的系统的负载能力，最直接有效的办法就是把计算任务尽可能交给客户端去做，并减少两者之间的交互；然而，另一方面，这样做又可能会带来一些其他问题，例如，客户端完成某些计算任务的时候可能会比较慢（因为在客户端可以用到的资源比较少，想要保持兼容性最好的办法就是只使用普适的Java Script子集），或者，作为安全系统的一个最基本的原则，任何来自外界的数据都是不应被信任的，等等。

看文档的时候，最恶心的事情就是明明那不是一份作弊条文档，却只罗列作者是怎么把一件事做起来的，譬如说列出命令行选项，但是不说这些选项是干什么的，以及为什么选上这些选项。

前一段日子，偶然又看了几集 千王之王重出江湖。其中有一集说到了沈胜天和龙四的决裂，两个人各执己见最后断绝师徒关系。

原则是什么？原则是一个人判断事情的准则，或者说价值观，但又不完全是。我想，还需要再加上一条：不会轻易改变。没有原则的人，要么对于事情的是非没有观念，要么对于是非的判断会经常发生变化，和这样的人长期合作会比较危险。

蛇头GG发来的一篇文章，值得一读：The Difference Between Art and Design。摘录一下标题：

• 艺术源于灵感，而设计源于动机。
• 艺术为人诠释，而设计为人理解。
• 艺术是一种品味，而设计则是一种主张。
• 艺术来自天赋，而设计来自技艺。
• 艺术为不同的人带来不同的信息，而设计为不同的人带来相同的信息。

先把想法记下来。

• 提供一种描述语言，将应用层协议描述成DFA；
• 一个generator将DFA转换为代码；
• 用户态程序通过某种接口来向kernel请求已经协商好的该种协议的socket并由kernel直接填写一部分数据结构；
• 应用程序对socket的第一个回应有时间限制—-如果一段时间之内不回应，则系统将该socket交给下一个监听进程。

解决的问题：

今天在 Matrix67 的 blog 上看到这么一道题：

一个人有两个小孩儿，其中有一个生于星期二的男孩儿。问另一个是男孩儿的概率是多少？

答案当然不是1/2或者1/4，因为我们已经知道了有一个是生于星期二的男孩，因此这是一个条件概率问题。

那啥，我是写给那谁看的。

共同点：持有价格低于其价值的资本。

不同点：套牢的含义是，在资本价格较高时买入并持有（此时抛出会导致损失）；抄底的含义是，在资本价格较低时买入并持有（通常，是在价格较低甚至最低的时买入）。

版本控制、持续集成测试、自动化回归测试等等，都拦不住不靠谱的开发人员和盲目引入新特性而不关注可用性和可靠性的架构师。某开源项目真是快让我发疯了，明明都已经第十几个小版本了……

（1899年10月15日）

第一节　国民与国家之异

中国人不知有国民也，数千年来通行之语，只有以国家二字并称者，未闻有以国民二字并称者。国家者何？国民者何？国家者，以国为一家私产之称也。古者国之起原，必自家族。一族之长者，若其勇者，统率其族以与他族相角，久之而化家为国，其权无限，奴畜群族，鞭笞叱咤，一家失势，他家代之，以暴易暴，无有已时，是之谓国家。国民者，以国为人民公产之称也。国者积民而成，舍民之外，则无有国。

以一国之民，治一国之事，定一国之法，谋一国之利，捍一国之患，其民不可得而侮，其国不可得而亡，是之谓国民。

第二节　国民竞争与国家竞争之异

有国家之竞争，有国民之竞争。国家竞争者，国君糜烂其民以与他国争者也；国民竞争者，一国之人各自为其性命财产之关系而与他国争者也。孔子之无义战也，墨子之非攻也，孟子所谓率土地而食人肉，罪不容于死也，皆为国家竞争者言之也。近世欧洲大家之论曰：“竞争者，进化之母也；

战事者，文明之媒也。“为国民竞争者言之也。国家竞争其力薄，国民竞争其力强；国家竞争其时短，国民竞争其时长。

今夫秦始皇也，亚历山大也，成吉思汗也，拿破仑也，古今东西史乘所称武功最盛之人也，其战也，皆出自封豕长蛇之野心，席卷囊括之异志，眈眈逐逐，不复可制，遂不惜驱一国之人以殉之。其战也，一人之战，非一国之战也。惟一人之战，故其从战者皆迫于号令，不得已而赴之，苟可以规避者，则获免为幸，是以其军志易涣，其军气易馁，故曰其力弱；惟一人之战，故其人一旦而败也，一旦而死也，其战事遂烟消瓦解，不留其影响，故曰其时短。若国民竞争则反是。凡任国事者，遇国难之至，当视其敌国为国家之竞争乎？

为国民之竞争乎？然后可以语于御抵之法也。

关于Scalability这个词的中文译法，目前还没有一个非常确切的定论。一些文献中将其翻译为"可扩充性"，而"扩充"指的主要是Scale up；而在一些实际的用法中，Scalability还包括Scale down，因此，“可伸缩性"也许是比较贴近原文意思的说法。

互联网应用的可扩充性体现在两个方面：其一，是能够对系统容量进行扩充，也就是说，这个系统各个组件能够提供的服务的量，能够在需要的时候予以扩充（特别是通过添加新的服务器等等）。其二，是这种扩充是有效率的扩充，即，增加硬件投入时，其投入与所产生的效果是接近甚至达到成比例增加的。通常说来，“可扩充"同时暗含的需求是用户的使用习惯尽可能保持不变。如果我们关注某一具体的计算节点，可扩充性还应体现于提高计算节点性能，例如增加其CPU数量或内存容量时，能够相应地改善系统的容量或响应时间，等等。

而另一方面，“可缩减性"主要指的则是说一套系统能够运行在尽可能少的软硬件环境之中。对于大型互联网公司而言，这一点可能并不重要，而对初创公司来说这一点则非常重要。

在设计互联网应用的时候，充分地考虑系统的可伸缩性，能够极大地减少日后的维护开销，并帮助决策者对于投资所能获得的回报进行更加精准的估计；另一方面，高可伸缩性的系统往往会具有更好的容灾能力，从而提供更好的用户体验。

与解决很多其他问题类似，改善可伸缩性最常用的方法就是分治法(Divide and Conquer)。分治属于大道理一类，在实践中，我们比较常用的分治策略包括：

• 提高计算的可并行度。简单的计算，例如连续执行的加法，可以将中间结果的计算并行完成；而复杂一些的计算，例如搜索，也可以通过类似的方式分派到不同的单元中进行，并最终在另外的地方完成汇总。这种策略，比较适合于数据集中数据之间直接关联度不大、生成数据集比输入数据集小很多，并且汇总计算本身引起的开销较小的情形。
• 增加能够完成同一类任务的计算/服务单元数。这类做法中，计算/服务单元仅仅完成某种将输入变换为输出的工作，并且，这类工作不太依赖于其与外界交互产生的状态，简而言之，对于输入数据，计算/服务单元能够自行完成一个环节的计算任务并给出输出。这种策略比较适合于存在，或可能成为瓶颈的位置。举例来说，对于读多写少的应用，通过适当增加cache环节（这些cache是全冗余的，也就是不同的机器之间可以完全地相互取代），就能够有效地提高其负载能力。
• 消除单一故障点/瓶颈。如果一个系统中某些数据只存在一份，或某种计算只能在某一点上完成，那么这些环节就会成为单一故障点，或性能瓶颈。消除这类问题需要更巧妙的设计，简单地将数据复制到更多的机器上并不能够从根本上解决问题，因为在这种结构中"主"节点仍会成为瓶颈。有时，为了达到这个目的需要进行一些折衷设计，例如分段提交的方法，在容忍一部分竞态条件（race condition）的前提下避免另一些、不能容忍的竞态条件。这类做法往往会导致局部吞吐量受到负面影响，或使设计变得复杂。