Month: December 2013

压力测试中几种不同的”压力“

1. 请求的数据量大小(字节数) 2. 每秒请求数    a. 短连接应用:不必多说    b. 长连接应用:大量连接建立请求 3. 在线数    a. 短连接应用:Session数    b. 长连接应用:维持的长连接数(socket数) 4. 留存数据量: 数据库里已有的数据量 待续。。。

消息中间件可能重发消息,怎么办?

消息中间件可能重发消息,怎么办?只能要求客户端保证幂等性了。 但这又增加了客户端的复杂性,人家可能不愿意。 其实解决办法很简单(也很流氓),你自己做个客户端SDK,在这里面做好消息去重,然后让你的客户集成它就是了。

有必要搞pipeline之类的东西吗?

有必要搞pipeline之类的东西吗? 把各块功能封装成独立的API,然后每个request handler分别调用不同的api组合不就行了吗?这样还免得搞框架,也不用写什么配置文件。 这种质疑不是没有道理,但最近的亲身体会表明,pipeline体系在开发效率、代码正确率上有确有一定优势。 比方说,要加一个切面功能的话,Pipeline模式中开发者要在各个request handler的xml配置中加上一行,API模式中开发者要修改各个 request handler类。 比较: 1. 在xml中加配置肯定比在各个类中加代码更快 2. 在xml中加不易出错,而在各个类代码中改相对容易出错     a. java代码在结构上不如xml文件清晰,插错地方的可能性比较高     b. 在java代码中新增API调用语句前要先收集输入,如果插入点的上下文没有直接可用的变量作为输入,则需要重构代码,引发bug隐患; 在xml中配置没有这个问题,因为pipeline体系中强制规定了输入变量应从pipeline context中获取,总是能获取到的。     c. 在java代码中调用API后要根据输出和异常决定下一步怎么走,这可能导致比较大的流程变更,而且不同的request handler需要做不同的变更,这非常容易出错; 在xml中配置没有这个问题,因为pipeline体系各valve自己已经决定了下一个出口,不需要调用者操心。 总结一下,pipeline体系中的处理结点是特殊的API,它们有高度统一的接口和更高的自恰性,组装起来比普通API更容易,所以应对功能变更的能力也更强。