Distributed Computing

试了一下这个基于 CLucene 的全文搜索，似乎还不错。这里记一下过程。

首先是给 dovecot 安装 Lucene 插件，用 FreeBSD port 来安装的话，只需 make config，选择 LUCENE 然后 portmaster dovecot 即可。

配置也还算容易，我之前已经做了索引与数据分开，因此并不需要单独的配置，只需在 dovecot.conf 中增加：

我国在最晚不晚于宋代发明了水密隔舱。所谓水密隔舱，是指将船体分成若干个互不相通的舱区，这样当一个或几个舱区进水时，整个船体仍然可以有足够的浮力而不致沉没。这是一项相当重要的发明，类似的设计思路在其他领域也有应用。

📜 现时提倡的安装方式为 pkg，本文并未对此进行更新。

VirtualBox可以在远程运行，并把界面通过 ssh 的 X11 转发放到管理员的桌面。

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

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

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

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

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

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

和蛇头GG讨论了一个关于卖票的问题，简单地说是票很有限，需求量很大，如何能够尽可能高效地让票以尽可能公平的方式卖出去。

我设计了一个分布式的结构来解决这个问题，当然这个原型可以进一步改进，此处按下不表。记录一下我对这个结构公平性的描述的一个比喻：

Today I have some ideas about P2P application framework. Would check if there is any available ones and whether they can fulfil my ideas. Maybe I would start a project to implement these ideas in Python and/or C++.

由于某种原因需要一口气inject大约80万封信，结果中间就不成了。后来发现似乎3000-10000/queue为宜。什么原因呢？

So it happens.

As the website states, it works by:

• Sending your page requests through Google machines dedicated to handling Google Web Accelerator traffic.
• Storing copies of frequently looked at pages to make them quickly accessible.
  Downloading only the updates if a web page has changed slightly since you last viewed it.
• Prefetching certain pages onto your computer in advance.
• Managing your Internet connection to reduce delays.
• Compressing data before sending it to your computer.

Someone has disclosed that he is implementing iSCSI on FreeBSD, at scsi@. iSCSI is essential technology that is highly scalable and looks quite promising.

在火车上跟HD聊了聊关于GNS等等一系列项目的想法。所谓GNS是一个全局的目录服务，包括客户和服务器两部分，客户运行在提供各种不同服务的机器上(www, databases, etc)。

客户启动时，向服务器发出一个「WAKEUP」信号，服务器则向需要该服务的所有服务器发出同样信号；反之，当客户所在的机器准备下线时，也类似地发出信号。

www, databases等服务的consumer据此在自己的本地可用服务表中添加/删除目录项。