http://shell909090.com/blog/2011/11/%E5%85%B3%E4%BA%8E%E7%BD%91%E7%AB%99%E6%9E%B6%E6%9E%84%E7%9A%84%E5%87%A0%E5%B0%81%E9%82%AE%E4%BB%B6%E6%91%98%E6%8A%84/
关于网站架构的几封邮件摘抄
Shell.Xu <shell909090@gmail.com>:
我知道，我自己写过一个greenlet + epoll的实验性框架。
最主要的问题是，写到后来我发现，这东西对用户的要求太高了。要用好这种框架，用户必须具备系统经验，知道阻塞操作实际上是由非阻塞操作和上下文调度去模拟的，知道代码处处无阻塞（其实是不能有无调度的阻塞），能够想像系统是如何运行的。
这种人不会太多。在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，都有希望。问题是目前来说，安全的写入分布式的索引本身好像也是要锁的，这就没意义了哈。 我还没想过分布式的索引本身写入锁的冲突概率是多少，能降低一个数量级就值得玩玩看。
是也乎,是也乎,列表的魅力就是可以轻易激发各种深度思考,,,,
不过,Blog 是完全不同的载体,直接摘录邮件内容就太 lazy 了
- 建议,将自个儿完整的思考,配合图谱,代码,讲述出来
- 作到自个儿半年之后,再看 blog 也可以轻易的数据整个 5W1H
http://wiki.woodpecker.org.cn/moin/5W1H
唔，这个事情等我把这玩意做完吧，或者告一段落，事情有个定论再来说。