闲话淘宝网和新浪微博架构

11-08-25 banq
如今分布式系统在国内已经不是新鲜事，NoSQL之花遍地开，我08年就诅咒的关系数据库虽然僵而不死，但其已经威力和影响力已经日渐式微，至少没有完全占据新兴需求市场。

淘宝网和新浪微博我都有使用，虽然深知其中架构之路坎坷，但今天写这个闲话不是夸耀追捧，而是作为一个懂行的使用者如何从用户体验角度来感知其技术架构特点：

淘宝网和新浪微博两个有明显极端：前者比较注重数据的及时更新，也就是高一致性，写入提交很快，但是读取数据时会丢丢拉拉；后者则相反，读取相当快，但是提交微博或评论等写入动作时却经常停顿延迟甚至失效。

从业务上讲，淘宝网确实是电子商务系统，和钱打交道比较多，好像这很符合关系数据库的高一致性要求，实际上，如果对业务进行细分，电子商务系统中高一致性要求范围比较小，按照ebay架构来看，约占据10%不到。如果不对自己的业务应用进行领域量化切分，会将高一致性扩大化，造成的表现就是写数据很快，读数据慢甚至无反应。

而新浪微博则是一个社区系统，根据其业务模型，好像几乎不需要高一致性，但是如果也不对业务进行领域切分，那么一致性将会丢失，甚至影响可靠性，微博用户可以忍受读不到数据，但是不能忍受无法写入数据，甚至提交微博时要再三确认，虽然一条废话没有存钱那么重要，但是要让用户自己去确认是否写人，这样用户体验真的很差。

总之，技术架构是一种平衡，只有对业务进行细腻的领域切分，才能真正做到有的放矢，技术架构还要摆脱自己屁股的影响，特别是过去的丰富关系数据库经验会培养人一种没有意识到惯性思维，从而让自己的脑袋无法真正做到平衡决策。

最后，衷心希望两家先驱者能够更上一层楼，利用良好宽松的资本环境，将业务分析方法引入技术架构，没有通用架构，只有合适的架构，合适与否取决于你对业务模型的透彻认识。

[该贴被banq于2011-08-25 10:17修改过]

jdon007
2011-08-26 11:34
2011年08月25日 10:12 "@banq"的内容
淘宝网和新浪微博两个有明显极端：前者比较注重数据的及时更新，也就是高一致性，写入提交很快，但是读取数据时会丢丢拉拉；后者则相反，读取相当快，但是提交微博或评论等写入动作时却经常停顿延迟甚至失效。 ...


根据CAP的理论，淘宝网注重“一致性”(C)，新浪网注重“交互性”（可用性，A）。在集中式系统中，这两者本来是“鱼和熊掌可兼而得之”。

为什么不可兼得呢？问题出现在“P"，即分区容忍性。分“区容忍性”实际上是“分布性”或“并发性”的同义词。在分布式系统中，一致性与交互性在追求极致时，会出现不可调和的矛盾。一致性要求可靠（准），交互性要求有效（快），而事实往往是“慢工才能出细活”。

banq
2011-08-26 11:39
2011年08月26日 11:34 "@jdon007"的内容
根据CAP的理论，淘宝网注重“一致性”(C)，新浪网注重“交互性”（可用性，A） ...


是这样，但是注意有一个前提，是对待特定业务模型，有些需要高一致性的业务模型就用CP，而有些应该用AP，而不是笼统地都用CP。这涉及业务领域的细分。

所以，在一个云计算环境中，我们可以根据我们业务特点选择不同的C或A，比如支付系统这样高一致性业务，我就直接选择关系数据库，如Amazon RDS；而对一致性要求没那么高，比如产品目录浏览 搜索等，那么我就选择NoSQL，如Amazon的SimpleDB；如果我用来存放的是静态文件，那么就可以选择CDN。

而如果不建立一个Paas，则容易发生眉毛胡子一把抓的情况，陷入细节纠结中，顾此失彼。

我楼上这篇文章是试图从一个总体论角度，不管云计算，还是自己做分布式，最终体现在用户端的读写这两个指标上，体现在延迟性和吞吐量这两个硬性指标上，你想推更多数据量吞吐到用户端，或者接受更大规模用户的大数据提交，会产生时间上延迟，如果后面的架构设计得不好，这种延迟就会妨碍用户感受。

架构上可接受的延迟是不能妨碍用户感受的，如果无法避免停顿长延迟，至少要每次给用户感受是平滑的，也就是不能时而停顿时而平滑，那就是后台动态扩展性Scalable设计得不够好了。这就像吃饭，如果囫囵吞进去，会难以下咽；相反，细细嚼碎(将一个页面的综合业务细细分离，调用不同的后台架构)，反而非常平滑。

[该贴被banq于2011-08-26 17:58修改过]

banq
2011-08-28 19:02
女人找男朋友的CAP定理 和程序员找分布式架构的CAP定理：

liujian1979
2011-08-29 09:53
我从06年开始认识淘宝并在淘宝上开始购物，一直到今年年初还感觉淘宝搜索和查询都很快，但到今年4-5月份至今发觉访问和打开淘宝网页速度和查询速度明显变慢了很多，尤其是很多店家网页第一次打开不全，需要刷新几次才能打开全的问题很是郁闷！对于淘宝现有的用户量和店面数，解决高延时应该是当务之急了，要不不管是商家还是顾客都无法忍受刷几次页面才能打开页面的情况。总的来说就是上淘宝的用户感受度明显感觉低了很多。希望淘宝技术人员能尽快的解决这一问题。
新浪微博的感受还挺好，提交慢是在可容忍范围内，感受不明显。
其实CAP不管是在淘宝还是在新浪微博，要运用到恰到好处都是很难！尤其是淘宝的业务复杂度越来越高。对于中国这个浮躁的社会，精耕细作不仅仅考的时候雄厚的资本。国情和环境决定了应该滋生什么样的公司！也许有些小公司开始并比Facebook差（理念和创新），但因为生长在中国，很快就被掐死在萌芽状态！

jdon007
2011-08-29 13:46
2011年08月29日 09:53 "@liujian1979"的内容
女人找男朋友的CAP定理 和程序员找分布式架构的CAP定理： ...


这兄弟幽默，不过有钱、有才又帅的男友是有可能的，比如李彦宏。

问题是找个最帅、最有才、最有钱的人几乎是不可能的。

高并发的环境下(P)，一致性(C)与交互性(A)，在追求“极致”时，才会出现“此消彼长”的矛盾。

找个耐看的、略具才华的、中产阶级的男友，女子一般是可以要求的。对于多数应用，也应有此追求，只是需牢记，“没有最好的，只有最合适的”。

banq
2011-08-29 15:33
技术架构是为业务服务的，如何将技术架构和业务切分紧密结合，实行起来不是无章可循，还是有一套模式的：如缺省坚持不可变性(Immutability)；引用透明；不同的数据需要不同保证边界(通过类等边界工具封装)等等。

banq
2011-08-30 08:49
今天(8月31日)淘宝在其微博宣布开源其分布式数据库系统OceanBase，这一举动本身说明淘宝人的开放性，表面上好像他们把他们的经验分享出去，好像没有得到什么利益，其实他们可能会得到更大的进步，因为架构设计是一种宏观战略设计，宏观战略不担心如何深入尖端，就担心这种深入的方向出错了，而这种方向性错误是身在庐山之中的淘宝人自己无法发现的。

我们这些局外人带着学习或挑剔眼光去看时，也许会偶然间发现这些细小但是方向性的问题，我想这也是国外很多大型系统开源的目的所在吧。

关于OceanBase在其官方博客http://rdc.taobao.com/blog/cs/?cat=97 PPT上看，其中我只看到分布式文件系统和CDN，如果按照Amzon的云计算层次来看，只相当于其CloudFront，都是针对静态数据部分，而动态数据部分如何优化没有看到(这才是最难最核心的)，没有完整的Paas概念。所以，称“分布式数据库系统OceanBase”也不是非常准确，分布式文件系统吧，类似于Facebook的Haystack或HDFS吧。

这些都是属于磁盘式数据库，最新文章：

数据管理的未来: “Disk-less” 风格数据库?

什么时候程序员意识到“Hold住事件”比“Hold住数据”更重要，就意味他摆脱了数据库阴影，走上了架构之路：NOSQL基于事件的事务实现


[该贴被banq于2011-08-31 13:16修改过]

banq
2011-09-01 09:44
大概我闲话了淘宝网，今天访问淘宝网首页，它就黑掉了我的chrome浏览器，我是10M带宽上网啊，
关键是把我正在Chrome浏览器中翻译的Martin Fowler文章：LMAX架构 给毁了，悲剧啊，而这篇文章也许应该是淘宝或支付宝等类型的未来架构，它能够在一个线程里每秒处理6百万订单啊，每微秒的延迟获得100K+ TPS。

LMAX架构一文其实给出了分布式事务的另外一种实现，这是一种否定传统关系数据库锁事务，也不同于Scala等提出的STM软事务，而是一种全新的事务，我看了一下淘宝OceanBase介绍，其中一句：

传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间，但数据规模受到严重制约，缺乏扩展性；现代云计算提供了极大的数据规模、良好的扩展性，但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长，OceanBase的设计和实现融合了二者的优势。

据观察，OceanBase类似HBase，或者类似HBase + HDFS，然后在其中增加了关系数据库，不能确切知道OceanBase是采取我前面讲的三种事务中哪一种来实现事务性呢？或者干脆是直接整合了关系数据库。HBase和Cassandra等区别见另外一篇文章：如何学习NoSQL？

反正这贴是闲话，我刚刚看到马云一句话：
马云：公司不缺战略，不缺idea，不缺批判，公司缺把战略做出来的人，把idea变现的人，把批判变建设性完善行动的人!刚来公司不到一年，千万别写战略报告，千万别瞎提发展大计。。。谁提，谁离开！三年后，你讲的话我一定洗耳恭听。

这种文化表面上让新来人员踏实干活，一旦他变成战术性人才，三年后他就提不出战略性观点啊，而且他还觉得那是夸夸其谈。

[该贴被banq于2011-09-01 20:52修改过]

jdon007
2011-09-04 12:12
2011年08月29日 09:53 "@liujian1979"的内容
不管云计算，还是自己做分布式，最终体现在用户端的读写这两个指标上，体现在延迟性和吞吐量这两个硬性指标上， ...


一般地，分布式通信系统有两个最基本的度量指标：有效性和可靠性。

有效性，反映分布式通信速度的“快慢”；（信息传递不过期，快）
可靠性，反应分布式通信质量的“好坏”。（信息传递不失真，准）

在CAP中，A，可用性，相当于“有效性”；C，一致性相当于“可靠性”。P是分区容忍性，或者分布式性。

在分布式通信系统中，
用户张三，发送（写）了一条消息—明天“不会”下雨；
用户李四，收到（读）到这条消息—明天“会”下雨。
该系统的“一致性”或“可靠性”就很差，信息严重失真。

用户张三，在今天，发送（写)了一条小-“我们明天一起去打球吧”；
用户李四，却在后天，收到（读）这条消息。
该系统的“可用性”或“有效性”就很差，信息严重失效（过了有效期）。

商品交易，以“可靠性”为主导，即在保证信息传递的准确性（可靠性）的前提下，提高信息传递的速度（有效性）。

围脖交流，以“有效性”为主导，即在保证信息传递的时效性（有效性）的前提下，提高信息传递的质量（可靠性）。

延迟性与吞吐量，是“有效性”（性能）指标的细化，即能够以“多快”的速度（延迟性）传递“多大”的信息量（吞吐量）。

分布式系统的衡量指标，须从“收发”（或“读写”）的关系出发，割裂二者来考虑，是很难反映出系统的基本特点的。

淘宝网“写的快，读的慢”的表象，是为保证“交易信息”的准确性或可靠性使然。

新浪围脖“写的慢，读的快”的表象，是为保证“围脖信息”的时效性或有效性使然。

banq
2011-09-09 09:51
2011年09月04日 12:12 "@jdon007"的内容
一般地，分布式通信系统有两个最基本的度量指标：有效性和可靠性。 ...


有效性Availability 有一个衡量指标，如ITIL的定义:



这这篇文章:CAP的availability不是你想象的那样中谈到：如果按照CAP定理严格定义：
对于一个分布式系统要持续可用, 被每个没有当机的节点接受的请求必须有响应，. 任何在服务端采取的计算可最终中断，也就是说，可用性的一个弱定义: 它没有约束一个计算在中断以前允许多长时间计算，也就是说：一个无限期的计算是允许的。

该文作者问了：难道花了10个小时和3天返回计算结果也算是"可用available" ？作者认为这种无限期延迟其实已经影响了可靠性(consistency)。

作者认为在实际系统中反而是PACELC 定理有可操作性，如下：

CAP应该被PACELC替代：如果有分区partition (P)，系统就必须在availability 和consistency (A and C)之间取得平衡; 否则else (E) 当系统运行在无分区情况下,系统需要在 latency (L) 和 consistency (C)之间取得平衡。


现实中可用性availability有两个指标：: 当我们不进行分区时，它实际是延迟性latency指标, 还有一种是分区时必须拥有可靠性reliable。

PACELC能够让我们在传统的延迟性latency vs 一致性consistency进行平衡，当分布式分区时，存在丢包情况下，就必须在可用性availability vs consistency一致性之间平衡。

我个人认为：Terrastore和CAP定律一文对Terrastore定位比较让人信服，而不是简单说既有关系数据库高一致特点，又有NoSQL等高分布式特点，好似一种超级通用解决方案。

如何打败CAP定理？

[该贴被banq于2011-10-15 07:26修改过]

banq
2011-11-02 13:06
其实淘宝网和新浪微博还算好的，虽然有延迟，但是还在容忍范围，京东商城的延迟则完成无法容忍，看今天我进入购物车的页面，订单流程都无法提交，相比LMAX架构每秒处理600万订单，京东商城是每小时处理6个订单不错了，有人打趣说：他们都是用员工的手直接处理Http的。

相关：

最终一致性在现实世界中到处存在



[该贴被banq于2011-11-09 14:58修改过]


banq
2012-06-15 07:41
从通信延迟角度去微调cap理论。http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed。该文章观点与我在本帖要表达的观点一致，评价分布式架构好坏最终要从终端用户能感受的延迟和吞吐量去衡量和微调，cap定理不是拒绝高质量服务的借口。