• Feeds

  • 中国共有多少台服务器-初略估算初窥

    自从看了《编程珠玑》第7章粗略估算之后就养成了一个奇怪的习惯,喜欢去计算身边的数字。比如一个城市共有多少台电梯,中国共有多少座桥梁等。

    粗略估算又叫费米近似(Fermi problem),比如坐广州到深圳的和谐号动车组时候就想,广深线每分钟进入火车站人流量有多大?这个似乎要请专业的调查公司才能得到结果,但实际上每个人几乎都可以算出来,尤其是程序员。

    1. 和谐号列车有8个车厢,1号和8号是头等车厢,一般坐不满 ,满员估算50人。除去5号餐车。因此共有5×100+100=600个座位。
    2. 15分钟一趟,每天从6点到22点,共发车18*(60/15)=72次
    3. 根据观察,广深线平时都有座位,但也不会太空。假如平均坐满70%座位的话,每天单向人流量为 72 * 600 * 70% = 30240 人
    4. 每分钟人流量为30240/18/60=28人
    5. 进一步考虑,需要几个售票窗口。估算平均每个乘客购票需要15秒,则至少7个窗口才不会引起排队现象。这跟平时观察一致,平时非高峰时刻如果窗口在5个以下会出现排长队现象。

    72法则

    72法则是会计上的一个经验。假设最初投资金额为100元,复息年利率9%(r%),利用“72法则”,将72除以9(增长率),得8(y),即需约8年时间,投资金额滚存至200元(两倍于100元),而准确需时为8.0432年。上面的r和y换成任何数字,只要相乘总数是72, 该法则都成立。

    72法则在初略估算中经常要用到,比如上面广深线的例子,假如客流月增长率3%, 则24月之后,广深线客流量会翻一番。(24*3=72)

    编程领域估算

    服务器编程领域经常面临预先估算,因为在程序开发前实际的场景并不存在。据去年《程序员》杂志介绍,奥运订票网站的瘫痪,是因为每秒请求数超过2200次。假如这个请求数都不能预先估算到的话,应该算是架构设计的失败。

    更多有趣例子及深入阅读

    • 中国共有多少台正在运行中的服务器?
    • 你有多少根头发?
    • 成年人体的骨头块数。
    • 孔子的出生年份(公元)

    更多有趣的例子可参看美国马里兰大学更多初略估算测试大全(英文)

    Google说,一个Datacenter就是一台计算机

    要实现一个典型的可扩展Web应用,有一大部分时间要花在Load balance, High availability, Consistent, Scalability等方面。这些都是有经验可循,但是通常无法简单重用。另外目前成熟的相关的部署经验都是孤立的,比如数据库,存储及文件系统,Web服务器都需要分别考虑。另外还有不少非核心的也经常需要用到,如cache, 全文检索, SSO、分布式计算如Hadoop等。所以大部分架构师的工作就是利用已有的经验,利用已有的硬件资源来对系统的负载进行一个平衡。

    由于这些组合技术含量并不是特别高,而且也无大的新技术来替代,所以大部分网站架构设计师的工作和10年前没什么区别,而且更糟糕的是,这些重复工作无法避免。新的一个应用,由于数据库表设计改了,所以所有的工作又得重来一次。因此是改变现状的时候了。

    最近,Google的Luiz André Barroso and Urs Hölzle写了一个paper, The Datacenter as a Computer – An Introduction to the Design of Warehouse-Scale Machines (PDF) 提出可以将一个Datacenter视为一台计算机。
    warehouse-scale-computer

    目前的操作系统在管理单机资源方面已经做到了相当完善,但还没有简单易用的软件体系将一Datacenter中的资源合理分配及利用,WSC也许是一个方向。Paper中比较了在WSC中,使用各种资源Latency, Bandwidth, Capacity的区别。
    wsc-latency

    因此,将来的程序可能会是这样,由几个简单的PHP组成, 运行在一个Datacenter上,使用的内存可大可小,可以从1M到100G;使用的存储可以无限,使用的数据库无需关心切分逻辑。程序员需要做的工 作,只需把PHP写好。其他的工作,通过一个Datacenter OS来完成。与Google AppEngine的区别是,这个OS是Open的。

    作者在上述paper中呼吁计算机科学家应该加强WSC这一新兴领域的研究,因此如果把LAMP这一记组合拳及相关经验理解为网站架构设计的话,或许不久的几年之后,这一定义将重新改写。我的Google Reader里面有上百篇加星的有关LAMP架构经验的文章,那时,它们对于大部分架构设计师不再具有借鉴意义。

    Google的paper最早是从The datacenter is the new mainframeThe Datacenter as a computer看到的。

    多服务器通讯层应该如何设计—一次code review小记

    大型的网络应用服务器(比如即时通讯及游戏服务器等)通常有大量的服务器内部数据通讯需求,几个月前曾经介绍过通讯层的实现再谈点对点通讯模块的故障问题,目前这个程序已经经历了数个版本的重构。今天进行了一次小组code review,讨论了当前版本的一些问题。

    I. Background

    我们为什么需要一个独立的通讯层

    对于服务器内部的通讯功能,已经有TCP提供可靠传输,已经有类似Apache MINA这样的框架来提供上层的封装,业务逻辑代码完全可以直接基于socket或MINA这样的框架来直接传送数据,我们为什么还需要包装一个独立的通讯层?

    目前考虑到的原因有

    • Connection pool作用。为了节点间更高的throughput, 通常两节点之间会使用n个固定连接来传输。n可设为CPU内核数大小。
    • 多节点互相连接的处理。一个节点需要连接n个节点发送信息。如果这部分逻辑放在业务调用层来实现,业务层会变得臃肿。
    • 处理自动重连逻辑,单个节点可以停用并重新启用。将这部分逻辑封装到通讯层,上层调用会更优雅。
    • 服务器之间通讯很短时间内不稳定(比如10s左右的中断)的处理。如果IDC内部或IDC之间通讯不稳定会造成这种现象。我们希望这种短暂的中断,不要引起业务逻辑重新选择节点,造成大量数据迁移及cache重构带来的内部振荡。
    • 海量数据传输最优化,大部分时间单个节点单向传输会>10k个数据包/s,独立的通讯层容易测试观察该环节是否存在瓶颈。

    通讯层不做什么

    • 序列化/反序列化,这个通常使用其他的框架或技术来做,比如protocol buffers, json等
    • RPC, 我们不做rpc的事情,已有的各种RPC技术已经做得足够好了,如果有RPC需求,我们会使用其他现有的技术。

    II. Code Review过程

    逻辑介绍

    首先由主程介绍了目前的数据流程,架构图及核心代码片断。比较核心的重发机制图示意如下

    comm

    (Figure 1: 重发的流程)

    过程说明:

    • 每个数据包有个TTL值,TTL>0之前会一直重试发给同一节点。这主要避免短期网络中断带来集群内振荡。
    • 如果正常的节点投递失败,则继续投递到backup节点。Backup节点由调用方在投递时候指定。类似在邮政寄快递,需要填写如果投递不到收件人怎么处理。通讯层只是根据投递地址表(list)来进行二次投递。
    • 如果backup也失败,则返回调用方的callback FailureHandler。这点有点类似Erlang里面失败处理的思路。

    听众提出的问题

    • 重发那一段流程是否必要,因为TCP本身已经有重发逻辑。应用层再加上一层重发处理,原理上可以应付短暂的网络中断,但是实际运行过程中能否真正有很大效果。(目前运行的情况也没有很明确的数据来支持这一点)
    • 目前一个节点需要连接的多个节点是静态配置的,即由程序启动时候决定,没有做自动发现及删除。目标节点是否可用由发送方自行判断。因此提出一个问题,backup节点选择由调用方来指定是否最佳?可否让通讯层自动协商,内部选择另一个同一类型的节点来做替代节点?但实现通讯层节点自动协商机制会增加程序复杂度。毕竟我们不是P2P程序,节点故障发生的情况很少。因此需要综合来权衡。
    • 目前的结构处理几十到上百个节点的集群问题不大,如果要用在上千个节点的场合,有哪些环节需要调整?

    其他提出的一些问题是针对具体代码写法的,由于不具有广泛借鉴意义,就不一一赘述。