thinking in asp 之四 蝴蝶的翅膀和产品风暴

再说已经身处生产环境中的细节，最完美的例子是asp的子系统DQnet——有兴趣的同学可以参看《ASP技术白皮书》相关章节。

我更乐意把它的产生过程描述为：蝴蝶的翅膀所扇动起来的产品风暴。

DQnet的产生只是出于一个普通的考虑：

1.我们可以试试在源站的每台服务器上加上一个squid缓存，这样可能会降低后端的服务压力。

蝴蝶开始扇动翅膀。

2.运行了一段时间，统计的结果是，命中率10-15%左右。有效果，这样挺好。

3.用户量逐步增加，而且前端的CDN也经常抽抽风，玩儿把清缓存的把戏，源站有点儿吃不住劲。

4.命中率还是10-15%，有效果，但是不够好。

5.嗯，主要是磁盘利用率的问题。RoundRobin模式下，每台服务器都会缓存同样的内容。假如有10台服务器（1T存储/台），那么，缓存的内容只有1T。

 

专用吐槽格，可以跳过，不影响阅读。

我可以吐槽asp的机器五花八门，就跟抗美援朝时候志愿军用的步枪种类一样多么~ 10台硬件条件一致的服务器？ 幻觉，一定是幻觉——《少林足球》台词。

 

6.我们写了一个nginx模块，用来做调度，算法采用一致性哈希，现在，缓存空间从1T扩展到10T啦。命中率飙升到40%。有效果，这样挺好。

7.我们试图整合热点数据发现算法，实现一个主动推和被动拉的cache策略，并且完成了原型——这个上文有提到。

8.问题再次出现，这个模块没有考虑failover，而且平白在服务器上多部署了一个服务，维护起来麻烦太大。

9.改吧，首先把一致性哈希内嵌到squid中，减少了服务器运行的服务，降低了维护的工作量。

专用吐槽格，可以跳过，不影响阅读。

关于第9步，别问我刚开始为啥不这么干？ 伦家那时候不是只会改nginx么？ 再说了，这个开发工作本来就是突发的、没规划到的好不好？ 各位看官，asp就是这么一路连滚带爬过来D…… -_-b

 

10.继续解决failover的问题，嗯，貌似squid的neighborUp挺好用，改改直接用上吧。

11.每台机器的磁盘空间大小不一样，机柜的上联带宽不一样，怎么办？改，加上权重因子。

12.命中率还想高点儿。发现不同cdn回源请求的域名不一样，造成重复缓存。改，加上自定义的主键生成器。好了，到了50%了。

13.小运营商访问速度太慢，最好在某地A单独假设一个cache节点。DQnet上吧。

14.某地A的cache节点面向最终用户的302方式不能满足源站服务，因为源站的用户是cdn，它们不会做跳转抓取。为了中心和边缘节点程序代码的通用性，继续改，取消302，通过内网proxy形式走数据。

15.老化策略貌似不适应我们服务的特点，继续改，加入主动老化策略。命中率再增加5个百分点。

16.某地B节点部署，x台服务器合xT硬盘存储空间，达到了平均80%的命中率，加上源站的中心节点命中率50%，合计回源率在10%以下。不考虑总的访问量和存储空间限制——这个我无法拿到数据，所以也无从评估，只能单单从数值比较，DQnet已经相当接近商业cdn系统的性能（商业cdn回源率在x%左右）。

 

蝴蝶在忽闪了16下翅膀之后，在地球的某个角落，热带风暴开始形成，而在部署完某地Bcache节点我才意识到这个风暴的存在——我们实际上已经完成了一个类似于商业CDN的cache体系。

 

当时的一些思路可以参见本博文《自有CDN的研发和建设》

当然，我们的初衷跟现有的状态还是有点儿出入，这又是一个chaos，开始我们想解决一个简单的问题，然后，我们试图提高命中率，然后我们规划了一个类似于facebook的haystack体系，然后，我们得到的是一个CDN原型。

专用吐槽格，可以跳过，不影响阅读。

对于haystack的设计，由于只是一个先期规划，所以并未写入以上的发展历程，对haystack有兴趣的同学，可以咨询投入了不少精力做预研的小翟同学。 也可以自行下载《Finding a needle in Haystack: Facebook’s photo storage》阅读。