- ！！！用户新注册邮件系统遭恶意攻击，暂不能发送邮件，请隔天尝试。寻求解决方案中
- 【征集】西西河的经济学，及清流措施，需要主动参与者
- 『稷下学宫』新认证方式
- 24年网站打算和努力目标
主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊
家园 这篇文章不错！ 赚钱的geek！
家园 哦也，说来就来了， 我这几天有点分神。物联网那个插播需要结束，Twitter只刨了一个小坑，下周接着刨。
先花。周末时，仔细读读，猛烈拍砖。
家园 哈哈，欢迎欢迎 就等着砖呢，这两天写着写着有点迷茫，好像太蜻蜓点水了，再往细节写，又不知道怎么写，要不就成了抄配置文件了，抓紧砖，要大大的砖。
嘿嘿，我也有插播哦。。。
- 复 哈哈，欢迎欢迎
家园 细节处理 写得太细显得罗嗦，写得太粗显得草率。
我也时时遇到类似问题。没有好办法。
回想起来，最终决定是粗还是细的，恐怕是写的时候的状态，如果忙，就粗，如果闲，就细。
。。。
打住，看样子，不是在交流经验吧。
- 复 哈哈，欢迎欢迎
家园 好文章，一点小建议 可能先拟个提纲比较好，要么重点架构，要么专注一些亮点和细节，要么点面结合但有所侧重，各有各的写法。
现在看起来是个巨坑，都２章了，还在门口dns转呢，不过反正我有耐心，在坑里等，就是不出来
家园 【原创】wikipedia架构学习笔记（二）路标 wikipedia有多少台服务器？上回小羊数了，357台，多少台放在前端接受用户访问请求？没数，谁爱数谁自己数去，人不能太八卦，呵呵，不过肯定不少于100台了，分别组成N个cluster，放置在好几个机房，上次贴了一个wikipedia架构图，相信那个写实风格的架构图，不是小羊一个人晕菜——这TMD简直就是一片服务器的丛林阿。但是，对于用户来说，就算它有百万台server、八百个cluster都不关我事儿，用户只管输入www.wikipedia.org，那么用户访问的时候，指向的是哪里？访问的是哪一个IP？
我们跟着感觉走一回，设想两台服务器，一台就在你们家隔壁，一台在地球的另一端，两台服务器都能够提供你需要的服务，你访问哪一台？
恭喜你，答对了，当然是离你最近的那一台，而且wikipedia就是这么干的。
用户首先遇到的就是wikipedia玩儿的第一个花样——DNS解析
DNS我们都知道是个什么东西——当我们在browser地址栏输入西西河的地址的时候，我们真正要去的，其实不是ccthere.com，而是寂寞。。。不对不对，乱了乱了呵呵，而是205.209.175.100这个ip地址，ip地址才是ipv4网络的根本，browser就是从DNS服务器那里获得了205.209.175.100这个地址，才能把我们扔到河里来的。其实中间还有一步，就是把ccthere.com变成ccthere.com. 看到区别了？（没看到的跟我来——为革命，保护视力，眼保健操，现在开始。）从难记的ip地址，到好记的域名，再到会自动补齐那个小圆点，技术，就是在人类贪得无厌的偷懒欲望中进步嘀。
知道了网站的IP地址，实际上还没有开始访问网站呢，这个时候，wikipedia的花样就已经开始玩儿了。以查询 zh.wikipedia.org 为例：
首先客户端发送查询报文"query zh.wikipedia.org"至DNS服务器，DNS服务器首先检查自身缓存，如果存在记录则直接返回结果。如果记录老化或不存在：
1.DNS服务器向根域名服务器发送查询报文"query zh.wikipedia.org"，根域名服务器返回 .org 域的权威域名服务器地址。
2.DNS服务器向 .org 域的权威域名服务器发送查询报文"query zh.wikipedia.org"，得到 .wikipedia.org 域的权威域名服务器地址。
3.DNS服务器向 .wikipedia.org 域的权威域名服务器发送查询报文"query zh.wikipedia.org"，得到主机 zh 的A记录，存入自身缓存并返回给客户端。
花样就在第二步，看下图，我们实际查询的结果
外链图片需谨慎，可能会被源头改分析一下：A记录的TTL很短，Ns记录地址类型是IN，也就是说，一般情况下，我们本地的DNS服务器不管怎么设置，因为TTL时间实在太短了，本地设置的DNS服务器缓存中 wikipedia.org这个域的解析基本都会从第五列的那三台域名解析服务器获得最新的结果。
wikipedia在他自己的DNS服务器上做了手脚，添加了地理信息设置，这个就是架构图当中所谓GeoDNS。
外链图片需谨慎，可能会被源头改这样一来，整个流程就清晰了，我们访问wikipedia.org，从我们指向的DNS服务器中获取的就是离我们最近的wikipedia服务器IP地址，然后这个地址就被存放到本地缓存中直到我们手工flush或者过期，从而在地域上先对服务器做了一次基于DNS的负载均衡。
小平说：电脑要从娃娃抓起
wikipedia说：提高网站性能要从用户端抓起
其实写到这里，有个疑问：
首先，首尔yahoo机房提供的服务器离线之后，wikipedia现在的机房只有两处，在这种情况下，GeoDNS基于地理信息对于用户的引导，不能说没有用，至少在wikipedia强悍的处理能力和足够的带宽面前，用处不大了；
其次、wikipedia的内容庞大是毫无疑问的，但是其内容却并非对于全部用户均有价值，而是根据语种的分别对用户有价值，语种的分别又天然的和地理信息有关系；
那么，我们可以想象一下：
1、为德语区的用户访问提供服务的server cluster如果存储非德语资料，利用率一定是底下的
2、如果德语区的cluster无法提供用户需要的内容，那么它需要找到最近的服务器获取内容
再看看wikipeida自己的DNS技术说明，有这样一句话“Wikimedia use two separate kinds of DNS servers, authoritative nameservers (that respond to queries from third party nameservers for our domains) and resolvers (that resolve DNS queries for our own servers) ”
我们有理由怀疑GeoDNS对于wikipedia最重要的用处应该在于内容的分布、存储和读取方面。
真的么？
参考：
家园 物理位置近有时候不一定快 主要原因有网络因素，包括带宽、流量限制，错误的路由设置；也有服务器端的因素，如CPU，queue,I/O等。
对此google专门开发了一个工具whyhigh用于诊断这类网络迟延。
http://research.google.com/pubs/pub35590.html
家园 太好了 关于地理位置的说法，老哥您说的是对的，我感觉wikipedia综合考虑这些因素更新DNS应该问题不大，但是似乎有几个原因他们没有做:
1、wikipedia接受用户访问的ip不多，但每个ip后头都是一堆堆的server，如果根据带宽，服务器忙闲这些因素，就必须综合这些IP后面cluster的状况，比起现在40行代码实现的简单分配方法，可能略嫌麻烦了
2、负载均衡的方法很多，dns算是一种，按照忙闲分配段位更高，从适用环境来说，后者更适用于cluster中节点与节点之间，如果采用根据忙闲等因素更新dns的方法，必须面临的一个问题就是dns记录在用户端以及其他dns服务器上的缓存问题，尽管可以尽量的降低TTL，但肯定无法实时更新dns记录，这样一来，负载均衡的效果不会太好
所以如果第一步用户和几个接受访问的ip之间，采用复杂的负载均衡分配方法，效费比不好，这可能就是wikipedia没有采用的原因吧。
但是，在wikipeida的cluster当中，肯定负载均衡的方法要多很多花样。。。
另外：
给老哥送宝，我去研究一下google的那玩意儿去再说
家园 wikipedia是真正有益于人类未来的创新网站 具有知识共产主义原始萌芽的意义
