Hadoop中的集群配置和使用技巧
本文介绍了Hadoop如何配置分布式框架运行环境，同时特别讲解了其中的一些细节。Hadoop可以单机跑，也可以配置集群跑，这里主要重点说一下集群配置运行的过程。本文是Hadoop入门实践三部曲的第二部。
- Java,
新闻
文章：智能服务契约带来的巨大伸缩性
作者 Floyd Marinescu译者 黄璜 发布于 2008年5月14日 上午1时51分
Udi Dahan讲述了在实现一个新订单系统时所遇到的一次经历，当时大尺寸消息的传送影响了系统的伸缩性，甚至导致了服务器瘫痪。这篇文章叙述了他们如何查出问题并给出了他们的解决方案，“通过改变我们的服务契约并引入有状态的交互，使得我们能够管理那些和系统性能息息相关的状态”。
问题：
消息大小看似对所有其它方面有很大的影响。当消息增大时，它会占用更多的CPU时间来反序列化（deserialize），消耗更多的内存在保存结果数据，更多的网络带宽和IO来进行数据库读写操作，所有这些加起来就会影响总的处理时间。然而，即使是像给一个合作伙伴的所有待处理订单打折这样小的请求，也会因所处理数据量不同而受到影响。
解决之道：
与之前的一条“创建订单信息”不同，合作伙伴可以随着时间动态地发送给我们多条“订单信息”，关键字是：（合作伙伴id，采购订单编号）。当该采购订单编号的所有条目完成后，他们可以发来一个“完成”标志为真的“订单信息”。这是有状态的交互......一旦每个请求的资源利用率得以下降，延迟也得以明显下降，但是吞吐率却比我们预期的更高。
Udi的收获：
我最大的收获是：可伸缩性不是是或不是这样一个简单的问题。除了并发用户数量和在线服务器的数量之外，可伸缩性还是一个多维的成本函数。对于某个响应时间的需求，峰值和均值请求的比率，消息大小，格式，每个请求的内存工作集大小，每个请求的CPU/IO利用率，一个解决方案需要花多大的代价？对于战略伙伴有意义的技术选型对一般合作伙伴又不具成本效益。始终站在业务的角度来得出结论——当他们发现成本（前端和进行中）盖过产生的回报的时候他们就可能改变性能需求。
你也曾经有过类似的经历吗？
阅读全文：智能服务契约带来的巨大伸缩性。
相关厂商内容
好文章、好例子
发表人
feng xishun
发表于
2008年5月15日 下午8时23分
Re: 好文章、好例子
发表人
Can Zheng
发表于
2008年6月2日 上午1时7分
2 条回复
回复