|
|
xyb 
于 8 月, 2 周 前说到：
按说用LAMP做网站的一般都是用缓存，方案比较成熟。现在随着erlang的热门，share nothing又开始流行了。只是缓存有memcached这样经受过验证的产品，share nothing用传统的LAMP如何来实现呢？感觉上会比用memcached耗费更多的资源。有谁知道都有那些网站是按照share nothing的原则设计实现的吗？
|
|
|
|
|
手背轻微晒伤的大野狼 
于 8 月, 1 周 前说到：
xyb，能否解释一下share nothing与erlang的关系？
基于我对Erlang非常有限的了解，因为这种语言的设计初衷是为了服务于高并发的电信，所以在大事务量的情况下，缓存反而成为麻烦事。这与通常的Web 2.0的网站设计目标是不同的。
所以，我觉得Erlang也许适合在线游戏，但是不太适合Web2.0的应用。
我如果说的不对，请纠正。ZoomQ，老黄他们也许有别的看法。
|
|
|
|
|
仨儿 
于 8 月, 1 周 前说到：
同AI 问题类似，还是界限问题；
web2.0 中也不是都是内容为主的哪，
比如说 twitter 就非常类似高迸发小内容的分布式应用，
其实 Erl 最成功的应用在无线业务领域，爱立信的 AXD301 项目的能量是有目共睹的哪；
正是因为采用了非常独特的思路所以，才令Erl 在特定领域成王成圣的，
详细理解 share nothing/速死 等等概念推荐阅读 Erl 作者的论文:
http://groups.google.com/group...
erl-面对软件错误构建可靠的分布式系统.pdf
所以，和兽血中所言类似：
没有差的开发语言，只有不会恰当使用的开发者
理解你的应用领域，理解你的语言工具，才是正确的开始...
|
|
|
|
|
cleverpig
于 8 月, 1 周 前说到：
本人对于cache/share nothing和erl的关系的看法——和三儿不谋而合：没有差的开发语言，只有不会恰当使用的开发者。在高并发系统中使用erl来handle concurrence requests，并且适度地采用distrubuted cache system来加速系统访问，在某些场合达到的效果要超过单独使用某一方。看似有些像太极中的制衡思想。
|
|
|
|
|
老黄
于 8 月, 1 周 前说到：
:) erlang并不是贴着share nothing标签呀。
我认为share nothing有其合理之处，也有可恨之处，我还是喜欢 服务即备份，备份即服务的理念。 也就是说，在服务的同时保持可能的备份和冗余，这个让人感觉有一举多得的快乐。
|
|
|
|
|
手背轻微晒伤的大野狼
于 8 月, 1 周 前说到：
有趣，对于好看簿这样的网站，你所说的”备份与服务“几乎同步的方式，应该怎样进行呢？
|
|
|
|
|
仨儿
于 8 月, 1 周 前说到：
参考Google 的GFS 部署方式就知道了，
服务本身就是冗余的，所以，同时也就等于完成了备份；
而且有些DFS 的备份策略也非常非常的合理:
* 设立3个同样的备份关系
* 写入时随机导入当时反应最快的主机
* 只有该份内容再次读取时，进行数据同步到其它两主机
* 再再次读取时，导向当时反应最快的主机
这也应该是 备份和均衡服务可以采用的策略...
|
|
|
|
|
xyb
于 8 月, 1 周 前说到：
发起这个话题时，实际上我是想知道有那些网站是把其中一个策略发展到至极的。现在我知道amazon是实际上在使用share nothing策略的[1]，各种数据被分散到很多数据库(有钱，用了很多oracle)，所有对数据的访问都直接去数据库获取，然后尽量优化数据库。而缓存的方法因为memcached的存在，在使用开源工具的众多网站中比较流行。那么，缓存的方式是不是存在着天然的瓶颈，在达到某种规模的时候，它带来的麻烦会比好处更多？毕竟mmecached的创建者livejournal的规模和这个星球上几个最大网站的规模差距很大，作为memcached的样板工程，它目前的这种架构发展下去能支撑多大的规模和复杂程度呢？这种架构有没有能力的极限？极限在哪里？这也是所有使用类似架构的"web 2.0"网站的问题。
[1] http://highscalability.com/ama...
现在看起来大多数网站都还没碰到这样的瓶颈，毕竟大家跟livejournalde的规模还差几个量级呢，但越早做准备，到时需要调整的东西越少，是不是？
to HD:
按我的理解，share nothing和备份既服务、服务既备份并不矛盾。share nothing意味着数据源能且只能要从源头获得，但这个数据源可以用很多技术来实现，其中也包括做了负载均衡的冗余服务。
to 大野狼:
有道理。网站和电信服务的确很不一样，erlang也许不适合开发网站，但不能说share nothing在网站开发中就没有用武之地。当网站规模很大时，保证缓存的一致性、缓存与数据源的一致性也同样是个很大的问题。这会不会让缓存退化成share nothing这样的架构：数据被分成很多块数据源分别提供服务，缓存被剥离，只架设在每个数据服务区的前面？
to zq, cleverpig:
share nothing在erlang以及电信业务中的成功人们都看到了，抛开语言，我是想跟大家讨论一下share nothing在网站的开发中是否有用武之地，以及它是否有可能成为终极解决方案。如果有人有自己的亲身体验也希望能分享一下，比如erlang或者share nothing在金山的应用。
缓存其实有很多自己的问题。比如，如果更新过于频繁，有可能造成两个更新同时覆写一个缓存，造成一致性错误；但如果在缓存更新时加锁，机制就又太复杂了，尤其是使用分布式缓存时。另外，当代码更新时，缓存中的数据有可能和新的代码不兼容，也得做额外处理：或者在代码中做兼容处理，或者冷启动缓存系统，或者提前批量删除缓存中所有旧数据。还有，当缓存系统冷启动时，要往缓存中灌入大量数据，数据库负载极高，而前台又因为从缓存获取不到数据而迟迟无法响应，这时网站的服务就会阻塞、中断。随着网站规模越大、数据越多、缓存越大，缓存冷启动的问题也就越明显。但share nothing方案天生就没有这些问题。
|
|
|
|
|
手背轻微晒伤的大野狼
于 8 月, 1 周 前说到：
◎xyb，我在这个论坛的另一个Inside MySpace里面有提到Myspace是一直到了上线两年半，活跃用户到达7百万的时候才开始实现Cache的。好看簿现在的解决方案就是预留出内存，每个服务器8G，不够再加。我的一个观点是能花钱省下工程师时间，降低系统复杂度的事情，就很值得去做。
MySpace直到上线3年后才迁移到64位平台上，多少也是问题。
> 这会不会让缓存退化成share nothing这样的架构：
> 数据被分成很多块数据源分别提供服务，
> 缓存被剥离，
> 只架设在每个数据服务区的前面？
呵呵，这绝对是未来的趋势。不知道豆瓣用的是怎样的数据Partitioning技术，根据我的研究，flickr，livejournal和MySpace都是采用按照用户切割而非按照功能切割的解决方案。
|
|
|
|
|
xyb
于 8 月, 1 周 前说到：
现在看起来，其实如果一开始就打定主意用share nothing，反而开发和管理会更简单，能降低系统的复杂度。
在代码里到处嵌进去读取、更新缓存的代码并不那么好看，增加修改功能时要时刻留意缓存的一致性也不那么轻松。当数据太多需要切分数据库的时候呢？所有缓存相关的代码都得检查一遍，用新的方案替换。如果一开始就是share nothing，前台服务和后台存储两个系统能分得更清晰，耦合度低，可以分别升级，容易维护，从长远来看似乎更节省工程师的时间，不过初期投入会更高一些。
|
|
|
|
|
老黄
于 8 月, 1 周 前说到：
呵呵，架构的问题决定了主基线。架构是不能随意改变的，代价就是工作量。各有各的好。从缓存切到share nothing也不是哪么容易的。这两天，我在xbaytable的dht分析时就发现不少难处，erlang到是省很多事，但是难的终究麻烦 :)
@大狼
另外，按用户切分是有道理的，因为一切的数据都有其关联性，为了节省这部分代码的复杂度，自然不会按功能切分了。
|
|
|
|
|
xyb
于 8 月 前说到：
不错，切换到不同方式是不太容易的，不要说缓存到share nothing，就是一个已有的老系统切换到用缓存的方式也要费很大的劲。
如何把缓存更好得应用到系统中也是个问题。django提供一个统一的缓存接口，倒是很方便；但有好几个地方可以插入缓存机制：html、view/controler、model等等，搞得太粗放后期开发不好办，搞得粒度太细又会太琐碎、效率不高。因为django有自己orm的关系，好像找不到特别理想的插入缓存机制的地方。
|
|
|
|
|
手背轻微晒伤的大野狼
于 8 月 前说到：
◎老黄：我在上一个公司作为架构师第一份工作就是利用缓存技术把编译器的速度（主要是代码生成器）提高将近5000%。工作量倒并不大，因为那个东东的很多东西修改的不多。
◎xyb：现在豆瓣采用什么缓存技术了吗？ 是否有过测试来判断这个工作量是否值得？
我觉得离开具体网站特点去讨论不太有效率，所以更想了解一下功能类似的网站是否有经验大家可以共享。
◎老黄：对了，你在xbaytable里面要用到DHT！？不会吧，搞这么复杂？
|
|
|
|
|
老黄
于 8 月 前说到：
呵呵，DHT只是一个叫法，实质上是用一个方法把数据分散到各个节点中去。一个简单的hash罢。
|
|
|
|
|
Diamond Tin!
于 7 月, 3 周 前说到：
我是这样看的，两者确实没啥关系：
erl的特性确实不止是语言层面的，它提供的轻量进程非常适合大并发的应用程序运行。而且它提供的高效的进程通讯方便了实现一些与以前不同的架构。
而SNA实际上还是避免share data以后造成分布后的服务绑定或者复制/失效处理的麻烦。但是，几乎所有的SNA方案都是share less，而不是share nothing...，完全的去中心化还是需要有特殊的场景来驱动的，平常能够见到的场景不足够share nothing。
但是，Martin Fowler的分布式第一原理说不要分布，原因是分布非常复杂。复杂的原因是分布的服务无法完全幂等，无法实现完全的并行，所以被迫才有了SNA。但是SNA是宏观的，微观上说多CPU也有同样的并发访问CACHE和内存的问题，所以有了有锁的并发和更加复杂的无锁并发问题。但是人们发现很难透明解决并发问题。所以不得不又回到从前，开始回归数学上面说的没有side effect的函数式逻辑表达……所以近年来函数式回归（当然这很大程度上与CPU的发展有关）……
扯这些就回到了erl的模型：
1、函数式表达保证无side effect，这是无锁并发的关键
2、轻量进程和低价的进程通讯使更大的进程并发成为可能，还有就是erl的vm的特殊性天然可以在分布式环境下运行
嗯，然后就是我的结论了。我觉得xyb之所以觉得两者相同，原因就在于两种想法都在要搞定并发问题，然后就是减少共享和相互干扰……从这个理念上两者是相同的。但是是不同的scope...
|
|
|
|
|
Diamond Tin!
于 7 月, 3 周 前说到：
我觉得erl的非常适合人类思维的patern matching这个特性比较适合描述算法，感觉上也就是适合CPU密集型的应用。
但是不幸的是大部分web应用都是dada centric，所以……你不觉得erl写web是杀牛用鸡刀了么？但是网游啦，交换设备啦，聊天室啦，数据中间件啦就比较适合erl了。虽然erl下面也有几个web框架，但是想起前两天看某牛写“每个人都想写自己的web framework”，我想那些不过是一种“我有这种能力……”的证明，我预言这不是erl的地盘……
|
|
|
如果想参与讨论，需要登录好看簿。
|
