Shell's Home

Nov 11, 2011 - 1 minute read - Comments

关于网站架构的几封邮件摘抄

Shell.Xu <shell909090@gmail.com>:

我知道,我自己写过一个greenlet + epoll的实验性框架。

http://code.google.com/p/py-web-server

最主要的问题是,写到后来我发现,这东西对用户的要求太高了。要用好这种框架,用户必须具备系统经验,知道阻塞操作实际上是由非阻塞操作和上下文调度去模拟的,知道代码处处无阻塞(其实是不能有无调度的阻塞),能够想像系统是如何运行的。

这种人不会太多。在cpyug里面不算少,抓10个20个肯定能抓出来,抓上100个也不是没希望。但是实际在操作的时候,平摊到上海这么个地方,会python的也就见过那么不到100人,有这种要求的几乎可以一个个数出来。而且大多数已经在一个不错的公司里面有个不错的职位,你没法指望招个人来做事。

这也是为什么很多公司凡python必django的原因,毕竟用了django,虽然罕见,但是可以招人。用了tornado,能招的范围就少了很多。我自己做的这个实验性的玩意,风险大不说,HR角度来说,可选程序员只有一个。一旦在上面做了系统,不废弃系统的前提下,你压根没法谈判工资。。。

从语言角度来说,我更倾向于lisp,那个比较优美一些,而且也有编译成C的选项,速度不慢,天然的fp。问题是lisp从语义的自然可理解性来说非常差劲,那个传说中某AI实验室源码最后一页全是)并非空穴来风。对于新手入门而言,lisp成本更加高,使用lisp做系统,HR执行的难度也更高。haskell我并不懂,不过从语言理解来说,大概介于lisp和python之间吧。

协程型框架和进程/线程型框架相比,最大的好处就是减少了锁的问题。因为上下文切换的位置都是已知的,是否需要锁很容易考虑。很多时候甚至不需要严格锁定,只要置标志位就好,速度很快。使用fp,也可以大幅减少锁的问题,但绝对不是避免。目前的系统架构设计,已经越来越多的把锁的问题扔到了数据库层。

例如,我在操作一条记录的时候,一定会发生行级锁,否则就是不安全的。而在添加一条记录的时候,必然会修改这个表上关联的索引。而修改索引的瞬间,就会发生瞬时的锁定和解锁,否则也是不安全的。这个过程虽然对用户不可见,但是并非不存在。诚然,数据库访问是基于网络的,而基于网络的read是一个阻塞操作,在架构级别一定会调度到别的上下文执行。但是没意义阿,大规模的用户访问,除掉可以缓存的部分外,都被压到了数据库上进行读写。这些访问,在表级频繁的发生冲突,被各种锁序列化成顺序访问。到最后,我们不断的向系统中添加机器,来换取性能增长的时候,应用服务器实际上变成了问题最小的一个——小到用也许bash去写cgi都可以满足。与此同时,我们的数据库问题越来越大,还没法拆分——你没办法像应用服务器负载均衡那样把数据库拆到多个机器上去,然后让他们的写入性能成倍数增加。

无论是mongo,redis,还是mysql,都没有本质上的解决锁,尤其是写入锁的问题。mongo的读取性能可以上到15kreq/s,但是写入只有5kreq/s,而且好像还不能由sheding做加速——至少不是成倍级别的加速。mysql目前比较成熟的方案还是单写多读。当然,还有所谓水平拆分和垂直拆分的方法。垂直拆分对业务有要求,水平拆分只解决了大规模数据吞吐分布到多个存储媒体的问题,不解决索引访问的问题。redis压根没有自己的分布方案,你必须自己来做。

k-v受到热捧的原因之一,在它给了你一个从某个层面绕过这个问题的方法。目前写入锁最严重的点在于索引。无论是插入还是修改记录都需要在数据库上变更索引,而索引的变更就必然会发生锁。K-V的要点在于不允许在记录上做索引——所以mongo不是k-v数据库——从而允许用户将庞大的写操作分布到数十乃至数百台机器上的同时,获得倍数级别的性能增长。我们先不考虑添加/删除——这个是一致性哈希的目标,也不考虑可用性——这个是冗余的目标。仅从这点来说,k-v数据库受到热捧是有原因的。

问题是,这也不是解决问题,这只是绕过问题。相信使用k-v的人应该有所感受,这玩意根本没法替代常规数据库来用。没有事务,没有一致性隔离就算了。连索引都没有,这TMD的怎么用阿。目前来说,更加实际的使用还是用k-v来存储一些确实没必要进行索引的东西——例如大量小规模图片,用户的属性数据。

Zoom.Quiet <zoom.quiet@gmail.com>:

  • 那么这样的话,可以考虑用 Erlang ,这货天然就是为了大分布高迸发服务发明的

  • 而且从语义行文角度看也很好理解

  • 更加要命的是 erl

提供了丰富到变态的动态调试工具,风骚无比的热部署无缝回滚…

  • 只是,摧悲的是 erl 对于计算无爱…

  • 不过,反过来想一下:

  • 现在 web2.0

的世界,以及在爆发中的移动互联应用中,有什么是非要复杂关系查询的?!

  • 通过业务的良好统计,可以从业务角度就异步化

  • 那么,不论什么语言来开发,都没有阻塞问题存在了哈…

  • 这也是为毛 K/V 数据库得以商业应用的主要原因

  • 另外,前述有人说 git 作存儲的思路也是个方向:

  • 既然分布式写入锁是个难题

  • 那么就直接只进行本地操作好了

  • 仅在必要时,进行分布式合并,这方面,各种版本控制系统都作得很好

  • 如果 redis 的bilog 文本对 git

合并是可耐受的,那不就是个山寨的分布异步安全锁了?

Shell.Xu <shell909090@gmail.com>:

我觉得我的最终解决方案是到大学里面培训lisp课程,争取弄出一批语义上看C系列语言不顺眼,只能读懂lisp的变态出来。这种现象在自然界有广泛分布,地球上至少有1/4的人类在使用最流行的语言系统时有障碍,只能使用一种难用的要死的古老的,基于符号的语言系统,并且引以为傲。。。

业务角度异步化并不是最终方案,因为除了移动互联网应用外,数据库业务最赚钱的还是公司业务。公司业务的数据量不见得比移动互联网应用小,而且他们有钱。由于目前没办法,公司业务都是找oracle这种公司来处理,而且对性能没有要求。其实不是真的没要求,而是没法要求而已。

我觉得比较有前景的,是如何将索引分布,理论来说这是可以做的。一致性哈希,DHT,都有希望。问题是目前来说,安全的写入分布式的索引本身好像也是要锁的,这就没意义了哈。

我还没想过分布式的索引本身写入锁的冲突概率是多少,能降低一个数量级就值得玩玩看。