工作中学习【虎.无名】摘读空间

文章列表

您正在查看 "工作中学习" 分类下的文章

谭俊青:MySQL vs NoSQL 效率与成本之争,Memcached和MySQL

2010年10月14日星期四 10:16

http://www.mysqlab.net/blog/2010/03/mysql-vs-nosql/ MySQL vs NoSQL 效率与成本之争
2010年3月17日谭俊青发表评论阅读评论
最近Twitter、DIGG等计划换用基于key-value的NoSQL数据库(e.g:Cassandra)，之所以有如此动向是因为基于MySQL + sharding + cache的构架随着数据量爆炸式增长，重构的人力成本太高，换用扩展性更好的NoSQL数据库，以达到控制人力成本的目的，从而减少总体成本。
随着数据量和访问量的增长，网站构架大致有这么几个发展阶段(以PHP+MySQL+Memcached为例)：
1: PHP + MySQL
2: PHP + MySQL (Master + Slaves)
3: PHP + MySQL (Master + Slaves) + Memcached (Middleware) 【虎.无名：这里Middleware指什么？】
4: PHP + MySQL (Sharding + Master + Slaves) + Memcached (Middleware)
5: PHP + MySQL (Sharding + Master + Slaves) + Memcached (Middleware) + NoSQL
从上面的发展历程可以看出，随着复杂度的增加，开发难度和复杂性也随之提升，数据量增加之后每次重构需要的人力成本急剧增加，因此为了控制成本，增长重构的周期，将一些数据量庞大，增长快速的业务迁移至NoSQL上存储。
因此大家不必要言必NoSQL，NoSQL也不会取代MySQL，不同的业务有它最适合的低成本存储方式，最终选择什么数据库是由系统成本决定的。
http://www.mysqlab.net/blog/2010/03/memcached-and-mysql/ Memcached and MySQL
2010年3月1日谭俊青发表评论阅读评论
相信很多开发人员接触过memcached,而且我认识的朋友当中有的是经常使用。那么在结合数据库，在对数据库内容做缓存的时候什么情况下使用memcached却不甚了解。有些朋友问到MySQL有自己的Query cache，为什么还要用memcached？ –by ivan@mysqlab.net
MySQL为了效率考虑，不太可能将数据粒度分那么细，所以在对表更新的时候将清空所有涉及到这张表的qcache，这样的话，在更新频繁或者表记录数很大的情况，qcache的效率将大打折扣。而使用memcached一般都是针对单条记录，从而在更新的时候对表中其他记录的cache没有影响，相比qcache来说，cache效率极大提高。这也是为什么在MySQL有Query cache的情况下还要使用memcache来缓存数据。
不过结合MySQL和memcached使用需要app层配合。不过当前也有MySQL memcached UDFs，结合MySQL触发器trigger，可是实现MySQL数据库的内容跟memcached同步，这样可以避免不同的应用程序需要实现对memcached的管理。
MySQL memcached UDFs的下载地址：https://launchpad.net/memcached-udfs
shell> tar zxf memcached_functions_mysql-x.xx.tar.gz
shell> cd memcached_functions_mysql-x.xx
shell> ./configure –with-mysql=/usr/local/mysql/bin/mysql_config
shell> make
shell> make install
shell> cp /usr/local/lib/libmemcached_functions_mysql* /usr/local/mysql/lib/mysql/plugins/
mysql> CREATE FUNCTION memc_get RETURNS STRING SONAME "libmemcached_functions_mysql.so";
mysql> source /path/TO/install_functions.sql
详情请参考：http://dev.mysql.com/doc/refman/5.1/en/ha-memcached-interfaces-mysqludf.html

类别：工作中学习|评论(0) |浏览(846)

软件编程21法则【推荐】

2010年10月08日星期五 9:45

http://www.iwanna.cn/archives/2010/10/08/5507/ 任何一个有经验的程序员都知道，软件开发遵循着一些不成文的法则。然而，如果你不遵循这些法则也并不意味着会受到惩罚；相反，有时你还会获得意外的好处。下面的就是软件编程中的21条法则：
任何程序一旦部署即显陈旧。
修改需求规范来适应程序比反过来做更容易。
一个程序如果很有用，那它注定要被改掉。
一个程序如果没用，那它一定会有很好的文档。
任何程序里都仅仅只有10%的代码会被执行到。
软件会一直膨胀到耗尽所有资源为止。
任何一个有点价值的程序里都会有至少一个bug。
原型完美的程度跟审视的人数成反比，反比值会随着涉及的资金数增大。
软件直到被变成产品运行至少6个月后，它最严重的问题才会被发现。
无法检测到的错误的形式无限多样，而能被检测到的正好相反，被定义了的十分有限。
修复一个错误所需要投入的努力会随着时间成指数级增加。
软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。【软件复杂度==热力学的熵】
任何自己的程序，几个月不看，形同其他人写的。
任何一个小程序里面都有一个巨大的程序蠢蠢欲出。
编码开始的越早，花费的时间越长。【仔细设计？过度设计？持续设计？】
一个粗心的项目计划会让你多花3倍的时间去完成；一个细心的项目计划只会让你多花2倍的时间。
往大型项目里添加人手会使项目更延迟。【沟通的效率】
一个程序至少会完成90%，但永远完成不了超过95%。【行百里者半九十】
如果你想麻烦被自动处理掉，你得到的是自动产生的麻烦。
开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
用户不会真正的知道要在软件里做些什么，除非使用过。

类别：工作中学习|评论(0) |浏览(292)

【推荐】软件架构师应该知道的97件事 zt

2010年09月13日星期一 16:36

【虎.无名】参加2010系统架构师大会，无意中看到了这本书，觉得值得一看。

原文：http://news.csdn.net/a/20100429/218192.html 其他介绍：http://www.china-pub.com/196660 和 http://book.douban.com/subject/4745287/ 封面：http://hi.csdn.net/attachment/201004/5/1495234_12704394070BRP.jpg

软件架构师是IT 行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事，博文视点即将翻译出版的新书《软件架构师应该知道的97 件事》（97 Things Every Software Architect Should Know ）探讨的就是这个主题。本书的编辑Richard Monson-Haefel 是畅销书《 Enterprise JavaBeans 》和《 Java 消息服务》的作者。Richard 邀请五十多位杰出的软件架构师分享工作经验和观点，帮助读者少走弯路。其中不乏大家熟悉的名字：《卓有成效的程序员》的作者Neal Ford，《企业集成模式》的作者Gregor Hohpe， Servlets 和JSP 专家组和W3C RDF工作组技术专家Bill de hÓra，《 Web 应用程序快速开发：使用TurboGears 》的作者Mark Ramm，《 Release It! 》的作者Michael Nygard，《软件开发沉思录》的作者之一Rebecca Parsons 博士，活跃于Perl 社区的女架构师Allison Randal ，《 Java SOA Cookbook 》的作者 Eben Hewitt ，等等。

下面内容摘自该书的标题，并给出了必要的补充说明，由本书译者SeanBV（他的CSDN博客）整理，推荐给大家。

1． 客户需求重于个人简历（ Nitin Borwankar ）客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。

2． 简化根本复杂性，消除偶发复杂性（ Neal Ford ）分析问题好比拨云见月、水落石出。

3． 关键问题可能不是出在技术上（ Mark Ramm ）团队同心，其利断金。

4． 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格（ Mark Richards ）沟通应当言简意赅、详略得当，别拖泥带水。

5． 架构决定性能（ Randy Stafford ）种瓜得瓜，种豆得豆，架构设计也是一样道理。

6． 分析客户需求背后的意义 （ Einar Landre ）抽丝剥茧，洞见症结。不要被表面需求迷惑。

7． 起立发言（ Udi Dahan ）起立发言效果更好。

8． 故障终究会发生（ Michael Nygard ）应该提前设计预防措施，限制故障。【虎.无名：故障不可避免，它可能在任何时间，任何地点发生。】

9． 我们常常忽略了自己在谈判（ Michael Nygard ）工程师应该适时转换角色，学习谈判的技巧。

10． 量化需求（ Keith Braithwaite ）没有规矩，不成方圆。

11． 一行代码比五百行架构说明更有价值（ Allison Randal ）可工作的代码才是目标，设计只是达成目标手段。

12． 不存在放之四海皆准的解决方案（ Randy Stafford ）软件世界没有万能钥匙。【虎.无名：需要针对特定环境进行权衡。】

13． 提前关注性能问题（ Rebecca Parsons ）尽早展开性能测试。

14． 架构设计要平衡兼顾多方需求（ Randy Stafford ）平衡兼顾项目的技术需求和相关各方的业务需求。

15． 草率提交任务是不负责任的行为（ Niclas Nilsson ）要设法杜绝开发人员草率提交任务的念头。

16． 不要在一棵树上吊死（ Keith Braithwaite ）为客户提供多样化的解决方案。

17． 业务目标至上 （ Dave Muirhead ）技术决策不能脱离业务目标和现实条件的约束。

18． 先确保解决方案简单可用，再考虑通用性和复用性（ Kevlin Henney ）

19． 架构师应该亲历亲为 （ John Davies ）身先士卒才能赢得同事的信任。

20． 持续集成 （ David Bartlett ）

21． 避免进度调整失误 （ Norman Carnovale ）不惜一切代价拒绝调整项目进度的要求。

22． 取舍的艺术（ Mark Richards ）架构不可能满足所有需求。

23． 打造数据库堡垒（ Dan Chak ）一开始就要定义好数据模型。

24． 重视不确定性（ Kevlin Henney ）推迟决策，建设性地利用不确定性。

25． 不要轻易放过不起眼的问题 （ Dave Quick ）别忘了温水煮青蛙的故事。

26． 让大家学会复用（ Jeremy Meyer ）重复利用已有资源，首先要改变大家的观念。

27． 架构里没有大写的“I ” （ Dave Quick ）变让自己变成自大狂。

28． 使用“ 一千英尺高” 的视图（ Erik Doernenburg ）选择合适的架构视图。

29． 先尝试后决策（ Erik Doernenburg ）

30． 掌握业务领域知识（ Mark Richards ）

31． 程序设计是一种设计 （ Einar Landre ）软件开发也分成设计和生产两个阶段。

32． 让开发人员自己做主 （ Philip Nelson ）

33． 时间改变一切 （ Philip Nelson ）选择值得投入精力的工作，别跟以前的工作过不去。

34． 设立软件架构专业为时尚早 （ Barry Hawkins ）

35． 控制项目规模 （ Dave Quick ）

36． 架构师不是演员，是管家 （ Barry Hawkins ）别忘了你的工作责任。

37． 软件架构的道德责任（ Michael Nygard ）架构师的决定会影响许多人，务必慎重。

38． 摩天大厦不可伸缩（ Michael Nygard ）但软件可以。

39． 混合开发的时代已经来临（ Edward Garson ）

40． 性能至上 （Craig Russell ）

41． 留意架构图里的空白区域（ Michael Nygard ）空白区域“充满”了各种软件和“硬件”。

42． 学习软件专业的行话（ Mark Richards ）同行之间讲行话方便交流。

43． 具体情境决定一切（ Edward Garson ）【具体问题具体分析。】

44． 侏儒、精灵、巫师和国王（ Evan Cofsky ）开发团队不应该同质化。

45． 向建筑师学习（ Keith Braithwaite ）借鉴建筑行业的经验。

46． 避免重复（ Niclas Nilsson ）

47． 欢迎来到现实世界（ Gregor Hohpe ）现实世界比软件世界复杂。

48． 仔细观察，别试图控制一切（ Gregor Hohpe ）

49． 架构师好比两面神 （ David Bartlett ）架构师应该像两面神一样，眼观六路、耳听八方。

50． 架构师应关注边界和接口 （ Einar Landre ）寻找自然的边界，分而治之。

51． 助力开发团队（ Timothy High ）优秀团队是成功的保障，要尽量助力开发团队。

52． 记录决策理由（ Timothy High ）记录架构决策背后的理由，具有极高的投资回报价值。

53． 挑战假设, 尤其是你自己的（ Timothy High ）臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。

54． 分享知识和经验（ Paul W. Homer ）帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。

55． 模式病 （ Chad La Vigne ）不要让一展设计模式功力的欲望，遮蔽了务实的真知。

56． 不要滥用架构隐喻 （ David Ing ）不要耽溺于系统隐喻之中，反让它拖了后腿。

57． 关注应用程序的支持和维护 （ Mncedisi Kasper ）应用程序的支持和维护，永远都不应该是事后才考虑的事情。

58． 有舍才有得（ Bill de hÓra ）珍惜需要权衡的时机，远胜毫无约束和限制。

59． 原则、公理和类比胜于个人意见和口味（ Michael Harmer ）

60． 从“ 可行走骨架” 开始开发应用（ Clint Shank ）从“ 可行走骨架” 开始，增量培育系统成长。

61． 数据是核心（ Paul W. Homer ）从“数据是核心”这个角度去认识系统，能大大降低理解复杂度。

62． 确保简单问题有简单的解 （Chad La Vigne ）

63． 架构师首先是开发人员 （Mike Brown ）碰到麻烦时，架构师可不能只会干吹烟圈却束手无策。

64． 根据投资回报率（ROI ）进行决策（ George Malamidis ）

65． 一切软件系统都是遗留系统（ Dave Anderson ）软件很快便会过时，修改维护无可避免。

66． 起码要有两个可选解决方案（ Timothy High ）

67． 理解变化的影响（ Doug Crawford ）清楚认识变化类型及其影响。

68． 你不能不了解硬件（ Kamal Wickramanayake ）硬件容量规划，是和软件架构同等重要的事情。

69． 现在走捷径，将来需付息（ Scot Mcphee ）及时还清技术债务。

70． 不要追求“完美”，“足够好”就行（ Greg Nyberg ）避免过度设计。

71． 小心“好主意” （ Greg Nyberg ）

72． 内容为王（ Zubin Wadia ）

73． 对商业方，架构师要避免愤世嫉俗（ Chad La Vigne ）

74． 拉伸关键维度，发现设计中的不足（ Stephen Jones ）

75． 架构师要以自己的编程能力为依托（ Mike Brown ）

76． 命名要恰如其分（ Sam Gardiner ）弄清楚要做的究竟是什么。

77． 稳定的问题可以获得高质量的解决方案（ Sam Gardiner ）

78． 天道酬勤（ Brian Hart ）真正做好那些看似简单的任务，坚守承诺。

79． 对决策负责（ Yi Zhou ）

80． 弃聪明，求质朴（ Eben Hewitt ）

81． 精心选择有效技术，绝不轻易抛弃（ Chad La Vigne ）

82． 客户的客户才是你的客户！（ Eben Hewitt ）

83． 事物发展总会出人意料（ Peter Gillard-Moss ）设计是在不断变化的世界中持续进行探索试验的过程。

84． 选择彼此间能和谐共处的框架（ Eric Hawthorne ）当心“无所不能”型的框架。

85． 着重强调项目的商业价值（ Yi Zhou ）

86． 不仅仅只控制代码，也要控制数据（ Chad La Vigne ）

87． 偿还技术债务（ Burkhardt Hufnagel ）在速度和架构间进行权衡，保持平衡。

88． 不要急于求解（ Eben Hewitt ）首先看看是否可以改变问题。

89． 打造称手的系统（ Keith Braithwaite ）

90． 找到并留住富有激情的问题解决者（ Chad La Vigne ）

91． 软件并非真实的存在（ Chad La Vigne ）虚拟世界中的软件是柔韧可变的。

92． 学习新语言（ Burkhardt Hufnagel ）防止沟通不畅和误解。

93． 没有永不过时的解决方案（ Richard Monson-Haefel ）

94． 用户接受度问题（ Norman Carnovale ）减轻用户接受度问题带来的风险。

95． 清汤的重要启示（ Eben Hewitt ）软件架构设计需要不断的精炼浓缩。

96． 对最终用户而言，界面就是系统（ Vinayak Hegde ）

97． 优秀软件不是构建出来的，而是培育起来的（ Bill de hÓra ）

类别：工作中学习|评论(0) |浏览(424)

cassandra观止(硬盘是磁带,bloom-filter,Gossip)含附件；详解Cassandra写操作

2010年06月23日星期三 13:59

http://blog.nosqlfan.com/html/51.html cassandra观止
【附cassandra开发者pdf讲搞：cassandra_nosql】

cassandra是由facebook开发的一套NoSQL存储引擎，也是目前最火的NoSQL应用之一，目前twitter和digg中都有使用。当然，用得最多的还是facebook自己。cassandra的特性不同的人理解不一样，归纳起来有如下几点：

分布式，集群下容错性高，无限水平扩展性
schema的灵活控制，随意增删字段
支持范围查询
基于gossip的p2p节点通信
充分利用硬盘高效的顺序读写

然而本文想要描述的是cassandra系统中包含的一些令人眼前一亮的技术实现上的思想。

1.硬盘是新的磁带

“内存是新的硬盘，硬盘是新的磁带”这是Jim Gray的一句名言。我们目前对硬盘（非SSD）的利用，多是随机读取，这时的硬盘读取速度是相当慢的，但是如果把硬盘当成磁带进行顺序读取的话，速度是相当惊人的。而cassandra的设计恰恰是冲着这一点来的，他在内在中保存一定量的数据后再统一写入磁盘，这本身就是一次顺序写入，在写入后不再进行更改，这样在进行数据读取时，就可以只进行一次次的顺序读取即可。大大提高了磁盘的效率。如果cassandra不更改数据，那数据的update操作又是如何实现的呢，cassandra采用的是追加方式，再写一条信息，取的时候取出对这个数据的所有操作再根据时间顺序进行案件重演就可以算出最新的数据是什么了。

2.bloom-filter算法的应用

bloom-filter算法简单来说就是判断一个值是否存在于一个集合中的算法，用得最多的是在搜索引擎的URL抓取中，如果这个URL在一段时间抓取过的URL列表中，那就不再进行抓取。这个算法的时间和空间复杂度都很小，基本每一个数据的判断只需要做几次hash就可以了，但是问题是有一定的误差，只要应用可接受这个误差，那使用bloom-filter算法是最好的。

bloom-filter在cassandra用来判断一个数据块中是否有一个值的更新，上面说到，我们在读取数据时，是将其更新记录全部读取再通过时间顺序排序得到最新值。而cassandra每次内存存储上限（这个可以自由设置，但为了保证效率，通常低于物理内存）到时都会将内在中的数据写入硬盘，生成一个新的文件。于是在数据量很大时，会有很多个块生成，我们如果所有块都去查找是否有某一个值的更新记录，是会浪费时间降低效率的，于是cassandra用bloom-filter算法来决定是否对这个块进行查找，cassandra中的index.db文件就是存储bloom-filter算法的hash表的。

我们上面也说过，bloom-filter算法会有一定误差，但是这个误差是可能会将不在一个集合中的值误判为在这个集合中，而不会将在这个集合中的值误判为不在这个集合中，有点杀三千不放一个的意思。这个误差在这里是可以忍受的，因为我们可以多查一个不存在这个值的数据块，但是决不会漏掉任何一个。

3.基于gossip的多点同步

gossip是一个p2p协议的实现，他的原理是向周围的节点传递信息，直到所有节点都有同样的信息，这种传播是病毒式的。通过这种方式，可以达到多点同步，并且可以不用关心具体节点量实现无限水平扩展的功能。而且多点分布式系统有很好的容错机制，集群中的一台或N台机器出问题，不会对整体数据服务的正确性造成影响。而cassandra的错误侦测系统也能很快的发现坏死的结点以便及时处理。

and more….

本文只讲述了令作者受到启发的技术点，抛砖引玉，欢迎提出更多不同的见解。

http://database.51cto.com/art/201005/202919.htm 详解Cassandra数据库的写操作

我们已经开始在OneSpot使用Cassandra来作为我们下一代的存储引擎(使用一个EC2的机器集群代替一台非常大的PostgreSQL机器),因此,之前几周的时间我一直在使用Cassandra. 由于我本人是一个基础设施方面的书呆子,并且坚信需要理解系统堆栈的各个层面,因为我阅读了部分关于Cassandra如何工作的资料,并且想写出点总结以期对后来者有所帮助.由于Cassandra的写性能表现卓越这一点众所周知,我认为我的介绍应该由此开始.

需要理解的第一件事是,Cassandra最好运行在多台机器上.据我所知,Twitter使用了一个45台机器组成的集群.在一台机器上运行Cassandra可能不是很有意义,因为你将失去没有单点故障的系统的优势.

客户端向一个随机的Cassandra节点发出一个写请求.这个节点作为代理往集群写入数据.节点的集群存储在一个节点”环”上,写会按照复制放置策略(replication placement strategy)复制到N个节点上.当使用RackAwareStrategy策略时,为了保证可靠性(reliability)与可用性(Availability), Cassandra会按照复制节点到当前节点的距离将复制节点分为3个桶:与当前节点位于同一机架、与当前节点位于同一数据中心、或位于不同的数据中心.你配置了Cassandra写数据到N个节点来做冗余,Cassandra会将第一份拷贝写入到此数据的主节点,第二份拷贝到环上的位于另一个数据中心的节点,剩余的其它拷贝到与代理节点位于同一个数据中心的机器上.这样就可以确保单点故障不会导致整个集群不可用,即使在整个数据中心都不可用时集群仍然保持可用.

因此,写请求从你的客户端出发到单一随机节点,此节点根据复制放置策略将写操作发送到N个不同的节点.我没有在此讨论很多边缘用例极端情况(节点宕机、集群中新增节点、等等),但是,节点需要等待N个节点返回成功并返回成功给客户端.(此处的描述有问题,Cassandra中,还有另外一个W的参数,也就是需要等待几份写拷贝成功才返回成功给客户端,译者加).

节点中的每一个都会以”RowMutation”消息的形式接收到此写请求.对于此消息,节点会采取以下两种行动:

◆追加此变更到提交日志(Commit log)以满足事务性目的

◆使用此变更修改一个内存内的Memtable 结构

它的工作就此结束.这就是为什么Cassandra的写操作如此快的原因:最慢的部分就是追加变更日志到文件的操作.与关系型数据库不同的是,Cassandra不会修改存储在磁盘上的数据,也不会去更新索引,因此没有密集的同步磁盘操作来阻塞这次写操作.

还有多个定期发生的异步操作:

◆当Memtable结构数据满的时候需要写入到SSTable,一个基于磁盘的结构,因此我们不会有太多只存在于内存的数据.

◆每个给定列族(ColumnFamily)的一组临时的SSTable会被合并到一个大的SSTable.此时,临时的SSTable就没有用了,它们会在将来的某个时间点被当作垃圾回收掉.

还有大量的边缘用例极端情况与复杂情况,我都没有在此讨论,我强烈建议大家至少要去阅读下Cassandra维基(Wiki)中关于ArchitectureInternals与Operations的相关描述.分布式系统相当复杂,Cassandra也不例外.

如果有发现错误或想要添加更多细节请留下意见,我不是Cassandra的开发者,因此我确定一定有1-2处的错误隐藏其中.

【编辑推荐】

类别：工作中学习|评论(0) |浏览(1764)

敏捷开发，敏捷宣言（转）：Waterfall vs Agile图

2010年06月17日星期四 13:25

http://codedestiny.javaeye.com/blog/618447 敏捷开发之 4句敏捷宣言（转）

敏捷开发之热门已达到任何一个开发人员都至少听过，并觉得敏捷方法很好，然而并不是所有的人都学习和实践过，以致于大家谈敏捷的时候其实理解的基准是不一样的，也导致“敏捷”泛滥成灾“，有些看似很敏捷的开发其实并不敏捷。

　　最近在一个项目中准备采用Scrum开发方法来解决以往开发方法中遇到的一些问题，所以近期将发表一些个人对敏捷的一些看法，欢迎和大家交流。

　 过程与工具、面面俱到的文档、合同谈判、遵循计划

　　　　　个体与交互            胜过过程与工具
　　　　　　    　可以工作的软件胜过面面俱到的文档
　　　　　　　　客户协作           胜过     合同谈判
　　　　　　　　响应变化               胜过     遵循计划

　　2001年2月由17位世界轻量级方法学家提出了一份敏捷联盟宣言 ，这个宣言只是简单的四句话，但却是敏捷方法的精髓，在谈敏捷方法之前就必须先对敏捷宣言有所理解。在和一些人员交流中，我发现大家都知道敏捷，但是能说出这个简单的敏捷宣言的并不多，都说当时知道，过了一阵子就忘记了。究其原因是靠死记硬背是不行的，需要通过自己的思考形成自己的理解才能够真正记住。上面的敏捷宣言非常简单，仅仅四句话而已，有的项目会出现上面这个漫画所描述的状况，领导说“我们开始尝试使用一种叫做敏捷的方法了，这就代表不再需要计划并且不再需要文档，只需要开始编码”。这其实就是简单记住敏捷宣言的几个字而出现的严重误解，下面我将对这四句话进行解释，希望大家跟随我的讲解也能对这个宣言有所认识。

　合同谈判　　

　　项目开发一般都是跟随着合同开始的。由客户经理同客户交谈，在合同中确定一些法律条文以及交付产品包含的功能，然后客户经理拿着合同回到公司由开发小组经过长时间开发后再交付给客户。在开发期间，如果需要变更合同，则需要经过一系列流程。开发过程中，有些客户可能只是简单的询问一下进度，有的甚至是到最后交付日了直接来问你要东西，当产品不能满足合同规定时就需要和客户谈判进行解决。仅仅通过合同谈判来开发产品，客户在开发过程中就不会进行实质性的反馈，导致最终的产品不满意也就很正常了。

　产品开发在早期市场不成熟的时候一般为公司领导（产品经理、LPDT）驱动，后期转变为用户驱动、销售驱动、服务驱动，在矩阵式管理模式下，产品事业部和开发管理部作为两个部门时，在做产品开发的时候就会类似在进行合同谈判，从一开始就会在两个部门之间产生争执而不是合作，这势必会影响产品的开发。

　　遵循计划

　　当拿到合同时，公司就开始组建项目组进行开发。此时需要项目经理制定出明确的计划，必须详细列出需求、设计、开发、测试、部署的各项任务。当项目组提交看似完整齐全的计划后，公司就视这个不变的计划作为项目组对公司的承诺，没有特殊情况时必须遵循制定的计划，如果想要变化，则需要经过公司评审。

　　软件复杂度有三个主要因素：业务、技术和人员。

　　关于业务和技术的关系我已经写了一些博文，有兴趣的可以去看看（从横向领域和纵向领域来谈业务和技术的关系）

《agile project management with scrum》（中文书名：Scrum敏捷项目管理）一书中有一个复杂度的图。

X轴表示技术（成熟度），Y轴表示业务（一致度）。从图中可以看到，业务和技术是正交的，各自对复杂度都有影响，我们在开发过程中需要做的通过各种办法尽量确保从Anarchy－Complex－Complicated－Simple进行转移。

技术和业务最终都需要人来执行，而每个人拥有不同的技能、经验和观点，当这些人在一起合作时又会使得开发过程变得复杂。

这些复杂性将导致开发过程中存在很多不确定性，所以项目初期制定的计划其实基本上不能真正的坚持下来。而当项目开发遇到困难时，项目组可能会为了表明自己做计划的能力，或者不想经历复杂的变更过程，而继续努力的坚持这个已经错误的计划。范围、时间和成本，这个金三角几乎没有领导不知道，而项目组为了保证”遵循计划“，对外宣称项目组运行状况良好，保证当前人员在预计时间肯定能保质保量的完成开发。而代码质量只有开发人员知道，领导们容易忽略和难以控制这个环节，所以最后一味的遵循计划就势必导致提供给客户的是一个不满意的产品。

　　过程与工具

　　计划制定后，项目组需要在类似ISO9000、CMMI、NPD等一些常用的项目管理方法下进行开发管理。工欲善其事，必先利其器，可以找到很多工具来支持开发，需求阶段有原型工具、需求管理跟踪工具，设计阶段有Rose、PD，开发阶段有各种IDE和辅助插件，测试阶段有TD等。

　　合适的工具能很好的帮助开发，但当在开发人员面前出现大量庞大笨重甚至不好用的工具和开发环境时，就会像缺少工具一样，都是不好的。在开发过程中，可能会出现夸大了工具的作用,当反应说开发工具对开发起起决定性的影响时，这很有可能是在计划阶段就开始错了，就像衣服扣错的时候，一般都是扣第一个扣子的时候，而不是你发现扣错的那个扣子。

　　面面俱到的文档

　　瀑布式开发下，文档承载着各阶段之间的信息传递。需求文档中定义详细用例，每个细节，原型中定义界面表现，甚至每个控件的具体位置，设计中的 UML图，数据库设计图，测试用例文档等等，如果没有文档，开发将不能在过程中顺利依次展开。

　　编写和维护一份详尽的需求文档总是一个好主意，然而就像前面所说业务复杂性带来的不确定性，除非给我们充足的时间，否则我们不可能一开始就想清楚所有细节。另一方面，编写文档需要花费大量的时间，如果考虑和代码的同步时，工作量更是急速上升，如果不考虑同步时，过多的文档反而比过少的文档还糟。当我们花大部分时间浪费的文档，仍旧只能以降低质量来遵循计划的执行。

Waterfall VS Agile

　在一个ppt中看到一张Waterfall和Agile对比的图。

瀑布式开发是计划驱动的，合同谈判后项目组制定计划并且遵循计划 ，在过程与工具 支持下通过面面俱到的文档来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。

而敏捷开发是价值驱动，通过自组织团队 在短期迭代 过程中不断的交付对用后有用的功能来进行产品开发。

从上图的正反三角形图形可以看出两者的驱动是不同的，虽然宣言中右项（ 过程与工具、面面俱到的文档、合同谈判、遵循计划）也很有价值，但是我们认为左项（ 个体与交互、可以工作的软件、客户协作、响应变化 ）更有价值，同时为了防止有些人学了敏捷之后而认为右边的没有价值了，我会在每条说明后重申一下右边的仍旧需要。以下我将继续对敏捷宣言中的左项内容进行解释。

个体与交互、可以工作的软件、客户协作、响应变化

　　　      个体与交互      胜过过程与工具
　　　　　　   　可以工作的软件胜过面面俱到的文档
　　　　　　　　客户协作             胜过     合同谈判
　　　　　　　　响应变化               胜过     遵循计划

　　客户协作胜过合同谈判

　　寻求客户合作的价值重于对合同的谈判。软件开发的最终目标是提供给客户满意的软件，而只有客户才更清楚怎么样才能满意，敏捷开发提倡客户和开发团队密切的在一起工作，并尽量经常行得提供反馈。各种不同的敏捷方法都会利用短期迭代，通过尽早提供软件来达到与客户频繁沟通和反馈的，这也可以把问题及早暴露出来，以免隐藏的问题在后期造成更大的影响。

　　虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。

响应变化胜过遵循计划

　　计划赶不上变化，敏捷项目承认开发过程中的不确定性，所以不会在开发中制定长时间的复杂计划，它们的成功都是建立在现实反馈的基础上的。 Scrum依照一组简单实践及规则，实施经验性过程控制方法的检查、适应和保证可视性等步骤，处理软件开发项目中的复杂问题。通过迭代开发，每次迭代都是基于上一迭代的完善基础之上进行的，通过不断的响应变化来消除开发中的不确定性。

　　虽然我们致力于响应变化，但并不是像上面漫画所说的不需要计划了,反而我们需要更多的规划。

　　《Agile Estimating and Planning》（中文书名：敏捷估计与规划）一书对如何做规划进行详细的讲解。它认为规划是困难的，而且作出的计划常常会出错，面对这样的问题，开发小组往往会走上两个极端：要么根本不做任何规划，要么在计划中投入大量的精力直到自己确信计划是正确的。不做规划的小组对一些最基本的问题，例如“你们什么时候能完成？”以及“我们可以在6月份安排产品发布吗？”都无法回答。而做了大量计划的小组会自欺欺人地认为某个计划是“正确的”。他们的计划也许更全面，但这并不一定意味着它更准确或更有用。这两种极端都是敏捷需要避免的，最开始漫画所说的“我们实施敏捷，不再需要计划和文档了”的论调是及其错误的。

　　敏捷不是不需要计划，相反它需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。

个体与交互胜过过程与工具

　　方法和工具是死的，人是活的，如何没有优秀个人和团队协作，再强大的方法和工具都是摆设。一个使用普通工具的优秀人员会比使用优秀工具的普通人员做得更好，一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径解决开发过程中遇到的问题。

　　虽然我们致力于个体和交互，但并不是不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程，每日构造等敏捷实践也需要工具的支持，需要哪些过程和工具由自组织团队制定，而不是由领导制定。

可以工作的软件胜过面面俱到的文档

在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档，支付多少金额等内容，而这些文档对用户来说是不是真的有价值呢？面面俱到的文档对客户来说确并不重要，用户需要的是一个能够运行起来，能够实质解决工作中问题的可以工作的软件。面面俱到的文档对开发团队也不重要，上百页的报告没有人愿意写，更没有人愿意去读，对开发团队来说最好的两份文档就是代码和团队。通过频繁的提供可以工作的软件，我们也可以更为频繁的搜集对产品和开发过程的反馈，保证开发小组始终是在处理最具有价值的功能，而且这些功能可以满足用户的需要。

　　虽然我们致力于提供可供做的软件，但并不是不要文档。我们在开发过程中仍然需要进行内部交流，也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求和算法，只要自组织团队认为足够就行了。

　　　　个体与交互         胜过过程与工具
　　　　　　   　可以工作的软件胜过面面俱到的文档
　　　　　　　　客户协作               胜过     合同谈判
　　　　　　　　响应变化             胜过     遵循计划

　　这四句价值观用语句表达就是：

　　　　自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件

　　胜过

　　　　与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求

类别：工作中学习|评论(0) |浏览(969)

Beta技术沙龙（霍炬）讲银杏搜索利用SNMP作服务监控的系统实现

2010年06月03日星期四 14:44

Beta技术沙龙，霍炬讲银杏搜索利用SNMP作服务监控的系统实现。
http://club.blogbeta.com/ BETA技术沙龙
http://club.blogbeta.com/2009/08/beta%E6%8A%80%E6%9C%AF%E6%B2%99%E9%BE%99%E7%AC%AC%E4%B8%83%E6%9C%9F%E5%A4%A7%E8%A7%84%E6%A8%A1%E8%BD%AF%E4%BB%B6%E6%9C%8D%E5%8A%A1%E7%9B%91%E6%8E%A7%E5%92%8C%E7%AE%A1%E7%90%86%E6%96%B9%E6%B3%95/ [beta技术沙龙第七期]大规模软件服务监控和管理方法
http://blog.devep.net/virushuo/2009/05/08/custom-snmp-by-agentx.html 在你自己的软件中应用snmp和agentx协议传递信息（作者：virushuo 发表于 2009-05-08 01:05 最后更新于 2009-05-08 01:05）
http://blog.devep.net/virushuo/2009/08/28/betasnmp_1.html beta技术沙龙的snmp话题的个人总结
http://joyfire.spaces.live.com/blog/cns!502060A314B1A145!2560.entry 2009/8/24 Beta技术沙龙：利用SNMP进行服务监控
http://www.faqs.org/rfcs/rfc2741.html RFC2741 - Agent Extensibility (AgentX) Protocol Version 1

在你自己的软件中应用snmp和agentx协议传递信息

作者：virushuo 发表于 2009-05-08 01:05 最后更新于 2009-05-08 01:05
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。
http://blog.devep.net/virushuo/2009/05/08/custom-snmp-by-agentx.html

我曾经想自己写一个udp server来接受我的服务器程序发回来的状态，然后做跟踪和统计。后来被Fenng批评为自己重复造轮子。于是转向试图利用snmp协议来做。

用snmp有几个原因：

1 snmp是基于udp协议的，具有udp的所有好处(数据状态这种东西，用tcp是不合适的)
2 snmp比较成熟，周边的软件非常多，后面可以很方便的处理收集数据，绘图等等一系列的功能。(rrdtool/cacti....)
3 因为我们要监控的服务非常多，所以希望能设计一个尽量免配置的方案，snmp的树型结构正好获取节点下面所有的被监控值。
snmp在网管系统中有很大规模的应用，但是似乎没什么人用来监控软件服务。而，目前我们知道的对snmp和cacti的应用，似乎大部分都只停留在了用来监控服务器状态(mem,load average,net io,disk)上，有点可惜。在这篇blog里面，我提到的用法应该不是最正宗的，但是有效。其实很多大厂商甚至自己修改snmp协议，做出自己的分支协议来。比起他们，虽然我做的不太正宗，但是也不为过。

我要实现的东西大概可以用这张图来描述：

概括起来：很多个服务分布在很多台机器的很多个端口，所以我们需要在每台机器上放一个snmp代理，得到他们的状态，然后再统一通过snmp协议获取这些状态。由于服务太多了，必须要免于配置，这就更显示出了snmp协议的优点。

扩展snmp有几种方法，不过综合起来，我认为最简单和灵活的还是agentx协议。agentx完全是独立在snmp server之外的，可以一层层的套起来。其他的协议要么要在snmp上加东西，要么要写mib的模块文件，都相当麻烦。

不过，最常用的snmpd，反而对agentx支持不好。至少他们自称还是试验性质，不建议用。我试图在snmpd.conf中允许agentx协议，也几经挫折。最终决定找别的方案。似乎大家都习惯把snmpd当作唯一的snmp server，其实类似产品还有很多，snmpd时间比较久，但我认为并非最好的。在ubuntu的apt源里面，都有几种其他方案可用。

当然，由于我并非希望取得系统的硬件状态，所以我也并不一定要找一个通用的产品。所以最后我决定用jagentx(http://eden.dei.uc.pt/agentx/)。

jagentx实现了snmp v1 协议和agetnx协议，一般来说足够用了。他们网站首页的那张图，很好的说明了agentx方式的系统结构。

jagentx提供了比较友好的api和demo，不过还是有一些bug，我做了一些修改。

1 jagentx的master(相当于server)，对于master mib的读取，只能支持snmpwalk，不能支持snmpget。其实是一个状态设置错了。
在 Master_Engine.java中

if (!any_subagent_queried){
int error_index = 1;

int error_status = Pdu.NO_SUCH_NAME;

后面，加上

if(value != null)
{
error_status = Pdu.NO_ERROR;
}
就可以了。

2 是关于session的。如果客户端退出，没有注销，就要等自己的session超时，不然连不上。这个在实际应用中很容易出问题。服务不正常退出的情况发生几率很高。于是我做了一些改动，可以通过sessionid来注销其他进程。这样确实会造成一些安全问题。不过可以用防火墙或是其他方式弥补。总比之前要等超时好。
改动的地方分布在几个文件里面，就不挨个列举了。

本来我给jagentx的开发者发了个邮件，告诉他这些改动，不过被退信了。所以我就把代码放这里，有需要的可以下载。

修改了这两处之后，这个东西很就好用了，jagetnx网站上的文档有demo代码，可以参考。

为了让我的山寨服务器正规点，我还是去申请了一个enterprise number。申请的方法是到iana 的申请页面添一张简单的表格，几天之后能收到回复，如果顺利通过，就会分配你一个数字号码，以后这个号码的snmp消息就代表你的组织的了。全部企业的enterprise number可以在http://www.iana.org/assignments/enterprise-numbers 这个页面查到(很大的文本文件)。可以看到，我们的银杏搜索ginkgotek是33364。

所以我们的snmp消息就在1.3.6.1.4.1.33364这个节点下面，我用snmpwalk就可以获得所有节点，包括新增的，这样就达到了免配置的目的。当然，到目前为止，我们还只是自己用于服务监控。
一切就绪之后，就可以选择你喜欢的工具来收集监控数据和画图了。比如常见的cacti。

这里是一张隐去了部分信息的cacti做出来的图。数据是从前面写到的这套东西收集上来的。

总结起来，这种办法适应于:

1 你有一个长期需要稳定运行的服务程序，否则你根本不需要监控

2 该程序有大量实例在运行，否则你用脚本把数据输出到snmpd都可以，没必要和我一样希望免配置

3 你不希望通过http或tcp连接来干扰该程序运行，否则你没必要用udp

写完了这篇blog，我也很希望能够侧面证明ginkgotek在保护客户利益上做的比别人多一些，选择我们的服务是可以放心的。

类别：工作中学习|评论(0) |浏览(357)

BFT(Byzantine Fault Tolerance)拜占庭容错（论文集）

2010年05月18日星期二 9:23

《程序员2009.5》可扩展性的艺术
http://www.hfadeel.com/Articles.htm
》http://www.hfadeel.com/Blog/Files/ArtofDistributed.pdf 【Art of Distributed Computing】
》http://www.hfadeel.com/Blog/Files/ArtofDistributed.pdf   【Art of Scalability - How we can design High Scalable Web Application】
》http://www.hfadeel.com/Blog/Files/ArtofDistributed.pdf   【The Graph - Graph On Hash】
》http://highscalability.com/ High Scalability
http://www.hfadeel.com/Blog/
》》Scalability, Availability & Stability Patterns. 【强烈推荐】http://s3.amazonaws.com/ppt-download/scalabilitypatterns20100510-100512004526-phpapp02.pdf?Signature=5xDZgcrYCYqwwix7ztVflEBffCo%3D&Expires=1274067263&AWSAccessKeyId=AKIAJLJT267DEGKZDHEQ
》》Horizontal Scalability via Transient, Shardable, and Share-Nothing Resources.
》》Scalability of the Hadoop Distributed File System.
》》Cassandra by Example. 【推荐Twitter简化】http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/#
----------------------------------------------------------------------------
【论文集】http://www.pmg.csail.mit.edu/bft/ BFT - Practical Byzantine Fault Tolerance

Publications:

2009

“Tolerating Latency in Replicated State Machines”
by Benjamin Wester, James Cowling, Edmund B. Nightingale, Peter M. Chen, Jason Flinn, and Barbara Liskov.
In Proceedings of the Sixth Symposium on Networked Systems Design and Implementation (NSDI), (Boston, Massachusetts), Apr. 2009.
Details. Download: pdf.

2008

“Detecting and Tolerating Byzantine Faults in Database Systems”
by Ben Vandiver.
Ph.D. dissertation, MIT, June 2008. Also as Technical Report MIT-CSAIL-TR-2008-040.
Details. Download: pdf.

“Computing Network Coordinates in the Presence of Byzantine Faults”
by You Zhou.
Masters thesis, MIT, (Cambridge, MA, USA), June 2008. Also as Technical Report MIT-CSAIL-TR-2009-015.
Details. Download: pdf.

2007

“Tolerating Byzantine Faults in Database Systems using Commit Barrier Scheduling”
by Ben Vandiver, Hari Balakrishnan, Barbara Liskov, and Sam Madden.
In Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP), (Stevenson, Washington, USA), Oct. 2007.
Details. Download: pdf.

“HQ Replication”
by James Cowling.
Masters thesis, MIT, May 2007.
Details. Download: pdf.

“HQ Replication: Properties and Optimizations”
by James Cowling, Daniel Myers, Barbara Liskov, Rodrigo Rodrigues, and Liuba Shrira.
MIT Technical Report MIT-CSAIL-TR-2007-009, (Cambridge, MA), Feb. 2007.
Details. Download: pdf.

2006

“HQ Replication: A Hybrid Quorum Protocol for Byzantine Fault Tolerance”
by James Cowling, Daniel Myers, Barbara Liskov, Rodrigo Rodrigues, and Liuba Shrira.
In Proceedings of the Seventh Symposium on Operating Systems Design and Implementations (OSDI), (Seattle, Washington), Nov. 2006.
Details. Download: pdf, html.

“Tolerating Byzantine Faulty Clients in a Quorum System”
by Barbara Liskov and Rodrigo Rodrigues.
In Proceedings of the 26th IEEE International Confererence on Distributed Computing SYstems (ICDCS06), (Lisbon, Portugal), July 2006.
Details. Download: pdf .

2005

“Byzantine Clients Rendered Harmless”
by Barbara Liskov and Rodrigo Rodrigues.
MIT Technical Report MIT-CSAIL-TR-2005-047, (Cambridge, MA), July 2005.
Details. Download: pdf .

2004

“Reconfigurable Byzantine-Fault-Tolerant Atomic Memory”
by Rodrigo Rodrigues and Barbara Liskov.
In Twenty-Third Annual ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing (PODC), (St. John's, Newfoundland, Canada), July 2004. Brief Announcement.
Details. Download: ps, pdf .

“Authentication in a Reconfigurable Byzantine Fault Tolerant System”
by Kathryn Chen.
Masters thesis, MIT, July 2004.
Details. Download: pdf .

“Byzantine Modification Detection in Multicast Networks using Randomized Network Coding”
by Tracey Ho, Ben Leong, Ralf Koetter, Muriel Médard, Michelle Effros, and David Karger.
In Proceedings of the 2004 IEEE International Symposium on Information Theory (ISIT), June 2004.
Details. Download: pdf, ps.

“Byzantine Fault Tolerance in Long-Lived Systems”
by Rodrigo Rodrigues and Barbara Liskov.
In 2nd Bertinoro Workshop on Future Directions in Distributed Computing (FuDiCo II), (Bertinoro, Italy), June 2004. Also as Technical Report MIT-LCS-TR-962.
Details. Download: ps, pdf .

2003

“BASE: Using Abstraction to Improve Fault Tolerance”
by Miguel Castro, Rodrigo Rodrigues, and Barbara Liskov.
ACM Transactions on Computer Systems (TOCS), vol. 21, no. 3, Aug. 2003.
Details. Download: abstract.

2002

“Practical Byzantine Fault Tolerance and Proactive Recovery”
by Miguel Castro and Barbara Liskov.
ACM Transactions on Computer Systems (TOCS), vol. 20, no. 4, Nov. 2002, pp. 398-461.
Details. Download: abstract.

“The Design of a Robust Peer-to-Peer System”
by Rodrigo Rodrigues, Barbara Liskov, and Liuba Shrira.
In 10th ACM SIGOPS European Workshop, (Saint Emilion, France), Sep. 2002.
Details. Download: ps, pdf, ppt.

2001

“BASE: Using Abstraction to Improve Fault Tolerance”
by Rodrigo Rodrigues, Miguel Castro, and Barbara Liskov.
In 18th Symposium on Operating Systems Principles (SOSP), (Banff, Canada), Oct. 2001. Best paper award.
Details. Download: ps, pdf, ppt.

“Byzantine fault tolerance can be fast”
by Miguel Castro and Barbara Liskov.
In International Conference on Dependable Systems and Networks (DSN), (Goteborg, Sweden), July 2001, pp. 513-518.
Details. Download: pdf.

“Using Abstraction to Improve Fault Tolerance”
by Miguel Castro, Rodrigo Rodrigues, and Barbara Liskov.
In 8th Workshop on Hot Topics in Operating Systems (HotOS-VIII), (Elmau/Oberbayern, Germany), May 2001.
Details. Download: ps, pdf.

“Combining Abstraction with Byzantine Fault Tolerance”
by Rodrigo Rodrigues.
Masters thesis, MIT, May 2001. Also as Technical Report MIT-LCS-TR-850.
Details. Download: ps, pdf .

“Practical Byzantine Fault Tolerance”
by Miguel Castro.
Ph.D. dissertation, MIT, Jan. 2001. Also as Technical Report MIT-LCS-TR-817.
Details. Download: ps, pdf .

“A Scalable Byzantine Fault Tolerant Secure Domain Name System”
by Sarah Ahmed.
Masters thesis, MIT, Jan. 2001. Also as Technical Report MIT-LCS-TR-849.
Details. Download: pdf .

2000

“Proactive Recovery in a Byzantine-Fault-Tolerant System”
by Miguel Castro and Barbara Liskov.
In Fourth Symposium on Operating Systems Design and Implementation (OSDI), (San Diego, USA), Oct. 2000.
Details. Download: pdf, ps, html.

1999

“Authenticated Byzantine Fault Tolerance Without Public-Key Cryptography”
by Miguel Castro and Barbara Liskov.
MIT Technical Memo MIT-LCS-TM-589, June 1999.
Details. Download: ps, pdf .

“A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication Algorithm”
by Miguel Castro and Barbara Liskov.
MIT Technical Memo MIT-LCS-TM-590, June 1999.
Details. Download: ps, pdf .

“Practical Byzantine Fault Tolerance”
by Miguel Castro and Barbara Liskov.
In Third Symposium on Operating Systems Design and Implementation (OSDI), (New Orleans, Louisiana), Feb. 1999.
Details. Download: pdf, ps, html.

“Using a Byzantine-Fault-Tolerant Algorithm to Provide a Secure DNS”
by Zheng Yang.
Masters thesis, MIT, Jan. 1999.
Details. Download: ps, pdf .

Software:

The source code for our project is publicly available. The version provided here runs on Linux. We have made changes to support other operating systems, please contact us if you require one of these versions.

Update!

The BFT codebase has been recently modified to compile on modern operating systems, under gcc4. It now also uses the lighter-weight sfslite library, rather than SFS.

The updated source code, including sfslite-1.2 is available here.

Please contact James Cowling, or the original BFT/BASE authors below, with any problems or questions.

Original Distribution

The BFT code uses the SFS cryptography library. For convenience we provide the version of SFS that is used by BFT. Later versions have changed the crypto interface in a backward incompatible way.

Getting BFT and SFS

First, you must obtain the BFT/BASE source code from here.

Create a new directory where you will unpack the source code above.

% mkdir byz-code
% cd byz-code
% cp /tmp/base-bft-src-rh72.tar.gz .
% tar xvfz bft-base-src-rh72.tar.gz
 (...)

Download version 0.5 or 0.6 of SFS, and unpack it in the same directory. For convenience, we provide a local copy of SFS 0.6 here.

% cp /tmp/sfs-0.6.tar.gz .
% tar xvfz sfs-0.6.tar.gz
 (...)

How to build and run

Instructions on how to build BFT/BASE and SFS are provided in the README file in the top directory of the source code. If you have any problems or questions please contact Miguel Castro or Rodrigo Rodrigues.

License

The BFT/BASE code is released under version 2 of the GNU General Public License.

There is a patent pending on the BFT algorithm.

类别：工作中学习|评论(0) |浏览(716)

The Byzantine Generals Problem(拜占庭将军问题) zt

2010年05月17日星期一 10:12

The Byzantine Generals Problem(拜占庭将军问题)
原文：http://yaowei211.blog.sohu.com/30757545.html
快照：http://blog.sina.com.cn/s/blog_483452da0100brdm.html
参考：http://zhiqiang.org/blog/science/computer-science/tcs-byzantine-failure-the-byzantine-generals-problem.html

一、拜占庭将军问题的背景

对于系统坏掉的风险，可以这样假设：我们的操作员可能会误操作、可能会被贿赂或背叛，系统本身可能就有木马程序，系统可能会被黑客或病毒占领，我们自己开发的系统可能有漏洞，我们的开发人员可能会留下后门，这些都可以导致系统坏掉。因此，在这些假设在变成可能的残酷现实中，生存技术是应真正被采用的一种信息安全技术。　　入侵容忍体系就是生存技术中的核心。如果我们的网络和系统学会生存，那么也就是建立起一个完善的入侵容忍体系。　　

入侵容忍的技术在这样的假设空间中实现它的价值：个人的公开行为在一定的概率下是可预知的，系统在一定的概率下能够正确完成基本的功能。一定的概率并不是指全部，所以，可以允许有错误，因此，入侵容忍还有对纠错理论的联想：即利用纠错码可以在一个错误百出、但有信道容量的信道中准确无误地传输数据，网络系统就这样在错误中“生存”下来的，这就是我们说的入侵容忍体系，它的生存技术有两种实现方式：一是攻击响应的入侵容忍方法，它不需要重新设计系统，可通过高效的检测系统发现异常，利用资源配置系统调整系统资源，并对对错误进行修补（修补系统）；二是攻击遮蔽的入侵容忍方法，它需要重新设计整个系统，并通过冗余、容错技术，门槛密码学技术及“拜占庭”技术来实现。

二、算法介绍

“拜占庭”技术，起源于拜占廷将军问题，这是入侵容忍体系的一个基本理论问题。在1982年被提出的“拜占廷将军问题”在今天被许多学者看好，然而在商业上还没有体现其价值。特别是中国的产业界把它放在了一个被遗忘的角落。

拜占庭将军问题可以抽象成：

设计一个协议，一个司令要送一个命令给他的n-1个副官，使得
IC1. 所有忠诚的副官遵守同一个命令。
IC2. 假如司令是忠诚的，则每一个忠诚的副官遵守他送出的该命令。

约定：忠诚的将军将遵守协议，而叛徒则可能破坏协议，尽可能的干绕其它人的判断。叛徒是匿名的。而且最后不需要确定谁是叛徒。拜占廷将军问题就是要让爱国的将军达成一致，而不是找叛国的将军。

我们的入侵容忍体系就是这样，只要在众多服务器上得到的正确的计算结果，，那么我们就可以相信这个数据，而不需要去寻找到底谁是间谍。如果要容忍一个捣乱的服务器，在数量上究竟会需要几个服务器？

“拜占廷将军”问题可以为我们解答这个问题：在进行混乱真实消息的传播中，两个将军中一个判国，另一个肯定打败仗，三个将军中如果有一个判国，则判国的将军一定有办法让两个爱国的将军不能达成一致，若再增加一个将军，既4个将军中如果只有一个判国，在不知道谁是判国者的情况下，存在一种算法使将军们达成一致，实际上就是三个爱国的将军能够达成一致，而不管判国的将军如何捣乱。

也就是说4个将军的团体能够容忍1个叛国将军。同样我们知道，当有m个判国者在捣乱而又无法找出他们的时候，存在一种算法或称做弹性协议，通过这种协议，能够保证爱国的将军达成一致。如果我们把能够容忍m个叛国者的协议叫m弹性协议，学者证明了，不存在3m个将军下的m弹性协议而一定存在3m+1或以上将军下的m弹性协议。就是说要有3m+1个或以上将军才能保证爱国的将军能够达成一致。如果要想容忍m个判国者，必须保证总的将军的个数大于3m。

三、具体分析

1 叛徒数大于或等于1/3，拜占庭问题不可解。

情况一：A，B，C三个司令，C是叛徒。A发消息给B，C“进攻”，C发消息给B“撤退”（因为是叛徒）。B收到两个矛盾的命令，无法作出决策。

情况二：A，B，C三个司令，A是叛徒。A发消息给B“进攻”，发消息给C“撤退”（因为是叛徒）。B。C收到不同的命令。

2.用口头信息(Oral Message,OM)，叛徒数少于1/3,拜占庭问题可解.

口头信息三条件
A1)传送正确
A2)接收者知道是谁发的
A3)沉默(不发信息)可被检测

可以证明，多项式复杂性算法OM(m)可以解决拜占庭问题.

递归设计协议OM(n, m)为

OM(n, 0)

1.司令发送命令给所有副官。

2.副官按照接收到的命令行事。

OM(n, m):

1.司令发送命令给所有副官，设副官i收到命令vi。

2.分为独立的n-1轮：对每个副官i，将其视为司令，使用协议OM(n-1, m-1)将vi发送到所有其它副官。

3.这样每个副官都收到n-1条信息，每个副官都按照出现次数更多的命令行事（如果进攻和撤退的命令一样多，则默认取撤退）。

结论：当n<=3m时，n个将军中的m个叛徒可以让将军们无法达成一致，也就是满足IC1和IC2的协议不可能存在。此时共需要信息交换轮数m+1.

3 用书写信息(Signed Message)，至少两个忠诚，拜占庭问题可解

在口头信息的基础上, 书写信息又增加了两个条件
A4.1) 忠诚司令的签名不能伪造，内容修改可检测
A4.2)任何人都可以识别司令的签名, 叛徒可以伪造叛徒司令的签名

可以证明，算法SM(m)可以解决m个叛徒的拜占庭问题。

SM(m)算法
1)接收者信息收到后，签上自己的名字，再送给别人
2)用书写信息, 只要有两个忠诚的司令, 拜占庭问题就可解

SM(1):如A是叛徒。A给B发“进攻”，给C发“撤退”命令（都被A签名）。B比较从C发来的命令（“撤退”，该命令被C签名了）知A是叛徒。C比较从B发来的命令（“进攻”，该命令由B签名），知A是叛徒。

结论：当n>=m+2时，n个将军中的m个叛徒可以让将军们可以达成一致，也就是满足交互一致性IC1和IC2。此时共需要信息交换轮数m+1.

类别：工作中学习|评论(0) |浏览(339)

【虎.无名】监控网络IO的几种种方式：sh脚本/iftraf/nmon/iftop/iotop/...

2010年05月14日星期五 14:03

【虎.无名】监控网络IO的几种种方式：sh脚本/iftraf/nmon/iftop/iotop/...
1)通过编写ionet.sh脚本来完成。计算某个网络设备的的流量（无需root权限）。。。231上（Linux-2.6.9-42.ELsmp）可用
2)iptraf -g 是一个字符型图像界面的，针对所有网络设备来统计。需要root权限
3)nmon功能比较强，最早用于aix，后来移植到linux了，可生成采样数据，并可离线分析生成excel报表。http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon
4)iftop(http://www.ex-parrot.com/%7Epdw/iftop/download/iftop-0.17.tar.gz)需要安装。
5)IoTop(http://guichaz.free.fr/iotop/files/iotop-0.4.tar.gz）需要安装。
6)cat /proc/net/dev
Inter-|   Receive                                                | Transmit
face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
lo:3898080016 110806564    0    0    0     0          0         0 3898080016 110806564    0    0    0     0       0          0
eth0:1676987060 112787274    0    0    0     0          0      1148 2489184522 76692292    0    0    0     0       0          0
7)针对某个Interface的网络流量可以通过比较两个时间网络接口的RX和TX数据来获得
$ date; ifconfig eth1
$ date; ifconfig eth1
8)通过SNMP采集数据。
http://blog.jiankongbao.com/?tag=%E7%BD%91%E7%BB%9C%E6%B5%81%E9%87%8F “监控宝”推出的服务器的“仪表盘”
最近一段日子，监控宝快速增强服务器监控功能，提供了各种历史统计，并且推出了服务器概述页面，它就像服务器的“仪表盘”一样，让你可以快速的对服务器的运行状况一目了然
http://www.php-oa.com/2008/04/29/linuxliuliangjiankongdesangefangfa-2.html Linux图形化之流量监控和IO监控 _ 凯哥
因为做linux常常会要做linux下的流量查看，下面的三个方法能很好的解决当前流量查看.注:我认为nload很破,不准.安装方法，请查我的另一个文章，linux的rpm高级管理.
(1)iftop工具
用途: 用来即时监看网路状态和各ip所使用的频宽。
执行(必须以root身份)
# iftop -i eth1 # 监控eth1的网卡的流量
$ iftop -B # 以位元组(bytes)为单位显示流量(预设是位元bits):
$ iftop -n # 直接显示IP, 不进行DNS反解:
$ iftop -N # 直接显示连接埠编号, 不显示服务名称:
$ iftop -F 192.168.1.0/24 or 192.168.1.0/255.255.255.0 # 显示某个网段进出封包流量
其他参数可下 iftop -h 看说明.
进入iftop画面时, 可按 p 切换是否显示连接埠, n 切换显示IP或主机的domain name, N切换显示连接埠代号或名称, p暂停显示, b切换是否显示长条, B切换计算几秒内的平均流量, 其他按键可以按h观看说明.
設定檔的位置在~/.iftoprc , 關於設定檔的寫法可以參考 iftop 的 info page.
(2)nload
用途: 用来即时监看网路状态和各ip所使用的频宽(很废话了)
#nload eth1 # nload默认的是eth0网卡，如果你想监测eth1网卡的流量
nload默认分为上下两块：上半部分是：Incoming也就是进入网卡的流量，下半部分是：Outgoing，也就是从这块网卡出去的流量，每部分都有当前流量（Curr），平均流量（Avg），最小流量（Min），最大流量（Max），总和流量（Ttl）这几个部分，看起来还是蛮直观的。另外，你也可以自己定义流量数值显示的单位
#nload –help # 就可以看到具体的相关参数了。
查看网络平均流量
(3)下面的脚本可以很好的监控你的网络的平均流量,你可以提定时间
# ionet.sh
#!/bin/bash
echo -n "which nic?"
read eth
echo "the nic is "$eth
echo -n "how much seconds:"
read sec
echo "duration is "$sec" seconds, wait please…"
infirst=$(awk '/'$eth'/{print $1 }' /proc/net/dev |sed 's/'$eth'://')
outfirst=$(awk '/'$eth'/{print $10 }' /proc/net/dev)
sumfirst=$(($infirst+$outfirst))
sleep $sec"s"
inend=$(awk '/'$eth'/{print $1 }' /proc/net/dev |sed 's/'$eth'://')
outend=$(awk '/'$eth'/{print $10 }' /proc/net/dev)
sumend=$(($inend+$outend))
sum=$(($sumend-$sumfirst))
echo $sec" seconds total :"$sum"bytes"
aver=$(($sum/$sec))
echo "avrage :"$aver"bytes/sec"
(4)还有一个叫ipband的软件听讲不错,有兴趣可以到 http://ipband.sourceforge.net/ 看看
(5)IO图形化监控
windows的任务管理器很不错，可以直接看到进程和对应IO的情况。
linux也有了，不过要求python>=2.5，内核>=2.6.20 http://guichaz.free.fr/iotop/
主页：http://guichaz.free.fr/iotop/
下载：http://guichaz.free.fr/iotop/files/iotop-0.4.tar.gz
http://dev.firnow.com/course/6_system/linux/Linuxjs/2008825/137525.html 查看 CPU，内存，网络流量和磁盘 I/O
3. 查看网络流量，可以用工具iptraf工具
$ iptraf -g
针对某个Interface的网络流量可以通过比较两个时间网络接口的RX和TX数据来获得
$ date; ifconfig eth1
$ date; ifconfig eth1
还有这个，最早是aix下，后来移植到linux也可用了 http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon
nmon的功能很强，还可生成excel报表。
http://www.aixchina.net/club/viewthread.php?tid=11687 用nmon监控aix的性能，nmon_analyser分析系统监控数据
nmon是一款很好的unix、linux下的系统性能监控工具。
下载地址：http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon
虽然网上有很多nmon的使用安装介绍，但是我按照他们的指导都没有安装成功。自己摸索着安装成功了。不过仍然感谢这些文档的指导。
Nmon安装手册
1.必须用2进制数据格式传输到主机上,否则你明明ls看得到这个文件，解压的时候告诉你没有这个文件，this file is not exist。
ftp 192.168.*.*
用户：root
密码：****
cd /home
mkdir monitor
cd monitor
mkdir nmon
cd nmon
bin
put e:/aix/nmon/nmon4aix12a.tar.gz
你所下载的nmon的地址
2.用xmanager登录aix
#cd /home/monitor/nmon
#gzip nmon4aix12a.tar.gz
#tar –xf nmon4aix12a.tar
可能tar的时候有报错，修改文件属性为755 即可。
安装完毕、
#cd nmon4aix12a
运行监控程序
#./nmon
按空格' s# l0 J2 b' y, k& \; H y
然后按“c”键
然后按“m”键
nmon_analyser分析系统监控数据，并有图标显示
1.下载nmon_analyser,地址：http://www-941.haw.ibm.com/collaboration/wiki/display/Wikiptype/nmonanalyser
2.这个文件不用上传到aix上，在pc上解压即可。很多人包括我都有此疑惑，解压完了就是一个doc文件NA_UserGuide v33.doc，一个xls文件nmon analyser v334.xls，怎么执行啊，怎么分析啊。请接着看。
3.在aix上运行nmon捕获数据，在当前目录下生产监控日志文件，文件以主机名和日期命名。
#./nmon -f -s 30 -c 120
nmon每30秒捕获一次数据快照
生产app_090623_1451.nmon文件，
4.将生产的app_090623_1451.nmon下载在pc上。
5.打开nmon analyser v334.xls，注意一般会报错，说宏的安全级别太高，一定要把宏的安全级别降到最低，在excel的工具-宏-安全性。
6.点击nmon analyser v334.xls文件里的按钮analyser nmon data,选择刚才下载的app_090623_1451.nmon，完成后另存为即可。
关于nmon_analyser的详细文档见NA_UserGuide v33.doc。
关于nmon的文档见 http://www.ibm.com/developerworks/cn/aix/library/analyze_aix/
http://gaoxingf.blog.51cto.com/612518/188966 Linux下监控网卡流量的软件iftop
官网上说使用iftop需要libpcap和libcurses这两个包。
安装iftop：
# wget http://www.ex-parrot.com/%7Epdw/iftop/download/iftop-0.17.tar.gz
# tar zxvf iftop-0.17.tar.gz
# cd iftop-0.17
# ./configure --prefix=/usr/local/iftop && make && make install
# /usr/local/iftop/sbin/iftop      //默认监测eth0网卡流量

类别：工作中学习|评论(0) |浏览(1253)

基于Java的x86模拟器 zt

2010年04月28日星期三 10:30

牛津大学的研究人员开发了一款基于Java的x86模拟器。研究者希望它可用来对应用程序进行测试，在不危及电脑的情况下了解病毒细节，模拟器利用了Java提供的Robust沙盒（robust sandbox）。网站上提供了在线demo（http://javapc.sourceforge.net/home_home.html），展示了其可在DOS环境下启动，并可运行一些游戏。由于完全使用了Java，因此这个模拟器的运行环境非常广泛，比如手机上。代码还无法在牛津大学之外的地方提供下载，但开发者已经表示将采用一般的许可证许可。（来源：http://www.builder.com.cn/2007/0428/389516.shtml）

类别：工作中学习|评论(0) |浏览(175)

J2EE中监听器Listener的应用(转)

2010年04月26日星期一 16:20

本文以二个Listener实例来讲述ServletContext、HttpSession对象生命周期及ServletContext、HttpSession对象中属性变化情况。

实例一:用于监听ServletContext对象生命周期及ServletContext对象中属性的变化情况的监听器ContextListener,分别实现了ServletContextListener,ServletContextAttributeListener接口。代码如下:

package com.hc.znpb.servlet;

import javax.servlet.ServletContextAttributeEvent;
import javax.servlet.ServletContextAttributeListener;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class ContextListener implements ServletContextListener,
ServletContextAttributeListener {
public void contextDestroyed(ServletContextEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】应用被关闭!");
}
public void contextInitialized(ServletContextEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】应用被启动!");
}
public void attributeAdded(ServletContextAttributeEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】ServletContext对象中新增一名为" + arg0.getName()
+ "的属性,其属性值为:" + arg0.getValue());
}
public void attributeRemoved(ServletContextAttributeEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】ServletContext对象中一名为" + arg0.getName()
+ "的属性被删除!");
}
public void attributeReplaced(ServletContextAttributeEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】ServletContext对象中一名为" + arg0.getName()
+ "的属性被更新!");
}

}

实例二:

用于监听HttpSession对象生命周期及HttpSession对象中属性的变化情况的监听器SessionListener,分别实现了HttpSessionListener,HttpSessionAttributeListener接口。代码如下:

package com.hc.znpb.servlet;

import javax.servlet.http.HttpSessionAttributeListener;
import javax.servlet.http.HttpSessionBindingEvent;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

import com.hc.znpb.util.SysUtil;

public class SessionListener implements HttpSessionAttributeListener,HttpSessionListener {

// 在线人数统计
private int userCount = 0;
public void attributeAdded(HttpSessionBindingEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】HttpSession对象中新增一名为" + arg0.getName() + "的属性,其属性值为" + arg0.getValue());
}

public void attributeRemoved(HttpSessionBindingEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】HttpSession对象中一名为" + arg0.getName()+ "的属性被删除!");
}
public void attributeReplaced(HttpSessionBindingEvent arg0) {
// TODO Auto-generated method stub
System.out.println("【监听到】HttpSession对象中一名为" + arg0.getName() + "的属性被修改！");
}
public void sessionCreated(HttpSessionEvent arg0) {
// TODO Auto-generated method stub
// 在线人数加1
arg0.getSession().setAttribute(SysUtil.SESSION_COUNT_USERS,new Integer(this.userCount++));
System.out.println("【监听到】新用户" + arg0.getSession().getId() + "上线！");
System.out.println("【在线用户数】" + this.userCount + "人");
}
public void sessionDestroyed(HttpSessionEvent arg0) {
// TODO Auto-generated method stub
// 在线人数减1
arg0.getSession().setAttribute(SysUtil.SESSION_COUNT_USERS,new Integer(--this.userCount));
System.out.println("【监听到】新用户" + arg0.getSession().getId() + "下线！");
System.out.println("【在线用户数】" + this.userCount + "人");
}

}

最后修改web.xml文件，如下:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.4"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<listener>
<listener-class>
com.hc.znpb.servlet.ContextListener
</listener-class>
</listener>

<listener>
<listener-class>
com.hc.znpb.servlet.SessionListener
</listener-class>
</listener>

</web-app>

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/uciqxkj/archive/2008/11/06/3238853.aspx

类别：工作中学习|评论(0) |浏览(5296)

如何架构、设计与实现高质量的远程接口 zt

2010年04月22日星期四 17:50

http://www.tech-q.cn/thread-7190-1-1.html 架构师之道：如何架构、设计与实现高质量的远程接口
一、【前言】
刚刚经历完一个公司的项目，涉及很多架构设计、远程接口。在使用（我们自身）平台设计的接口过程中十分曲折、全体痛苦，而我负责的传真接口却让外部客户（电信方）与内部客户（应用方）感觉愉快清晰而受内外好评。因此，我感觉颇有必要将我历来的设计经验分享出来，以帮助团队成长，未来的项目中少走弯路，作出成熟的、高质量的接口设计。
二、【正确的人，做正确的事】
任何优秀的架构师都明白的道理：
1、需求永远是第一位的，接口为需求服务。需求是接口的“衣食父母”。
2、应用方（工程师们）也是另一种意义上的”衣食父母”，如接口架构不良、实现较差，难用难扩展甚至没人愿意用，则最终会被“父母”抛弃。
3、有时候，我们看似比“衣食父母”更专业、更有经验，但并不见得比“父母”更有“生活智慧”，不要去试图教训“父母”，或让“父母”适应你。相反，尽一切可能适应或满足“衣食父母”的需求才是正确的设计之道。
4、好酒也怕巷子深；好设计需要好的媒介加以表达。写一份优良的接口设计文档，并在评审中清晰明白的阐述设计思路，是架构师的基本功。
5、好酒是与好窖、好水、好温度、好酿酒师密不可分的（再加上一段时间）。让团队成员尽可能广泛参与设计与评审，才能集思广益、查漏补缺，更能沟通顺畅、执行无误，切忌孤芳自赏、闭门造车、欲速不达。
6、如果你的团队中的“木桶效应”非常明显。你需要做两件重要的事：不要让自己的工作成为短板；尽可能补救那块最短的板。
三、【人与制度】
人与制度的关系，就像人与自然的关系。人能改变自然，但首先是被自然改变。
优秀的设计背后一定有优秀的作者，但如果“自然环境”不良，好设计也难以诞生或容易夭折。
如果你的团队一直不能诞生优良的设计，最大的可能只有两点：人或自然环境相当不佳。
具体到影响设计质量的制度建设上，我只建议4点：
1、让你团队的最优秀者作独立设计师或主设计师，无论是产品设计还是架构设计。
2、需求评审必须严格且广泛参与，业务流程图（注意：不是PageFlow）与业务规则描述是产出物中的必备内容，可多轮直至全部细节都经过评审
3、架构与接口设计的评审也必须同样不可省略，可多轮直至满足全部需求点（含潜在需求）方可通过评审
4、接口的设计与现实最好由同一人负责，别推脱或假手他人，甚至让新人或实习生来开发接口的实现
四、【接口的协议与框架】
目前，最常见的远程接口协议是基于HTTP协议基础上的soap、hessian、Json-RPC等。前两者，我应用已久，我对技术人员的协议建议是：hessian。对于Java开发者来说，支持soap（webservice）协议的最好的框架类库是xfire（另一个是axis远不如xfire好用）；而支持hessian协议的框架类库，最好的就是spring。因此，hessian+spring是我的推荐，也是很多架构师的不二选择。
五、【远程接口的架构设计】
比起协议与框架的选择来说，接口的架构设计才是体现设计师真正水准的分水岭。
一般来说，无论远程接口还是本地接口，常常会有异步执行的情况：即调用方call被调用方的接口，同步返回请求成功，但实际操作是被调用方延后去执行的。这种时候，提供回调接口是最佳选择，只有万不得已之时，才考虑让调用方轮询被调用方的接口，以查询执行结果。
因此，回调模式与轮询模式相比，无论是及时性、安全性、可靠性以及性能效率上远胜不止一筹。只有一种极特殊的情况下，我们完全无法采取回调模式：即被调用方的系统过于老旧，不可改造，无法回调不同的调用方。大多数时候，我们都可以用回调模式取代轮询模式，甚至可进一步做得更完美一点，让被调用方对于调用方不存在直接依赖（答案我不直接讲出来，自己思考一下怎么将<直接依赖>变成<优雅且万能的间接依赖>）。
架构方案也是综合技术能力的体现，需要设计者在协议规范、语言能力、面向对象思想、数据结构、设计模式等方面不能存在明显短板。记住：一份出色的设计文档是你设计工作的最终载体。
六、【远程接口的设计实现】
我列举一些易犯（特别是接口设计的新手）的常见问题：
1.不定义接口类(interface)，而是直接定义抽象类。
2.接口返回对象参差不齐，随便定义。
——最好定义全局统一的Result对象：resultCode（全局返回码）, resultObject。
3.异常处理非常不统一，有时候用CheckedException，有些时候用UncheckedException，有些时候用ErrorCode。
——我的建议是所有异常在方法内部捕获，统一在ResultCode（全局返回码）中定义一段错误码，通过输出结果返回。
4.使用Map作接口方法的输入、输出，还美其名曰：简单灵活。有时候甚至只有一个Map作输入。
——Map非常不适合作公共API方法的输入输出（仅非常特殊时除外），直接导致弱类型问题、易引发潜在BUG且调试困难、不容易书写数据对象的（反射式）校验代码。另外，有些人反映hessian协议下存在Map中的自定义对象的序列化问题，其实很简单：1、不要使用Map；2、覆盖一下这些对象的hashCode方法。
好的接口方法的输入、输出无不定义为强类型，且应分别输入多个不同的业务数据对象（易于校验、维护与测试）。
5.接口包不提供输入对象的校验，对象长度、格式等只在文档中说明。
——建议接口包统一提供输入对象的校验：是否必填、长度与格式。最好定义一个Validatable接口：含validate方法，同时让所有输入对象实现之。
6.远程数据对象未实现序列化接口。
7.未考虑远程接口的安全性问题。
——有两种方案可让远程接口提升安全性：一、使用HTTPS协议；二、接口方法上增加一个安全码参数作安全检查（方法一：调用方与被调方用同一密钥对时间戳作DES加解密以便比对）。前者属于协议层安全，后者属于应用层安全，两者也可以同时提供，我建议仅用后者即可。
8.不作单元测试。
——关键类的public方法最好先作单元测试。另外，如完成一个接口方法的实现类，最好书写单元测试代码自测之（事半功倍之举）
还有很多细节问题，需要你自己的分析、判断与经验。这里请牢记一句话：细节决定成败！当你完成一个接口类库包，就可以打上版本发布（建议与接口文档同时发布，且版本保持一致）。如以后升级类库，记住先升级文档。
七、【后记】
到此，我已经比较全面的介绍了接口设计主要原则与重点，但仅靠别人的分享与培训是不足以成为一位出色的设计师的。

类别：工作中学习|评论(0) |浏览(288)

关于 I/O 的五分钟法则(Five-Minute Rule) zt

2010年04月19日星期一 14:06

去年在对 SSD 做调查的时候就关注过这个『五分钟法则』，今天又发现了『这篇文章』的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

http://tech.techweb.com.cn/thread-434380-1-1.html [推荐] 内存还是硬盘? 数据库IO瓶颈时的抉择
很多DBA在进行数据库管理时通常都会遇到数据库IO瓶颈，在硬件成本预算有限的情况下，解决这一瓶颈有两个方法：一是增加内存；二是增加磁盘（假设不增加机器的情况下）。到底是加内存合算，还是加磁盘实惠呢，这是个头疼的问题。
已经神秘消失的数据库大师Jim Gray早在20年前就为我们考虑过这个问题了，并且得出一个结论叫“五分钟规则”（Five Minutes Rule），就是说如果一个页面每五分钟就会被访问一次的话，就应该把它放到内存中去，否则就应该把它存储在磁盘上。这样，数据库只要统计一下有多少页面的访问频率超过五分钟一次，就知道需要多少内存了。
当然五分钟是个典型值，或者表示一个数量级，具体的值要看硬件条件。Jim Gray给出的公式是：
RI = 每M数据页数 * 一块磁盘的价格 / 磁盘每秒能进行的随机IO次数 / 每M内存的价格
其中RI即为要放到内存的页面访问时间周期阈值。
这个一公式可以这么理解。假设你拿到一个页面，它的访问周期是I。你要决定是买内存来存储这个页面还是买磁盘来存储它。假设买内存来存储，开销很容易算出来是"每M内存价格/每M数据页数"。如果买磁盘来存，则开销是"一块磁盘的价格 / 磁盘每秒能进行的随机IO次数 / I"，意思是说，我买个磁盘花的钱是“一块磁盘的价格”这么多，再我这个页一秒只会访问"1/I"次，因此我只占用了磁盘带宽的"1/I/磁盘每秒能进行的随机IO次数"，因此为这个页花的开销就是“一块磁盘的价格 / 磁盘每秒能进行的随机IO次数 / I"。
这样，导致内存开销"每M内存价格/每M数据页数"与磁盘开销"一块磁盘的价格 / 磁盘每秒能进行的随机IO次数 / I"相等的I值即为访问时间周期阈值，计算出来就是公式中的RI。
在数据库IO瓶颈时，针对当前常用硬件来计算一下。设页面大小为16K（InnoDB默认页面大小），也就是每M数据页数64，一块SAS盘算3000块，每秒能进行200次随机IO，4G的内存算3000块一条，也就是每M内存0.75元。这样算出来RI是1280秒，也就是20分钟左右。
可惜的是MySQL并不提供页面的访问频率统计功能。可以用一个方法来代替，就是把数据库关掉，起来后看20分钟内数据库的缓存有没有满，若没有满，表示内存太大，否则表示内存太小。只是在热门时间段肯定是不会去做这个实验的，非热门时间段倒是可以把数据库重起下，但这时负载轻又不准了。即使是哪天MySQL crash了，在热门时间段crash后要做很多redo，又不准了。实际上这一功能是可以实现的，统计有多少个20分钟访问一次的页面可以近似的转化为统计20分钟内有多少个不同的页面被访问。假设系统中内存大小与理想值相差不太大，则只需要多用不到1/1000的内存就可以统计出来，当然每次页面访问时要多搜索一个哈希表。嗯，在NTSE里准备实现吧，哈哈。
当然这一计算已经忽略了很多实际因素，比如如果你机器上的RAID卡已经满了不能加硬盘，那就只好加内存了，如果内存槽插满了，那就只好加硬盘了。如果硬盘和内存都加不了，那就加机器吧。另外上述计算假设页面访问是完全随机的，如果是顺序访问，那就大不相同了，这时的RI会小很多，因为这时磁盘每秒能读入的页面数增加了。

类别：工作中学习|评论(0) |浏览(2128)

再谈select, iocp, epoll,kqueue及各种I/O复用机制（zt，原贴多图）

2010年04月14日星期三 18:34

来源：http://blog.csdn.net/shallwake/archive/2010/01/28/5265287.aspx

首先，介绍几种常见的I/O模型及其区别，如下：

blocking I/O
nonblocking I/O
I/O multiplexing (select and poll)
signal driven I/O (SIGIO)
asynchronous I/O (the POSIX aio_functions)

blocking I/O
这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：

重点解释下上图，下面例子都会讲到。首先application调用 recvfrom()转入kernel，注意kernel有2个过程，wait for data和copy data from kernel to user。直到最后copy complete后，recvfrom()才返回。此过程一直是阻塞的。

nonblocking I/O：
与blocking I/O对立的，非阻塞套接字，调用过程图如下：

可以看见，如果直接操作它，那就是个轮询。直到内核缓冲区有数据。

I/O multiplexing (select and poll)
最常见的I/O复用模型，select。select先阻塞，有活动套接字才返回。与blocking I/O相比，select会有两次系统调用，但是select能处理多个套接字。

signal driven I/O (SIGIO)
只有UNIX系统支持，感兴趣的课查阅相关资料

与I/O multiplexing (select and poll)相比，它的优势是，免去了select的阻塞与轮询，当有活跃套接字时，由注册的handler处理。

asynchronous I/O (the POSIX aio_functions)
很少有*nix系统支持，windows的IOCP则是此模型。完全异步的I/O复用机制，因为纵观上面其它四种模型，至少都会在由kernel copy data to appliction时阻塞。而该模型是当copy完成后才通知application，可见是纯异步的。好像只有windows的完成端口是这个模型，效率也很出色。

下面是以上五种模型的比较

可以看出，越往后，阻塞越少，理论上效率也是最优。

=====================分割线==================================

5种模型的比较比较清晰了，剩下的就是把select,epoll,iocp,kqueue按号入座那就OK了。select和iocp分别对应第3种与第5种模型，那么epoll与kqueue呢？其实也于select属于同一种模型，只是更高级一些，可以看作有了第4种模型的某些特性，如callback机制。

那么，为什么epoll,kqueue比select高级？

答案是，他们无轮询。因为他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

windows or *nix （IOCP or kqueue/epoll）？

诚然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系统，但是由于其系统本身的局限性，大型服务器还是在UNIX下。而且正如上面所述，kqueue/epoll 与 IOCP相比，就是多了一层从内核copy数据到应用层的阻塞，从而不能算作asynchronous I/O类。但是，这层小小的阻塞无足轻重，kqueue与epoll已经做得很优秀了。

提供一致的接口，IO Design Patterns

实际上，不管是哪种模型，都可以抽象一层出来，提供一致的接口，广为人知的有ACE,Libevent这些，他们都是跨平台的，而且他们自动选择最优的I/O复用机制，用户只需调用接口即可。说到这里又得说说2个设计模式，Reactor and Proactor。有一篇经典文章http://www.artima.com/articles/io_design_patterns.html 值得阅读，Libevent是Reactor模型，ACE提供Proactor模型。实际都是对各种I/O复用机制的封装。

Java nio包是什么I/O机制？

我曾天真的认为java nio封装的是IOCP。。现在可以确定，目前的java本质是select()模型，可以检查\jre\bin\nio.dll得知。至于java服务器为什么效率还不错。。我也不得而知，可能是设计得比较好吧。。-_-。

=====================分割线==================================

总结一些重点：

只有IOCP是asynchronous I/O，其他机制或多或少都会有一点阻塞。
select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
epoll, kqueue是Reacor模式，IOCP是Proactor模式。
java nio包是select模型。。

OVER，写得很累，转载请注明出处，谢谢！

类别：工作中学习|评论(0) |浏览(879)

架构大型网站的的九个参考主题 zt

2010年04月10日星期六 22:20

http://blog.donews.com/jiatian/archive/2010/04/06/1583613.aspx 架构大型网站的的九个参考主题
提到做大规模网站，大家一定会想到云计算，想到Google File System，Chubby， BigTable，MapReduce等等。这些技术固然很好，但是它们仅仅是构成一个大型网站的技术要素。实际构建一个大型网站时，光知道技术要素是不够的，还得明白如何把各个要素有机地结合到一起。“Flickr 网站架构研究”是一篇值得反复阅读的好文章。这篇文章不仅对一个大型网站的架构进行了系统解剖，逐条梳理，而且行文深入浅出。可惜这样的文章不多见。关于大型网站实例的讨论，散落在各处，而且内容零散。学习和掌握构建大型网站的架构，需要汇总散落的文章，梳理零散的内容。做好这项工作很有意义，但是也比较困难。我们的体会是，不妨抓住以下几个主题，逐个分析大型网站的实例，然后横向比较。
1. Database
数据存储历来是麻烦，尤其是需要存储海量数据的时候，往往单个数据库容量不够，甚至一个数据库集群也不够。常见的解决办法是分割，譬如按用户ID把海量数据分割成若干块，每块存储到一个独立的数据库里去。但是分割的做法降低了join操作的效率。Google Bigtable的效率如何？好处是什么，缺陷是什么？Bigtable对什么样的情景最适用？根据Bigtable原理实现的开源软件，Hadoop/HBase的运行效率如何？
2. Cache
用户访问网站时，通常读的操作比写的操作更频繁。为了提高读的操作，不妨把相关内容缓存到内存里，减少Disk IO的消耗。MemCached 最近大热，Wikipedia， YouTube， Digg， Twitter等等大型网站都在用MemCached作为缓存工具。SquidCache和Varnish等等工具，也与缓存沾边。Twitter的做法是把MemCached和Varnish结合起来，同时使用。什么样的内容，应该用什么样的缓存工具？不同的工具间如何协调？各大网站的实际运行的结果，有哪些经验和教训？
3. File System
有些内容，既没必要存放在数据库里，也不适合存放在缓存中，譬如log 和images。在这种情况下，我们需要文件系统。当有海量内容需要存放在文件系统中时，我们需要使用分布式文件系统。Google File System对于什么样的情景适用，什么样的情景不适用？分布式文件系统常常需要相应的锁机制，保证并发的读写操作不相互干扰。Chubby有什么好处？什么情形下不适用？据说MogileFS更适合存储大量的，但是单体尺寸不大的文件，譬如images。而Google File System更适合存放大尺寸但是数量不多的文件。有没有可能把小尺寸的多个文件，合并成一个大文件，然后存储到Google File System中去。在这种情况下，比较MogileFS与Google FS的性能，是否有高下之分？
4. Thread Management
一套工序通常由若干任务组成。多线程的办法是由一根线程全权负责整套工序的操作。另外一个办法是把工序斩成几段，每一段由一根或几根线程负责，这种办法称为工作台【虎.无名：SEDA架构】。常见的是多线程的办法。但是工作台的做法有利于集中计算资源处理繁重的任务，避免瓶颈的出现。但是缺陷是需要在不同线程之间，传递记录中间状态的数据。什么样的情形适合用多线程，什么时候用工作台？
5. Scheduler
同一个网站通常会提供多种服务，不同的服务需要调用不同的业务逻辑。有些业务逻辑可以在同一台服务器上完成，但是当业务逻辑复杂的时候，需要调用多台服务器合作完成。不同服务的受众对象不同，流量也不同，不同时段的流量也不同，同一时段不同服务的流量也不同，所以需要动态地分配计算资源。这是 scheduler的工作。Scheduler给不同服务器分配工作时，最简单的办法是启动预先安装在该服务器上的相关程序。由于不能保证每个程序都十分完美，当一个程序发生错误时，应当避免整个服务器因此而崩溃，影响其它工作的正常进行。是否需要动用virtual machine，实现各个不同工作之间相互隔绝？
6. Signal Flow and Data Flow
大型网站后台系统经常由众多服务器组成，服务器与服务器之间时不时会发生数据交换，譬如Web Server解析完用户请求后，把请求转发给某一台App Server，这一台App Server完成了部分工作后，把中间数据转发给下一台App Server。而第二台App Server完成任务后，整个工作就结束了，结果应该返回给Web Server。
问题是如何让第一台App Server如何知道应该把中间结果给第二台App Server，而第二台App Server又如何知道它的目的地是Web Server？一个比较有效率的做法，是区别数据流和控制流。Server与Server之间常设通道，专供控制流使用，传递指令去控制数据流的发送。数据流不占用控制流通道，只有在需要时，才建立数据流的通道。【如，FTP的模式。】控制流和数据流的组织，需要结合具体的业务逻辑，才能优化设计，减少带宽消耗，缩短数据传输的时间。
7. Instrumentation
网站后台各个部分是否运转正常，哪里是瓶颈，哪里空闲。这些都需要实时监控。不仅及时避免整个后台系统的崩溃，而且可以分析各个部分运行的规律，从而找到优化系统的途径。问题是，应该选用什么样的监控工具，才能够尽量减少对系统程序的干扰，同时提供有价值的信息？
8. Anti-abuse
通常网站面对的是形形色色的用户，绝大多数用户的行为是友好的，但是不排除少数用户蓄意恶作剧。如果事先没有设计防范措施，少数恶意用户的胡作非为，会干扰其他用户享受正常的服务。问题是，如何防范并且及时制止恶意行为的发生？
9. Exception Handling
不论预先设想有多周密，实际运行时，总会遇到这样那样的意外情况。譬如敏感词的出现，往往事先没有征兆。所以，在设计系统架构时，应该给网管提供必要工具，应付突发事件。

类别：工作中学习|评论(0) |浏览(555)