[Hadoop] MapReduce进程间的交互
摘自象书
Month: November 2012
头脑风暴：思考可能性的方案时先不要考虑约束
对一个问题，需要提出各种假设性的方案并进行评估。有一种本能是：在对某个方案还没想透时，你不禁会想到一些约束，让你马上这个方案的可行性。 顺着这个怀疑，你会陷入更多的怀疑，并且花很多脑力和时间来想证明或者推翻自己的怀疑。但由于你对方案本身没有想透，你的证明或推翻往往以失败告终。 接着你又开始回过头来想这个方案本身，然后又被约束所拦住，接着又陷入怀疑中。。。 这种做法本身并没有错，可能最终还是能想透。但由于它的反复、停滞，使得整个过程比较低效。 如果你先不管约束，先把方案本身想透，再来考虑约束对它的影响，效率会高得多。
同事教了一个评估所需qps的办法
互联网应用中，业务方最容易给出的评估指标是UV 我们就是要根据UV推导出系统应该具备的极限峰值 推导过程是： 1. 根据UV估计出PV，一般可以乘10 2. 确定峰值访问的时间长度（比如说中午那个小时），及这个时间段流量占全天流量的比例，从而得出这个时间段内的PV 3. 用这个PV数除于峰值时间段的跨度（单位秒），即得QPS 当然，QPS满足了要求未必就意味着性能达标了。你还要考虑并发数。经验上，可以使用25(当然未必普适)并发数作为极限并发数，然后再测一下在这个并发数QPS能否达到上面推导出的值。 p.s. 为了确定极限并发数，也可以逐渐提高并发数，依次进行性能测试；然后查看性能曲线(如qps，具体视情况而定)，直到性能曲线下降为止。