网站加速动态应用篇 节约10倍以上的成本

MC池子层：

每个IDC内部的多个MC机是作为一个整体来管理的，也就是说，假如你有100个数据，4个MC机，那么每个MC上只会存25个数据，而不会每个都存100个。好处是，获得了相当于以前4倍的内存池， 增大了缓存命中率。更额外的好处是，减少了，本IDC内部各MC间数据同步的时间开销，使得本IDC任何一服务器更新的数据，同IDC内其他服务器立即可见。也使得IDC之间MC的同步更为节约，每个IDC一个池子，每个池子只需要写一份数据。

MC池子增减机器的问题：如果是传统的hash算法根据key值，将数据平均的hash到4台机器上，那么按照新的hash规则，增加一台机器后，将会有近80%的缓存失效，造成大量数据迁移。所以我们改用Consistent Hashing，首先求出memcached服务器（节点）的哈希值，并将其配置到0～2的32次方的圆上。然后用同样的方法求出存储数据的键的哈希值，并映射到圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2的32次方仍然找不到服务器，就会保存到第一台memcached服务器上。它能最大限度地抑制键的重新分布。而且，有的实现还采用了虚拟节点的思想，使得分布更加均匀。由服务器台数（m）和增加的服务器台数（n）计算增加服务器后的命中率计算公式如下：（1 - n/（n+m） ） * 100 ，按这个计算，增加一台机器后还将得到80%的命中率。更较幸运的是这个算法已经被php所支持，可以通过php.ini设置。

宕机重启后初始化的问题：如果初始化的数据只从一台DB上获得，那么在高峰期间必将压垮DB，所以，我们需要将这个压力，分散到本IDC的多台DB上。细节会在基础类库中进行讲述。

异地MC池子的数据同步：已经封装在基础类库中，更新MC时指定特定的参数，就会在其他异地MC池子上也进行更新。所以我们如果在北京添了一个数据，那么在深圳也会立刻看到。

DB层：

主从结构集群，主库可切换，从库互为备份。从DB宕掉一台，可以自动跳过，不影响服务，目前通过基础类库实现，以后会采用内部DNS。所有从库直接和主库相连，结构简单，方便管理。不过写的数据量相对比较小的，而且我们允许DB延迟（由MC来保证实时性，或者异地本来就可以接受短暂的延迟），这里将不是问题。

MC和DB写队列：

在专线中断时不影响写操作（读都是本地的，当然也不受影响），而且在更新数据时能够快速返回（因为不需要远程通信）。

具体来说就是将MC的异地写，以及DB的写操作封装成直接追加写本地队列文件。每个机器上有个守护进程，每0.1秒检查一次，有则rename，然后开始将队列数据逐条往深圳数据中心post，同时每成功一条记录当前offset，以便意外宕掉后接着上次的后面处理。（优化点的可以改为批量确认，冒进点的，可以使用内存盘优化写速度）。如果线路不通，或者数据中心写失败，post程序将sleep and retry，线路恢复则继续，不会丢数据。这里有个细节需要注意，就是往数据中心同步的时候，尽量发往同一台机器，也即绑定，以保证序列的顺序，这个保证可以通过对post守护进程的pid取mod来实现，如果绑定的机器出了故障，则应该选定另外一台机器绑定，一旦检测到以前的机器好了，则应该切回来，以保证应有的负载均衡。另外，最外层的接入端也同样需要注意这个问题，我们对lvs做了会话保持，以确保同一用户在相当长的一段时间内，会访问到同一台机器。对于仅仅使用DNS轮询，又没有使用长连接的服务，如果在短时间内做数据更新，肯定会出现乱序的问题。除非你各服务器时间都很精准，而且，每个记录写的时候打上精确到ms的时间戳。

然后，深圳数据中心接收到post的数据后，根据消息类型按一定规则的命名分别存放，这样即使增加一种新的消息，也可以方便的使用队列。比如收到MC的消息后，要写三份，分别发往三个IDC，各自不受影响。DB，可以根据不同的port实例子来创建队列，免得有一个port宕了，影响其他。具体实现细节可以自己调整，同样得有个程序定期（比如每0.1秒，0.01秒也无所谓，对cpu的消耗非常小）检查队列文件存在就rename，然后往master里写。

以上则能保证，DB的master宕掉，或者专线的中断情况下，用户服务基本不受影响，只是异地的同步会延迟一些。额外收获是将来做DB升级调整的时候，可以用队列分流，分别做不同的处理。

祛除安全隐患：

不管你的系统设计的多么完美，疏忽这一条足以致命。

以上设计看起来似乎已经没什么问题了，各种容灾，异常也基本考虑到了，不幸的是，这个平台并不是仅仅给设计者自己使用，如果有个新手使用了 file_get_contents（$url）; 如果url所依赖的服务器负载过重，那么整个系统都有被拖垮的危险。动态应用的一个铁律就是，凡是依赖本系统外部资源的地方必须加超时限制，尽可能的减少依赖。file_get_contents的超时不是很精确，推荐使用curl的库进行封装，可以设置connect超时，也可以设置整个函数的执行时间超时。我一般会设置my_curl（）;函数的最大默认执行时间为一秒，因为是从内网拉取数据，一秒还拉不到，肯定有问题。另外，别忘记了mysql读服务，当某一idc的一台slave连接数满了以后，如果没设置过mysql.connect_timeout=1;那这个IDC的服务会整个被拖垮，因为默认的是60秒。（mysql的写由队列保证，不存在此问题）。

另外，我们项目还有个特殊性，即，每次拉取用户股票信息时，需要从后台专线到深圳进行身份合法性验证，由于历史的原因，这个验证系统暂不具备多IDC分别的能力。假设北京的专线断了，虽然用户的数据是没问题，但是验证却通不过，会导致获取数据失败。同样这个验证是要加超时的，另外为了在专线断掉的情况下依然正常提供服务，就需要在得不到验证的情况下，要通过代理的手段到邻近的IDC去验证。同时，我们也支持另外一种验证方式，对于已经通过验证的用户，专线中断一小段时间，比如一小时，服务是可以不受影响。

总之就是尽量低偶合，少依赖，加超时。另外一个维护的安全，则由安全中心把关，我就不多说了。