世世待茗

突然的想起研究蒸汤和煲汤

在食欲清淡的夏日，一盅好汤，总能唤起齿间的味觉

对于一向慵懒，嗜汤趟躺烫的偶~  煲汤便是自己给自己的幸福~

今天在家山寨了一把“黄芪炖鸡”~  欢迎从前yy“黄颀炖鸡”未遂的同学来一偿夙愿 ^_^~~

（典故挺有趣：某北京新东方牛老师，名黄颀，号称Verbal考到650，拿着成绩单去找他，便可喝到他独家的“黄芪炖鸡”~ Verbal 650，多少同学的梦想~ 这老师又出身中医，所以这“黄颀炖鸡”嘛，自是营养也很赞了~ ）

1. 超市选了些鸡腿肉和翅根 ，在凉水中浸泡飞水。与洗好切好的姜片放好沥干后备用

tips：由于夏日不准备久炖，且喜味浓郁却清淡的，故选些鸡腿肉和翅根，都很鲜嫩，较适合清淡的汤。生姜洗净后可不去皮，如有老姜更好，都是为了更劲一些。

2.不加油，放入锅内炒干，色会稍变黄。再加入少量白酒，继续炒干，肉会紧致并且很香哦。

3. 将原料放入容器中，加入凉水，洗净的黄芪、白芷、肉桂、枸杞。

tips：今天为了比较，尝试了蒸汤和煲汤两种方案。上图是蒸汤的，今天没买到蒸盅，只能山寨下用碗了。

蒸汤：放入容器后，用保鲜膜封好，上火整。约1小时。

煲汤：放入砂锅，大火烧开，转小火，炖约1小时。

4.1  蒸汤起锅。加了些胡椒，真破坏美感 T_T! ~味道较清淡。

4.2 炖汤起锅，味道浓郁，下图是已经盛入小碗的，是不是很诱人，呵呵。

总结下：

第一次尝试，做法还是挺成功的，汤鲜美，肉质鲜嫩。

改进想法：蒸汤时间可以稍长一些，味道会更浓郁，下次要换蒸盅~煲汤火候已经很不错了，这次肉桂放了两颗，稍有点苦，下次一颗就好。

欢迎同学们有空找偶一偿“黄芪炖鸡”的夙愿，呵呵~

——————————————————————俺是美食分割线——————————————————————

今天尝试改良了一下凉拌毛豆的做法，实践很成功，故也分享一下。

从前偶做凉拌毛豆，都是最后浇油，这样毛豆会受到油的再次受热影响，小料味也不够香。只拍了变化的地方，其他的和从前一样，以前日志上有。

在油锅中将芝麻油烧热（从前都用色拉油，发现芝麻油更好吃），均匀的浇在小料上。会发出呲呲的响声。

调入老抽、生抽、醋、等~~（比例很重要），这张拍糊了，囧，大家见谅一下

拌好起锅啦，冰箱冰镇30分钟后味道更好，呵呵。

嘿~ 流口水了不？ ^_^

转眼在Pyramid组两年了，历经过DFS和DTS两个项目，如今随着DTS的Alpha成功发布，也想试着对旧日知识和经验做一番梳理，写写文章。

整个系列会分成理论和实战两个方面，前者主要是对开发过程中参考的各篇paper做一番综述，后者则侧重于一些编程心得和设计上的注意点。暂时想到的题目有：
Theory
1. Consensus：讨论各种Consensus算法，以及其在选举、事务方面的应用
2. How to handle CAP：大言不惭的讨论一下分布式系统的CAP solutions，会涵盖How to build a scalable system/GFS/Map Reduce/Bigtable/Chubby等几篇文章
3. something else, 比如压缩算法等等

Practice
1. TCP/UDP Issues：讲一些在UDP、TCP编程中遇到的问题和解决思路
2. Commit Log Mechanism：探讨如何高效的处理commit log，以及如何保证log和memory的一致性
3. 协议设计：总结自己在交互协议、网络协议等方面设计上的问题，包括rpc等等
4. 从GAE设计看Bigtable：尝试从GAE上找到Bigtable改进方法的蛛丝马迹
5. 杂七杂八，比如一些特别需要注重的设计方面，或者一些为付诸实现的想法

当然，不是所有文章都会公开…

2009-04-20 09:16:42.0 阅读:849 回复:0
[文章作者：陈臻 本文版本：v1.1 最后修改：2009.4.20转载请注明原文链接：http://www.ip234.com ]

这是一次公司内部的交流会，主题是校内的发展史和构架讲解，主讲人是校内网CTO黄晶，其中关于架构变迁的一段个人觉得是很具有代表性的过程，特在会上作了大概的笔记，现在是凌晨一点不到，正好清醒头脑进行回忆总结。

每个网站的发展都会按照一个大致相同的路线去完成，当然这里说的是每个相对成功的网站。

第一阶段：

这一阶段没有太大的访问量，甚至只有一台服务器就搞定了所有的访问。DB和前端的代码全都在一起，压力不高。忆者注：我觉得在alexa没进五万的时候，只要不是特殊的应用，基本都在此列吧。

第二阶段：

网站初具规模，DB压力大增，单独的一台DB已经满足不了现在的访问量，开始考虑读写分离的Master-slave库，使用三个及以上的服务器。忆者注：这时网站的alexa基本上会在1-3万的位置，每天的ip在5-10w的样子，当然，DB我们都认为是MySql。

第三阶段：

访问量继续增加，增加到了DB的压力在Master的机器上非常的明显了，Master开始出现吃不消的情况，出现写耗尽。主从也已经不能满足要求，需要进一步解决负载问题，此时要引入Mysql Proxy程序，进行中间层代理，实现负载均衡，易于扩展。忆者注：这时网站已经不可限量了，先恭喜下你的网站能用到这段。

第四阶段：

网站继续发展，进而出现了数据量的成倍增长，原来的N台DB都出现了一个问题，数据量巨大，无法完成正常速度的读写。此时，需要对网站按功能进行垂直划分，比如用户注册登录是一部分、UGC又是另一部分。与此同时，对数据本身进行水平划分，也就是Hash散表或者是散库。

第五阶段：

真的没了。再往下玩就灭了。

其实再进一步第五第六阶段，就是无法预想的未来了，也许有什么突飞猛进的科学技术发明也说不好。

今天和yahoo的agentZhang（openResty作者）聊起，他说到第五个阶段其实应该是BigTable，的确很强大，来自google的作品。不过美中不足的是，它并不像我相像中的那样能够顺利过渡到第五阶段。以下论述来自infoQ:
Todd从定义BigTable的适用范围开始论述。由于BigTable引入的各种代价，只有在以下情况下使用BigTable才能带来益处：a)需要伸缩到巨量的用户数，b)更新与读取操作相比比例很小。Todd还着重强调为了“优化读取速度和可伸缩性”，所采取的理论路线与关系数据库中的做法存在根本的分歧，很可能初看起来是违背直觉甚至相当冒险的。

[slideshare id=1346297&doc=qconbeijing2009-090426225251-phpapp01]

2年前在初识kdd的时候，特别激动的觉得数据背后隐藏着太多未知的、有趣的东西，一些DM的算法是多么精巧，似乎它们就是n把万能钥匙，面对一扇扇数据的大门，插进去轻轻转动即可打开。那个时候，苦于数据太少，只能从网上找些公开的测试数据。一心想，当数据足够多了，背后的故事一定足够有趣。

当真正面临每天G甚至T级别，形式各异的商业数据时，我发现自己渐渐有些迷失，无论是能力还是激情。如果你也发现：

1.数据缺乏可信度

2.数据效率低下

3.从数据到信息非常困难

数据可以很狭义，也可以广义到抽象于大千世界任何事物的演变。

那么以下的一些topic我们可以通过不同的视角去审视数据的方方面面，我们可以一起来学习和探讨，从信息中“抽丝剥茧”~

今后本分类（好玩的数据）将围绕这些话题展开。

————————————本帖是个map—逐渐更新的topic分割线————— ————————————-

什么是数据？

数据仓库

数据集市

数据预处理

数据清理、转换

异常的发现

数据分析方法

统计学方法

数据挖掘方法

人工智能

处理数据的常用工具

数据可视化

OLAP

OLTP

大规模数据处理（分布式、云计算）

计算中数据精度的处理

适用于hoopchina（虎扑）和popgo（漫游）的自动翻页设置，当然，前提是你用firefox并安装了autopager插件

for hoopchina.com:

<autopager>
<site><urlPattern>http://bbs.hoopchina.com/*</urlPattern>
<guid>D661475F-94D9-7FE3-417A-D884-BFBD-5D3D</guid>
<margin>1</margin>
<owner>dyerac</owner>
<urlIsRegex>true</urlIsRegex>
<quickLoad>true</quickLoad>
<contentXPath>//div[@class='page_box']</contentXPath>
<contentXPath>//table[@id='pl']</contentXPath>
<contentXPath>//body</contentXPath>
<testLink>http://bbs.hoopchina.com/670864.html?vthread</testLink>
<linkXPath>//a[@class='next' and @title='下一页'] | //table[3]/tbody/tr/td[@align='left']/span[1]/following-sibling::a[1]</linkXPath>
<desc>http://bbs.hoopchina.com/670864.html?vthread</desc>
</site>
</autopager>

for popgo.net:

<autopager>
<site><urlPattern>popgo.net/*</urlPattern>
<guid>EEC01EEE-5707-D109-F0A8-17EE-AC12-4D23</guid>
<margin>1</margin>
<owner>dyerac</owner>
<urlIsRegex>true</urlIsRegex>
<quickLoad>true</quickLoad>
<contentXPath>//center</contentXPath>
<testLink>http://popgo.net/bbs/forumdisplay.php?s=&amp;forumid=11&amp;daysprune=30&amp;sortorder=&amp;sortfield=lastpost&amp;perpage=40&amp;pagenumber=3</testLink>
<linkXPath>//a[@title='下一页']</linkXPath>
<desc>http://popgo.net/bbs/forumdisplay.php?s=&amp;forumid=11&amp;daysprune=30&amp;sortorder=&amp;sortfield=lastpost&amp;perpage=40&amp;pagenumber=3</desc>
</site>
</autopager>

———————————–

PHPWind 老版本的html代码真可怕…都不用div的….

useful links:

http://www.teesoft.info/component/option,com_wrapper/Itemid,86/

A brief history of Consensus, 2PC and Transaction Commit.

by Mark Mc Keown

http://betathoughts.blogspot.com/2007/06/brief-history-of-consensus-2pc-and.html

This is a potted history of consensus, transactions and 2PC. Reading the literature on consensus is difficult because the language changes (consensus was originally called agreement), the results come in an order that isn’t logical, and the whole framework for describing distributed algorithms evolved in parallel with the work. Also, there are few books other than Lynch’s Distributed Algorithms that cover the subject.

Papers are discussed in the order that makes most sense, not in the order they were published.

The first instance of the consensus problem that I am aware of is in Lamport’s “Time, Clocks and the Ordering of Events in a Distributed System” (1978), though it is not explicitly declared as a consensus or agreement problem. In this paper Lamport discusses how messages take a finite time to travel between processors and draws an analogy with Einstein’s special relativity. Discussing Einstein’s theory with respect to distributed systems is popular recently in the blogsphere, but in 1978 Lamport give a complete analysis with space-time diagrams and all. The issue is that in a distributed system you cannot tell if event A happened before event B, unless A caused B in some way. Each observer can see events happen in a different order, except for events that cause each other, ie there is only a partial ordering of events in a distributed system. Lamport defines the “happens before” relationship and operator, and goes on to give an algorithm that provides a total ordering of events in a distributed system, so that each process sees events in the same order as every other process.

Lamport also introduces the concept of a distributed state machine: start a set of deterministic state machines in the same state and then make sure they process the same messages in the same order. Each machine is now a replica of the others. The key problem is making each replica agree what is the next message to process: a consensus problem. This is what the algorithm for creating a total ordering of events does, it provides an agreed ordering for the delivery of messages. However, the system is not fault tolerant; if one process fails that others have to wait for it to recover.

Around the same time as this paper, Gray described 2PC in “Notes on Database Operating Systems” (1979). Unfortunately 2PC would block if the TM (Transaction Manager) fails at the wrong time. Skeen showed in “NonBlocking Commit Protocols” (1981)that for a distributed transactions you needed a 3 phrase commit algorithm to avoid the blocking problems associated with 2PC. The problem was coming up with a nice 3PC algorithm, this would only take nearly 25 years!

Fischer, Lynch and Paterson showed that distributed consensus was impossible in an asynchronous system with just one faulty process in “Impossibility of distributed consensus with one faulty process” (1985), this famous result is known as the “FLP” result. By this time “consensus” was the name given to the problem of getting a bunch of processors to agree a value. In an asynchronous system (where processors run at arbitrary speeds and messages can take an arbitrarily long time to travel between processors) with a perfect network (all messages are delivered, messages arrive in order and can not be duplicated) distributed consensus is impossible with just one faulty process (even just a fail-stop). The kernel of the problem is that you cannot tell the difference between a process that has stopped and one that is running very slowly, making dealing with faults in an asynchronous system almost impossible. The paper was also important because it demonstrated how to show something was impossible: show that all algorithms that solve the problem must have some property, then show that this property is impossible, ie proof by contradiction. (This approach was only re-learned as Turing used it in the halting problem)

By this stage people realized that a distributed algorithm has two properties: safety and liveness. Safety means nothing bad happens, while liveness means that something good eventually happens. 2PC is an asynchronous consensus algorithm, all processes must agree on either commit or abort for a transaction. 2PC is safe: no bad data is ever written to the databases, but its liveness properties aren’t great: if the TM fails at the wrong point the system will block.

Also by this stage people thought of distributed systems as being synchronous (processes run at known rates, and messages are delivered in known bounds of time) or asynchronous (processes run at unknown and arbitrary rates, and messages can take unbounded time to be delivered). The asynchronous case is more general than the synchronous case: an algorithm that works for an asynchronous system will also work for a synchronous system, but not vice versa. You can treat a synchronous system as a special case of an asynchronous system that just happens to have bounds on the time it takes to deliver a message.

Before FLP, there was the “The Byzantine Generals Problem” (1982) paper. In this form of the consensus problem the processes can lie, and they can actively try to deceive other processes. This problem looks harder than the FLP result, but it does have a solution for the synchronous case (though when the Byzantine Generals paper was written the distinction between asynchronous and synchronous systems was not explicit). The solution is expensive in the number of messages exchanged, and the number of rounds of messages required. The problem originally came from the aerospace industry: what would happen if sensors gave false information on an plane (clearly the system could be treated as synchronous).

In 1986 there was a get together of the distributed systems people who were interested in consensus and the transaction people. At the time the best consensus algorithm was the Byzantine Generals, but this was too expensive to use for transactions. Jim Gray wrote up a note on the meeting: “A Comparison of the Byzantine Agreement Problem and the Transaction Commit Problem.” (1987) .

The paper contains this in the introduction

“Prior to the conference, it was widely believed that the transaction commit problem faced by distributed systems is a degenerate form of the Byzantine Generals Problem studied by academe. Perhaps the most useful consequence of the conference was to show that these two problems have little in common.”

Eventually distributed transactions would be seen as a version of consensus, called uniform consensus (see “Uniform consensus is harder than consensus” (2000)). With uniform consensus all processes must agree on a value, even the faulty ones – a transaction should only commit if all RMs are prepared to commit. Most forms of consensus are only concerned with having the non-faulty processes agree. Uniform consensus is more difficult than general consensus.

Eventually Lamport came up with the Paxos consensus algorithm, described in “The Part-Time Parliament” (submitted in 1990, published 1998). Unfortunately the analogy with Greek democracy failed badly with people finding the paper very difficult to understand, and the paper was ignored until its case was taken up by Butler Lampson in “How to Build a Highly Availability System using Consensus” (1996). This paper provides a good introduction to building fault tolerant systems and Paxos. Later Lamport would publish “Paxos Made Simple (2001).

The kernel of Paxos is that given a fixed number of processes, any majority of them must have at least one process in common. For example given three processes A, B and C the possible majorities are: AB, AC, or BC. If a decision is made when one majority is present eg AB, then at any time in the future when another majority is available at least one of the processes can remember what the previous majority decided. If the majority is AB then both processes will remember, if AC is present then A will remember and if BC is present then B will remember.

Paxos can tolerate lost messages, delayed messages, repeated messages, and messages delivered out of order. It will reach consensus if there is a single leader for long enough that the leader can talk to a majority of processes twice. Any process, including leaders, can fail and restart; in fact all processes can fail at the same time, the algorithm is still safe. There can be more than one leader at a time.

Paxos is an asynchronous algorithm; there are no explicit timeouts. However, it only reaches consensus when the system is behaving in a synchronous way, ie messages are delivered in a bounded period of time; otherwise it is safe. There is a pathological case where Paxos will not reach consensus, in accordance to FLP, but this scenario is relatively easy to avoid in practice.

Clearly dividing systems into synchronous and asynchronous is too broad a distinction, and Dwork, Lynch and Stockmeyer defined partially synchronous systems in “Consensus in the presence of partial synchrony” (1988) . There are two versions of partial synchronous system: in one processes run at speeds within a known range and messages are delivered in bounded time but the actual values are not known a priori; in the other version the range of speeds of the processes and the upper bound for message deliver are known a priori, but they will only start holding at some unknown time in the future. The partial synchronous model is a better model for the real world than either the synchronous or asynchronous model; networks function in a predicatable way most of the time, but occasionally go crazy.

Lamport and Gray went on to apply Paxos to the distributed transaction commit problem in “Consensus on Transaction Commit” (2005). They used Paxos to effectively replicate the TM of 2PC, and used an instance of Paxos for each RM involved in the transaction to agree whether that RM could commit the transaction. On the face of it, using an instance of Paxos per RM looks expensive, but it turns out that it is not. Paxos Commit will complete in two phases for the fault free case, ie it has the same message delay as 2PC, though more messages are exchanged. A third phase is only required if there is a fault, in accordance to the Skeen result. Given 2n+1 TM replicas Paxos Commit will complete with up to n faulty replicas. Paxos Commit does not use Paxos to solve the transaction commit problem directly, ie it is not used to solve uniform consensus, rather it is used to make the system fault tolerant.

Any argument that distributed transactions should not be used because 2PC is blocking is a void, because Paxos Commit addresses the blocking issue.

Recently there has been some discussion of the CAP conjecture: Consistency, Availability and Partition. The conjecture asserts that you cannot have all three in a distributed system: a system that is consistent, that can have faulty processes and that can handle a network partition.

We can examine CAP by equating consistency with consensus. For an asynchronous system we cannot reach consensus with one faulty process, FLP, so we cannot have consistency and availability for an asynchronous system!

Now take a Paxos system with three nodes: A, B and C. We can reach consensus if two nodes are working, ie we can have consistency and availability. Now if C becomes partitioned and C is queried, it cannot respond because it cannot communicate with the other nodes; it doesn’t know whether it has been partitioned, or if the other two nodes are down, or if the network is being very slow. The other two nodes can carry on, because they can talk to each other and they form a majority. So for the CAP conjecture, Paxos does not handle a partition because C cannot respond to queries. However, we could engineer our way around this. If we are inside a data center we can use two independent networks (Paxos doesn’t mind if messages are repeated). If we are on the internet, then we could have our client query all nodes A, B and C, and if C is partitioned the client can query A or B unless it is partitioned in a similar way to C.

For a synchronous network, if C is partitioned it can learn that it is partitioned if it does not receive messages in a fixed period of time, and thus can declare itself down to the client.

Paxos, Paxos Commit and HTTP/REST have been combined to build a highly available co-allocation system for Grid computing, details of which can be found here HARC, there are also more references in this paper: “Co-Allocation, Fault Tolerance and Grid Computing” (2006).

最近每天都和td同学艰难抉择吃什么，就差写个工具大时代、e世界、第三级、永和、真功夫排calendar或random了~~~  端午假期的最后一天，自己来做做春日小菜吧~~~

1.时蔬丸子汤

丸子汤一直是爸爸的拿手菜，也是我打小就特别钟爱的。到了北京，好吃的我，只能自己尝试一把啦~

–a.剁肉：肥瘦肉3：7的比例剁馅。tips：自己剁会比超市绞肉机绞出来的更筋斗和香嫩哦。我今天偷懒买的超市较肥一些的肉馅，自己加瘦肉剁的，呵呵。

–b.调馅：馅的味道才是家的味道。加盐、生粉、生抽（喜欢色深的同学们也可以用老抽）、胡椒、鸡精、料酒、美极鲜味汁、葱姜少许、一点点香油，捏匀。tips：朝一个方向捏匀，并略带摔打会丸子纤维充分融合，口感好哦。

–c.煮汤：凉水入锅，开火。加入少许香菇，开小到中火慢慢煮，可以将菇的鲜味慢慢融入汤中。稍后将一小个番茄切片加入，我特别喜欢这种鲜美的汤略加酸甜的滋味。

–d.下丸子：水开后，即可下丸子啦。将肉馅从大拇指和食指间穿过，用一个小勺舀起定型。这样既能保证丸子大小均匀，形状圆润，操作起来也很方便快捷。成型后直接将勺轻轻放入水中，便可继续下一个丸子了。稍注意的是在这期间需要火不宜太大，稍加搅拌，以免粘锅。煮到丸子慢慢变色浮起，加入小白菜（北京叫油菜），略煮熟关火。加入香油香喷喷起锅啦~~

2.黄瓜盅

昨天在一个订阅的美食博客上看到有这样一个江南小菜，觉得很是春天。今天试了一试，不属于懒人的菜，比较费时，黄瓜中的肉非常清香美味，但黄瓜蒸熟后我便不大喜欢，有人能推荐推荐改良的方法吗？呵呵~

–a.将黄瓜切成小段，用小刀挖空中部的瓤。

–b.将之前准备好的肉馅灌入，装盘。

–c.每个黄瓜上加入一丁丁香菇、一丁丁番茄配色。

–d.入锅蒸10分钟即好。

3. 培根炒蛋

这个菜非常简单，不过搭配起来口感和营养都很不错，值得推荐。

–a.两片培根切丁，加入打好的三个鸡蛋液中，加少许盐。

–b.热锅热油，小到中火，一般的煎蛋方法。tips：不要急着翻，会散也会不大漂亮。煎到一面快要都变成固体时，翻面。快熟时稍拨散即可。

4.凉拌毛豆

不知是我没发现还是怎样，在北京一直都没有发现好吃的毛豆。一般看到的都是黄黄的，盐水煮煮，丝毫没有武汉的毛豆风味。于是td同学每次看到毛豆卖都会买回来让我来找找武汉味道。今天没用热油浇，是简单做法。

–a.毛豆两面剪好。（55，武汉都有卖剪好的，北京可能不流行，每次都得自己剪了）

–b.烧水，煮毛豆，几分钟即好，我一般都是先偷吃着尝尝，呵呵。tips：烧的水中加盐和一两滴油一起煮，这样煮出来的毛豆不会发黄，翠绿且比较甜。

–c.加盐、生抽、醋、蒜泥、鸡精、辣椒油调味好。（喜欢吃花椒的同学可稍加花椒油）。加入煮好沥干的毛豆拌好即可。tips：另一种做法是将油烧热，浇入调好料的毛豆中，会更香。再冰镇一下，更美。

写过很多篇开篇语 多有很多美好的说辞

初三时的个人主页

高一时的网管委网站

高二时的班级网站

数不清的blog

还有数不清的喧华开版或各种活动开篇

今天这篇  它没什么特别  不在一个特别的日子 也没有特别的缘由

只是它的诞生  凝聚了我对自己的挑战

坚持坦诚认识自己

坚持input->output

坚持正确的做事和思考方式

坚持让每天的过往变得坚实有力量

希望一年、两年、n年后看来，发现它是那么平淡无奇却又铿锵有力