网络经济很脆弱，一缆断了啥事也做不成。

新浪科技来搞：

网易科技无来搞

搜狐科技来搞：

:至北美70%互联网电路中断

在家（网通ADSL）上不去或很慢的网站列表：

http://www.54chen.com

http://www..com

http://www.yahoo.com

...

公司的网络：（具ip138参考）

• 本站主数据： 网通
• 参考数据一： 网通
• 参考数据二： 网通ADSL

http://www.adobe.com

http://www.642weather.com

http://.com/

http://www.wordpress.com

...

MSN的确已经恢复，但还在丢消息。

[转载请注明：http://www.54chen.com/727-how-to-redirect-wordpress-rss-feeds-to-feedburner-with-nginx-original/ 作者：陈臻]

可能有大多数朋友都会在用wordpress的时候需要从原始的feed地址转到feedburner上，看到一个老外的博客上说了apache的htaccess的修改方案：

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner    [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/-aboutJavaAndPhp [R=302,NC,L]
</IfModule>

if ($http_user_agent !~ FeedBurner) {
  rewrite ^/feed$ http://feeds.feedburner.com/-aboutJavaAndPhp redirect;
  rewrite ^/feed/$ http://feeds.feedburner.com/-aboutJavaAndPhp redirect;
}

联合利华引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没 装入香皂。总不能把空盒子卖给顾客啊，他们只好请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科 研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了几十万，成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且 驱动一只机械手把空皂盒推走。 南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为发火，找了个小工来说你TMD给我把这个搞定。小工果然想出了办法：他在生产线旁边放了 台风扇猛吹，空皂盒自然会被吹走.

转老故事一个，发散下思维，凡事换个方式想问题。

[作者：陈臻 转载请注明出处：http://www.54chen.com/714-design-for-all-key-value-of-the-distributed-system-architecture-original/ 版本：1.1  2090810]

8.10 增加dev4server组里esx大侠提出的几个性问题

这个架构的产生，是为了公司的一个新项目，而后来慢慢变成了解决整个公司的所有问题的一个架构，期间经yahoo的angentZh先生、dev4server组里张立冰先生、盛大的许式伟先生推荐研究了bigtable、Dynamo等很有性的分布式架构。

如下图所示：

总体：底层以key-value存储，每个节点内作主主互备，节点以一致性哈希存取，哈希所使用的key为relation-key，非直接存取时的key。

step 0：连接客户端收到一个key为relatioin-key_id的存取请求，取出relation-key进行一致性哈希计算，这里是为了让相关的内容都能存在一个节点上，类似bigtable的tablet；

step 1：连接客户端读取最新的配置文件，server.conf。

step 2：根据配置文件寻找正确的节点。

step 3：在B节点之间增加了一个节点A的时候，A前的虚拟节点将寻找不到数据，此时连接客户端会重新读取老的配置文件server.conf.1，根据老的配置，这里的数据会去B节点读取原来的数据，读到的数据会转移到新增加的节点A中。

step 4：增加节点A后，服务器端会同时运行手动的转移脚本，转移脚本直接将B节点中符合A节点的存取规则的数据全部转移，转移结束将作server.conf.1，进行删除老配置文件的作。

这个架构的特点：

1.底层的key-value引擎并不特指某种，用cabinet或者是mysql都是可以的；

2.增加或者删除节点都可以是半自动+半手动或者是全手动处理；

3.适合大多数大型网站任何业务。

这个架构的名字：未命名

1. 速度：relation-key存储的方式，使相关性强的数据都在一起，保障批量的速度；

2.容灾：底层master-master同步的DB保障了其中一台出现故障不会影响整个系统；

3.扩展：手动加自动的方式使扩展节点应对自如。

Q&A:

A:系统中有server.conf server.conf.1 server.conf.2....只检测配置文件，如果手动迁移数据结束，配置文件将被删除。
Q:节点A进入时，是否能有选择的向B所要数据？

A:这里的确是忽略了同一个key的数据的版本控制的问题。如果先执行了手动脚本再存到A结点是正常的，如果先存到A再执行手动脚本，会出现老数据盖了新数据。不知有啥好的idea没?
Q:所要数据后，何时算完成？因为B可能一直在有新数据生成。

A:如果是新的配置文件上来了，写入B的数据应该就已经是新的规则了，这样，只需要手动执行的脚本循环当前的数据一圈，其中的数据自然是正确无误的了。手动脚本完成后删除老的配置文件标志迁移结束。
Q:完成后，节点A如何生效？

A:老的配置文件删除前，读数据作是半生效状态（逐步恢复）；老的配置文件被删除后，A节点的读写都自然生效了。
Q:容灾，如果节点A掉了，那B上是否有A所保存的信息？

A:一个节点下有至少两个物理实际节点做主主备份，上面是一个带网络检测和自动选取连接的工具，虚拟成一个节点，换句话说，A节点两台机器全部坏掉的可能性这里视为零。

作者不详，如果作者看到可联系站长添加版权声明。

本文首先从P2P的定义出发，介绍了结构化P2P与非结构化P2P的区别以及结构化P2P的核心技术DHT。而后，本文深入介绍了几种主流的DHT算法与协议并对每种协议进行了讨论。文章的最后展望了DHT在未来的发展趋势。

对 等网络(Peer-to-Peer，简称P2P)是目前非常热门的应用，自1999年以来，P2P的研究一直是知名学府(如佬麻省理工学院，加州大 学伯克利分校和莱斯大学等)以及知名企业的研发机构(如微软，诺基亚的研究院)关注的重点。它甚至被佬《财富》杂志称为改变因特网发展的四大新技术之 一，被认为是无线宽带互联网未来的关键技术。

作为一项新兴的技术，目前学术界对P2P在 技术层面上的定义尚未统一。Keith W. Ross (Polytechnic University)和Dan Rubenstein(Columbia University)在[9]中提到了对P2P系统的3个基本定义：

相比服务器而言有明显的自治性(Autonomy)。

利用网络边缘的资源，如存储/计算能力和信息资源。

网络边缘的资源处在动态的变化中(新的资源加入，已有的资源消失)。

自治性的要求使得P2P系统不再需要特定的管理机制，所有节点之间拥有对等的关系。这一方面为系统带来了自组织、容错性好、可扩展性强等优点；另一方面也提出了新的问题：如何在没有集中管理机制的情况下实现系统的自组织和自管理？

定义2，3中分布性和动态性的特点使得上述问题的实现具有更大的难度。在分布式系统中，过多过快的信息交互可能消耗大量的网络资源；而为了实时反映系统的变化，又要求节点及时获得更新信息，这就需要在节点之间进行通信。

为了解决这一对矛盾，已经有许多P2P的框架和协议被提出来并得到了很好的应用。

结构化与非结构化P2P

依照节点信息存储与搜索方式的不同，诸多P2P协议可以分为2大类：结构化(Structured)的与非结构化(Unstructured)的系统。

非结构化P2P系统

在 非结构化的系统中，每个节点存储自身的信息或信息的索引(如指针和IP地址)。当用户需要在P2P系统中获取信息时，他们预先并不知道这些信息(如某个文 件)会在那个节点上存储。因此，在非结构化P2P系统中，信息搜索的算法难免带有一定的盲目性，例如最简单的泛洪式查找(类似于广播)和扩展环查找(从最 近的n个节点开始，层层转发直到找到目标或超出了跳数的上限为止)。

一些典型的应用采用了一 些优化的办法。如在Gnutella中，采用了等级制的组成结构：节点被分成超级节点(Super Node)和普通节点。普通节点必须依附于超级节点，每个超级节点作为一个的域管理者，负责处理域内的查询作。在查找的过程中，查询首先在域内进 行，失败后才会扩展到超级节点之间。

非结构化系统的优点在于实现结构简单：无须服务器，节点之间完全平等，网络的层次是单一的，而且节点之间无需维护拓扑信息。

结构化P2P系统

在结构化P2P系统中，每个节点只存储特定的信息或特定信息的索引。当用户需要在P2P系统中获取信息时，他们必须知道这些信息(或索引)可能存在于那些节点中。由于用户预先知道应该搜索哪些节点，避免了非结构化P2P系统中使用的泛洪式查找，因此提高了信息搜索的效率。

但是，结构化P2P也引入了新的问题：

首先，既然信息是分布存储的，那么如何将信息分布存储在重叠网中的节点上？

其次，由于节点动态的加入和离开重叠网，如何将拓扑的变更信息通知其它节点？

DHT的引入基本解决了上述问题，因此自从DHT协议出现以后，结构化P2P的应用得到了快速的发展。目前已经有很多较为成熟的DHT协议被提出并且得到了应用。其中比较有性的有：缓冲阵列路由协议(CARP)；一致性哈希；Chord；内容寻址网络；Pastry。

DHT简介

DHT使用分布式哈希算法来解决结构化的分布式存储问题。分布式哈希算法的核心是通过将存储对象的特征(关键字)经过哈希运算，得到键值(Hash Key)，对象的分布存储依据键值来进行。具体来讲，大致有以下步骤：

对存储对象的关键字进行哈希运算，得到键值。这样就将所有的对象映射到了一个具体的数值范围中。

重叠网中的每个节点负责数值范围中的特定段落。例如，节点A负责存储键值从8000到8999的对象；而节点B负责7000~7999的对象。这样就将对象集合分布地存储在所有的节点中。

节点可以直接存储对象本身，如文件中的一个片段；也可以存储对象的索引，如该对象所在节点的IP地址。

结 构化的分布式存储问题解决后，剩下的问题就是用户如何才能找到存储着目标信息的节点。在有着大量节点(如100万个)的P2P系统中，任何节点都不可能拥 有全部的节点?键值?内容的对应关系；因此用户获得了键值之后，如何找到该键值对应的节点就被称为DHT的路由问题。DHT协议必须定义优化的查找(路 由)算法来完成这一搜寻的工作。不同的DHT协议之间区别很大程度上就在于定义了不同的路由算法。

DHT的应用非常简洁—-API简单到只有一项输入和一项输出：

应用层将数据对象(文件、数据块或索引)通过哈希算法获得键值，将该键值提交给DHT后，返回结果就是键值所在节点的IP地址。图1(来自[9])显示了这种应用结构：

图 1 DHT的应用结构

在这样的支持下，可以开发多种P2P的应用程序，如网络存储与文件共享、即时消息、音频/视频等。图2(来自[9])显示了这种应用结构：

图 2 DHT应用的层次

主流DHT协议

缓冲阵列路由协议(CARP，Cache Array Routing Protocol)

协议简介

CARP 是由微软公司的Vinod Valloppillil和宾西法尼亚大学的Keith W. Ross在1997年提出的。该协议可以将URL空间映射到一个仅有松散关联关系的Web cache 服务器(在协议中称为“代理”，Proxy)阵列中。支持该协议的HTTP客户端可以根据要访问的URL智能选择目标代理。该协议解决了在代理阵列内分布 存储内容的问题，避免了内容的重复存储，提高了客户端访问时Web Cache命中的概率。

哈希算法

哈 希使用的关键字有2个，一个是代理的标识符(每个代理均有唯一的标识)，另一个是URL本身。存储内容时，每个代理负责缓冲哈希键值最大的URL。这样， 当缓冲代理阵列发生少量变化时(新的代理加入或旧的代理退出)，原有的URL还有可能仍然被映射到原来的代理上，仍可以按照原有的方式访问。

路由算法

客户端(HTTP浏览器)首先加载一个代理配置文件，该文件中存储了代理的标识符和IP地址等用于哈希的关键参数。浏览器在访问网页时，可以根据URL和代理标识获得代理的位置信息(IP地址)，从而可以直接访问缓冲代理中的页面。

讨论

CARP的哈希过程比较简单，路由查找更是简单到至多只有一跳(O(1))。但是CARP在P2P的应用环境中有一些致命的缺陷：

每个节点必须知道其它所有节点的信息。在大规模的重叠网环境中，由于可能存在大量的(数百万)节点，加之节点都是动态加入和退出网络，因此这一条件几乎不可能满足。

在缓冲阵列发生较大变化时(这在P2P网络中非常常见)，原有的URL和代理之间的对应关系可能发生改变，从而使得原有的配置文件失效。

一致性哈希(Consistent Hash)

协议简介

一致性哈希算法在1997年由麻省理工学院提出(参见0)，设计目标是为了解决因特网中的热点(Hot pot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。

哈希算法

一致性哈希提出了在动态变化的Cache环境中，哈希算法应该满足的4个适应条件：

平衡性(Balance)

平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。

单调性(Monotonicity)

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。

简单的哈希算法往往不能满足单调性的要求，如最简单的线性哈希：

x → ax + b mod (P)

在上式中，P表示全部缓冲的大小。不难看出，当缓冲大小发生变化时(从P1到P2)，原来所有的哈希结果均会发生变化，从而不满足单调性的要求。

哈希结果的变化意味着当缓冲空间发生变化时，所有的映射关系需要在系统内全部更新。而在P2P系统内，缓冲的变化等价于Peer加入或退出系统，这一情况在P2P系统中会频繁发生，因此会带来极大计算和传输负荷。单调性就是要求哈希算法能够避免这一情况的发生。

分散性(Spread)

在 分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能 不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同 缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。

负载(Load)

负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

从表面上看，一致性哈希针对的是分布式缓冲的问题，但是如果将缓冲看作P2P系统中的Peer，将映射的内容看作各种共享的资源(数据，文件，媒体流等)，就会发现两者实际上是在描述同一问题。

路由算法

在 一致性哈希算法中，每个节点(对应P2P系统中的Peer)都有随机分配的ID。在将内容映射到节点时，使用内容的关键字和节点的ID进行一致性哈希运算 并获得键值。一致性哈希要求键值和节点ID处于同一值域。最简单的键值和ID可以是一维的，比如从0000到9999的整数集合。

根据键值存储内容时，内容将被存储到具有与其键值最接近的ID的节点上。例如键值为1001的内容，系统中有ID为1000，1010，1100的节点，该内容将被映射到1000节点。

为 了构建查询所需的路由，一致性哈希要求每个节点存储其上行节点(ID值大于自身的节点中最小的)和下行节点(ID值小于自身的节点中最大的)的位置信息 (IP地址)。当节点需要查找内容时，就可以根据内容的键值决定向上行或下行节点发起查询请求。收到查询请求的节点如果发现自己拥有被请求的目标，可以直 接向发起查询请求的节点返回确认；如果发现不属于自身的范围，可以转发请求到自己的上行/下行节点。

为 了维护上述路由信息，在节点加入/退出系统时，相邻的节点必须及时更新路由信息。这就要求节点不仅存储直接相连的下行节点位置信息，还要知道一定深度(n 跳)的间接下行节点信息，并且动态地维护节点列表。当节点退出系统时，它的上行节点将尝试直接连接到最近的下行节点，连接成功后，从新的下行节点获得下行 节点列表并更新自身的节点列表。同样的，当新的节点加入到系统中时，首先根据自身的ID找到下行节点并获得下行节点列表，然后要求上行节点修改其下行节点 列表，这样就恢复了路由关系。

讨论

一致性哈希基本解决了在P2P环境中最为关键的问题——如何在动态的网络拓扑中分布存储和路由。每个节点仅需维护少量相邻节点的信息，并且在节点加入/退出系统时，仅有相关的少量节点参与到拓扑的维护中。所有这一切使得一致性哈希成为第一个实用的DHT算法。

但 是一致性哈希的路由算法尚有不足之处。在查询过程中，查询消息要经过O(N)步(O(N)表示与N成正比关系，N系统内的节点总数) 才能到达被查询的节点。不难想象，当系统规模非常大时，节点数量可能超过百万，这样的查询效率显然难以满足使用的需要。换个角度来看，即使用户能够忍受漫 长的时延，查询过程中产生的大量消息也会给网络带来不必要的负荷。

下文中讨论的几种DHT协议都对路由做出了优化，提出了各自的算法。

Chord协议

Chord 在2001年由麻省理工学院提出(参见0)，其核心就是要解决在P2P应用中遇到的基本问题：如何在P2P网络中找到存有特定数据的节点。与前两种协 议不同，Chord专门为P2P应用设计，因此考虑了在P2P应用中可能遇到的特殊问题，这些内容将在路由的部分进行讨论。

哈希算法

Chord使用一致性哈希作为哈希算法。在一致性哈希协议中并没有定义具体的算法，在Chord协议中将其规定为SHA-1。

路由算法

Chord在一致性哈希的基础上提供了优化的路由算法：

在 Chord中，每个节点同样需要存储m个其他节点的信息，这些信息的集合被称为查询表(Finger Table)。一致性哈希中的节点同样具有这样的表格，但在Chord中，表格中的节点不再是直接相邻的节点，它们的间距(ID间隔)将成2i 的关系排列(i 表示表中的数组下标)。这样形成的节点之间路由关系实际上就是折半查找算法需要的排列关系。

在 查询的过程中，查询节点将请求发送到与键值最接近的节点上。收到查询请求的节点如果发现自身存储了被查询的信息，可以直接回应查询节点 (这与一致性哈希完全相同)；如果被查询的信息不在本地，就根据查询表将请求转发到与键值最接近的节点上。这样的过程一直持续到找到相应的节点为止。不难 看出，查询过程实际上就是折半查找的过程。

经过Chord的优化后，查询需要的跳数由O ( N)减少到O(log(N))。这样即使在大规模的P2P网络中(例如N＝100,000,000)，查询的跳数也仅为O(8)，每个节点仅需存储27个(log2100000000)其他节点的信息。

Chord还考虑到多个节点同时加入系统的情况并对节点加入/退出算法作了优化。

讨论

Chord算法本身具有如下优点：

负载平衡

这一优点来自于一致性哈希，也就是一致性哈希中提到的平衡性。所有的节点以同等的概率分担系统负荷，从而可以避免某些节点负载过大的情况。

分布性

Chord是纯分布式系统，节点之间完全平等并完成同样的工作。这使得Chord具有很高的鲁棒性，可以抵御DoS攻击。

可扩展性

Chord协议的开销随着系统规模(结点总数N)的增加而按照O(logN)的比例增加。因此Chord可以用于大规模的系统。

可用性

Chord协议要求节点根据网络的变化动态的更新查询表，因此能够及时恢复路由关系，使得查询可以可靠地进行。

命名的灵活性

Chord并未限制查询内容的结构，因此应用层可以灵活的将内容映射到键值空间而不受协议的限制。

Chord在CFS系统中得到了应用，具体的介绍可参见[8]

内容寻址网络(Content-Addressable Network，CAN)

CAN在2001年由加州大学伯克利分校提出(参见[3])。与Chord一样，CAN也是DHT的一个变种。

哈希算法

CAN的哈希算法与一致性哈希有所不同。Chord中，哈希得到的键值总是一维的，而在CAN中，哈希的结果由d维的笛卡尔空间来表示。d是一个由系统规模决定的常量。

路由算法

CAN的路由查询将在d维笛卡尔空间中进行。

在 CAN中，每个节点自身的ID经由哈希后得到的d维向量。经过这样的映射后，整个P2P系统将被映射到一个d维笛卡尔空间中，每个节点的位置由其自身ID 决定。CAN对邻居节点的定义并不要求成2i的关系排列，而是改为用在笛卡尔空间上相邻来表示：在d维笛卡尔空间中，2个节点的d维坐标中有d-1维是相 等的，剩余的一维是相邻的节点称之为相邻节点。

CAN中的节点仅存储相邻节点表。由于在d维的空间中最多有2d个相邻的节点，因此节点的相邻节点表最多有2d个表项。

在 查询的过程中，查询节点首先计算被查询内容的键值(d维向量)，然后在节点列表中查找在笛卡尔空间中与该键值最为接近的相邻节点，找到后向该节点发送查询 请求(这一策略被称为贪婪策略)。查询请求中将携带被查询内容的键值。收到查询请求的节点如果发现自身存储了被查询的信息，可以直接回应查询节点(这与一 致性哈希完全相同)；如果被查询的信息不在本地，就根据相邻节点表将请求转发到与键值最接近的节点上。这样的过程一直持续到找到相应的节点为止。在查询过 程中，被查询节点到目标节点的笛卡尔空间距离单调地减少。

如果查询节点或转发节点发现邻居节点表中无法找到可用的下一跳节点，则采用非结构化P2P常用的扩展环搜索(Expanding Ring Search，使用无状态，受控的泛洪算法在重叠网中搜索)以找到合适的(符合贪婪策略)下一节点。

经过CAN的优化后，查询需要的跳数由O ( N)减少到均值为(d/4)(n1/d)的随机制，考虑到d为常数，这一值可以表示为O(n1/d)或O(dn1/d)。

讨论

CAN 和Chord的主要区别在于路由算法不同。相比之下，在节点数量非常大时，CAN的平均查询跳数要比Chord增加得更快。而且 CAN查询过程中需要的运算量也要高于Chord。但CAN使用的d为预先设置的常量，因此并不假设系统节点数量。在节点总数动态变化范围很大的系统中， CAN的相邻节点表结构保持稳定，这在P2P的应用中也是很重要的优点。

Pastry

Pastry在2001年由位于英国剑桥的微软研究院和莱斯(Rice)大学提出(参见[4])。Pastry也是DHT的一个变种。

哈希算法

Pastry使用一致性哈希作为哈希算法。哈希所得的键值为一维(实际上使用的是128bit的整数空间)。Pastry也没有规定具体应该采用何种哈希算法。

路由算法

在Pastry协议中，每个节点都拥有一个128bit的标识(Node Id)。为了保证Node ID的唯一性，一般由节点的网络标识(如IP地址)经过哈希得到。

Pastry中的每个节点拥有一个路由表R(Routing table)，一个邻居节点集M(Neighborhood Set)和一个叶子节点集合L(Leaf set)，它们一起构成了节点的状态表。

路 由表R共有logBN(B = 2b为系统参数，典型值为16，N表示系统的节点总数)行，每行包括B-1个表项，每个表项记录了一个邻居节点的信息(节点标识、IP地址、当前状态 等)。这样就形成了拥有(B-1)logBN个条目的二维表格。路由表第n行的表项所记录的邻居节点的Node ID前n个数位和当前节点的前n个数位相同，而第n＋1个数位则分别取从0到B-1的值(除了与当前节点第n＋1数位的值)。这样形成的路由表很类似IP 路由中最长掩码匹配的算法。参数b(或B)大小非常关键：B过大则节点需要维护很大的路由表，可能超出节点的负载能力，但路由表大些可以存储更多的邻居节 点，在转发时更为精确。平均每次路由查找需要的跳数在Pastry中计算的结果是logBN，因此B的选择反映了路由表大小和路由效率之间的折衷。

叶子节点集合L中存放的是在键值空间中与当前节点距离最近的|L|个节点的信息，其中一半节点标识大于当前节点，另一半节点标识小于当前节点。|L|的典型值为2b或者2*2b。

邻 居节点集合M中存放的是在真实网络中与当前节点“距离”最近的|M|个节点的信息。“距离”的定义在Pastry中非常类似IP路由协议中对距离的定义， 也就是考虑到转发跳数、传输路径带宽、QoS等综合因素后所得的转发开销(可以参见OSPF等路由协议)。Pastry并未提供距离信息的获取方法，而是 假设应用层可以通过某种手段(人工配制或自动协商)得到信息并配置邻居节点集合。|M|的典型值为2b或者2*2b。

图 3给出了一个Pastry节点状态表的例子，该图来源于[4]。

在节点状态表中，节点本身的ID为10233102。叶子集合中有8项，每一项都一个当前节点已知的其他节点的信息。路由表共有4*8项，可以看出由上至下节点ID重合的位数(前缀)不断增加。邻居集合中的节点ID由于来源于应用层，一般没有规律性可循。

Pastry的路由过程如下：

首 先，路由查询消息中将携带被查询对象ID(Object Id)，又称消息键值。当收到路由消息时，节点首先检查消息键值是否落在叶子节点集合的范围内。如果是，则直接把消息转发给叶子节点集合中节点标识和消息 键值最接近的节点；否则就从路由表中根据最长前缀优先的原则选择一个节点作为路由目标，转发路由消息。如果不存在这样的节点，当前节点将会从其维护的所有 邻居节点集合(包括路由表叶子集合及邻居集合中的节点)中选择一个距离消息键值最近的节点作为转发目标。

从上述过程中可以看出，每一步路由和上一步相比都更靠近目标节点，因此这个过程是收敛的。如果路由表不为空，每步路由至少能够增加一个前缀匹配数位，因此在路由表始终有效时，路由的步数至多为logBN。

讨论

Pastry的路由利用了成熟的最大掩码匹配算法，因此实现时可以利用很多现成的软件算法和硬件框架，可以获得很好的效率。

与Chord和CAN相比，Pastry引入了叶子节点和邻居节点集合的概念。在应用层能够及时准确地获得这两个集合的节点信息时，可以大大加快路由查找的速度，同时降低因路由引起的网络传输开销；不过在动态变化的P2P网络中如何理想地做到这一点的确有很大的难度。

Pastry的典型应用包括PAST(参见[5][6])和SCRIBE(参见[7])。

趋势分析

目前DHT算法的发展方向非常多，不断有新的改进算法被提出来。就笔者目前了解到的信息而言，至少有以下一些方向：

接近性(Proximity)

文中提到的DHT算法中，除了Pasrty以外，均未考虑重叠网络拓扑结构与真实的IP网络之间的重合关系。节点之间进行对等通信时，不会考虑优先选取距离自己最近的节点。这样就使得最终形成的重叠网结构混乱，效率低下。因此如何让节点获得并利用接近性信息就非常重要。

结构化

目 前基于DHT的应用尚未大规模展开，很多工程上的细节问题尚待解决。例如：目前有很多种类的P2P应用，如文件存储和共享、电子邮件、流媒体等。这些应用 在处理P2P路由算法、拓扑维护和信息检索上使用的方法均有很大差别，导致即使是同类的应用也无法实现互通。如何为各种P2P的应用抽象出一个通用的层 次，也是目前研究的热点问题之一。

信息查询

基于分布式哈希表的查询是一种单关键字的精确匹配，尽管相对于非结构化系统它使得系统资源可被确定性地查询到，但它也极大地限制了查询的应用范围。目前有许多改进的结构化查询算法已经被提出来。

参考文献

David Karger, Eric Lehman, Tom Leighton, Matthew Levine, Daniel Lewin, Rina Panigrahy “Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”. In Proceedings of the 29th Annual ACM Sym-posium on Theory of Computing (El Paso, TX, May 1997), pp. 654-663.

Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan_ “Chord: A Scalable Peertopeer Lookup Service for Internet Applications” SIGCOMM’01, August 2731, 2001, San Diego, California, USA.

Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, Scott Shenker “A Scalable Content-Addressable Network” SIGCOMM’01, August 27-31, 2001, San Diego, California, USA..

Antony Rowstron1 and Peter Druschel “Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems” Appears in Proc. of the 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001). Heidelberg, Germany, November 2001.

P. Druschel and A. Rowstron. PAST: A large-scale, persistent peer-to-peer storage utility. In Proc. HotOS VIII, Schloss Elmau, Germany, May 2001.

A. Rowstron and P. Druschel. Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility. In Proc. ACM SOSP’01, Banff, Canada, Oct. 2001.

A. Rowstron, A.-M. Kermarrec, P. Druschel, and M. Castro. Scribe: The design of a large-scale event notification infrastructure. Submitted for publication. June 2001. http://www.research.microsoft.com/ antr/SCRIBE/.

F. Dabek, M. F. Kaashoek, D. Karger, R. Morris, and I. Stoica. Wide-area cooperative storage with CFS. In Proc. ACM SOSP’01, Banff, Canada, Oct. 2001.

Keith W. Ross, Dan Rubenstein, “P2P Systems”

宁 宁，“对等网络组通信机制的位置感知技术研究Research on Location-Aware Tech-nology in Peer-to-Peer Group Com-munication Mechanism”，申请清华大学工学硕士学位论文，May.2005.

李祖鹏，建华，唐辉，“基于P2P计算模式的自组织网络路由模型”，软件学报，1000-9825/2005/16(05)0916

胡进锋，郑纬民(清华大学计算机系高性能计算研究所，，100084)，“p2p系统结点信息收集算法 Node Collection Protocol in P2P Systems”

邹 福泰，马范援(上海交通大学计算机科学与工程系)，“基于分布式哈希表的对等系统关键技术研究RESEARCH ON THE KEY TECHNIQUE OF PEER-TO-PEER SYSTEMS BASED ON DISTRIBUTED HASH TABLE”，申请上海交通大学博士学位论文，二零零四年十一月

视频下载中...

[ 文章作者：陈臻 本文版本：v1.0 最后修改：2009.8.2 转载请注明原文链接：http://www.54chen.com/688-wordpress-nginx-php-cgi-mysql-memory-in-the-128m-to-install-and-optimize-the-vps-notes/ ]

选取CentOS，因为它是号称最安全及性能都相对较好的Linux系统。系统内存128m，系统用掉30m，有100m左右可用（如图1所示），swap已经有256M，硬盘为5G，除去系统后大约有4G可供捣腾。

图1。

首先，在空白的系统上使用下面的命令，安装gcc等一堆工具和后面php会用到的一些包：

yum -y install gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers

yum这一堆东西会有点慢，这里正好插播一下，mysql的编译在128的内存下非常慢，所以呆会儿我们会采取直接yum，php、nginx都下源码编译，经过以往的经验eAccelerator、Xcache和Zend Optimizer这三者，最好是用eAccelerator搭配Zend Optimizer能给php加速得到最佳效果，当然了，Zend Optimizer需要Zend Guard来搭配，而后者是收费的，伟大的人有伟大的破解。

我执行的时候耗时32分钟左右。

言归正传，继续： wget http://sysoev.ru/nginx/nginx-0.7.61.tar.gz
wget http://www.php.net/get/php-5.2.10.tar.gz/from/this/mirror
wget http://blog.s135.com/soft/linux/nginx_php/phpfpm/php-5.2.10-fpm-0.5.11.diff.gz
wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.9.tar.gz [nginx rewrite使用]

【安装MySQL】 yum install -y mysql-server
启动MySQL:
service mysqld start
设置mysql数据库root帐号密码:
mysqladmin -u root password 'newpassword' [引号内填密码]
让mysql更安全：
mysql -u root -p [此时会要求你输入刚刚设置的密码，输入后回车即可]

mysql> DROP DATABASE test; [删除test数据库]
mysql> DELETE FROM mysql.user WHERE user = ''; [删除匿名帐户]
mysql>DELETE FROM mysql.user WHERE password = '';[删除无密码帐户]
mysql> FLUSH PRIVILEGES; [重载权限]

【优化MySQL】
此时的mysql直接吃掉20m左右的内存，如图2所示。我们要对其进行优化，关掉innodb。

图2。

vi /etc/my.cnf
在后面增加如下内容：

skip-innodb
[mysql]
no-auto-rehash

[mysqld]
user = mysql
port = 3306
open_files_limit = 600
back_log = 20
max_connections = 100
max_connect_errors = 200
table_cache = 60
external-locking = FALSE
max_allowed_packet = 16M
sort_buffer_size = 128K
join_buffer_size = 128K
thread_cache_size = 10
thread_concurrency = 8
query_cache_size = 0M
query_cache_limit = 2M
query_cache_min_res_unit = 2k
default_table_type = MyISAM
thread_stack = 192K
transaction_isolation = READ-UNCOMMITTED
tmp_table_size = 512K
max_heap_table_size = 32M
long_query_time = 1
log_long_format
server-id = 1
binlog_cache_size = 2M
max_binlog_cache_size = 4M
max_binlog_size = 512M
expire_logs_days = 7
key_buffer_size = 4M
read_buffer_size = 1M
read_rnd_buffer_size = 2M
bulk_insert_buffer_size = 2M
myisam_sort_buffer_size = 4M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover

[mysqldump]
quick
max_allowed_packet = 16M

【重启MySQL】
service mysqld restart
再看mysql吃掉的内存，已经降低了四分之一，如图3所示： 图3。

【安装php】
首先使用yum安装上mysql的开发包，供php扩展mysql使用： yum -y install mysql-devel
安装patch工具：
yum -y install patch
tar zxvf php-5.2.10.tar.gz
gzip -cd php-5.2.10-fpm-0.5.11.diff.gz | patch -d php-5.2.10 -p1
cd php-5.2.10
./configure --prefix=/opt/php --with-config-file-path=/opt/php/etc --with-mysql=/usr/share/mysql --with-mysqli=/usr/bin/mysql_config --with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir --with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml --disable-rpath --enable-discard-path --enable-safe-mode --enable-bcmath --enable-shmop --enable-sysvsem --enable-inline-optimization --with-curl --with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm --enable-force-cgi-redirect --enable-mbstring --with-gd --enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets --with-ldap --with-ldap-sasl --without-pear
make && make install 把pear手动装上(这个是5.2.10的一个bug，后面可能已经打补丁了)：
curl http://pear.php.net/go-pear | /opt/php/bin/php
cp php.ini-dist /opt/php/etc/php.ini

【安装eaccelerator】 tar jxvf eaccelerator-0.9.5.3.tar.bz2
cd eaccelerator-0.9.5.3
/opt/php/bin/phpize
./configure --enable-eaccelerator=shared --with-php-config=/opt/php/bin/php-config
make && make install mkdir -p /opt/eaccelerator_cache
vi /opt/php/etc/php.ini

添加下面的内容： [eaccelerator]
zend_extension="/usr/local/webserver/php/lib/php/extensions/no-debug-non-zts-20060613/eaccelerator.so"
eaccelerator.shm_size="64"
eaccelerator.cache_dir="/usr/local/webserver/eaccelerator_cache"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="3600"
eaccelerator.shm_prune_period="3600"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

【安装Zend Optimizer】
要去zend.com上注册用户名后进download页面下载，这里太弱智了，不知道zend是否有专门的产品人员，这种注册下载有什么意义，只是一堆死账号而已。
下载ZendOptimizer-3.3.3-linux-glibc23-i386.tar.gz tar -zxvf ZendOptimizer-3.3.3-linux-glibc23-i386.tar.gz
cd ZendOptimizer-3.3.3-linux-glibc23-i386
./install

运行过程中会要求你写些安装路径啥的，照着写就是。
如果出现类似下面的错误：
./install-tty: line 139: ./php: cannot execute binary file
那说明你下错了包了，这种情况是因为你32位的系统下了64位的包或者是反过来。

【安装nginx】 tar -zxvf pcre-7.9.tar.gz
cd pcre-7.9
./configure
make && make install
cd ..

tar zxvf nginx-0.7.61.tar.gz
cd nginx-0.7.61
./configure --user=www --group=www --prefix=/opt/nginx --with-http_stub_status_module --with-http_ssl_module
make && make install

增加www用户：
groupadd www
useradd -g www www

【优化php\nginx】
1.优化php-fpm.conf vi /opt/php/etc/php-fpm.conf
修改log level为error:
error
修改max_children:
5 修改listen_address为unix socket方式运行：
/tmp/php-cgi.sock

2.优化nginx.conf
vi /opt/nginx/conf/nginx.conf
在events中增加： use epoll;
在http中增加下面的代码，打开gzip：
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
在使用php的server中使用unix socket通信方式：
fastcgi_pass unix:/tmp/php-cgi.sock;

【设置开机启动】
/sbin/chkconfig --add mysqld [在服务清单中添加mysql服务]
/sbin/chkconfig mysqld on [设置mysql服务开机启动]

vi /etc/rc.locale
加入两行：
/opt/php/sbin/php-fpm start
/opt/nginx/sbin/nginx

【误区提示】
XEN更像物理服务器，会尽量把剩余的内存当成buffer和cache，所以看到下图的时候不要惊慌，其实内存都在cache里了。 图4

【wordpress专项优化】
使用wp-super-cache插件，将页面生成html，省去php的开销，性能有提升。
对照access log，刷新页面，看堵在什么地方

【几个建议】
合并css js个数 并且压缩 速度提升明显
wordpress没有任何插件的时候，效率是很不错的，但是有些不负责任的插件会导致整体看起来很慢，下面是一些常用的插件的问题：
1.weibo tools插件：用来从后端取weibo数据的，这个插件搞了一个js一个css在head里，并且都是通过php生成的，两个php请求，让首页很慢。建议去掉（可能会影响自动化？没来得及分析细节）。
2.wp-spamfree插件：用来做antispam的，这是一个动态生成的js，不知道为什么非常慢。建议换别的插件。

【结果展示】
在完成上述一系列的作后，https://www.54chen.com 我是陈科学院的打开速度已经非常迅速了，基本上一秒钟就能全部显示。内存还有40m空闲，如图5所示： 图5