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，都有希望。问题是目前来说，安全的写入分布式的索引本身好像也是要锁的，这就没意义了哈。

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