亚马逊入驻自贸区将改变什么？境外代购哪种更省钱？

August 27, 2014, 10:40 am

8 月 20 日，亚马逊宣布将入驻自贸区的消息在国内外引发了广泛讨论，同时也将海淘、境外代购推上了风口浪尖。事实上，真正参与海淘、境外代购的人数仅占普通消费人群的极小部分，但随着全球市场的不断发展，跨境购物势必将成为不可避免的大趋势。那么，亚马逊入驻自贸区到底意味着什么，它与海淘、境外代购之间又有着什么样的区别？作为普通消费者的我们，应该做何选择呢？

亚马逊入驻自贸区：开启全新跨境购物模式

在亚马逊正式入驻自贸区之前，国人跨境购物主要有两种形式，一是海淘，一是境外代购。海淘是消费者亲自上境外购物网站（例如美亚、eBay）购买商品，并委托转运公司将商品邮回国内；境外代购则是委托在境外的他人为自己购买商品（例如淘宝的全球购）并邮寄回国。尽管两者的渠道不同，但都是由于购物不便、省钱、对国内产品质量不信任等原因而产生。

而亚马逊入驻自贸区，便意味着我们有了一种全新的、官方认可的跨境购物方式。它将包括两种模式：一是直邮，即商品在境外，亚马逊通过国际物流直接将其送到消费者手中；二是 自贸区仓储模式，即亚马逊在自贸区内建立境外商品仓库，商品的运送通过自有物流完成。总体看来，直邮模式将作为亚马逊在初期的主要方式，而未来，自贸区仓储模式则会成为主流。毕竟，亚马逊在上海自贸区设立的可不只是仓库，更是国际贸易总部，它将成为亚马逊全球业务的中心所在。

那么，海淘、境外代购以及未来的亚马逊跨境购物模式到底有什么不同呢？我们用一张图来让大家更直观清晰的看到整个购物流程：

从上图可以看到，亚马逊跨境购物优势在于它将大大缩短物流时间，也不用操心物品在运输途中损坏、赔偿的问题，更不必担忧它可能会被海关查税、甚至扣押。当然，这也意味着你不可避免的需要付出一些行邮税，而这些税费将根据你的商品品类和价值来收取。与之相比，海淘与境外代购的优势，则是可能避免掉税务上的支出，且在当下看来，实际被抽税的商品也并不算多。

关于“行邮税”：指海关对入境旅客行李物品和个人邮递物品征收的进口税。

长远来看，全球市场的商品价格差异终将逐渐缩小，而国内高昂的税率也并不一定会永久存在，所以我们尝试着排除掉价格和不可控的税务因素，只是把购物的安全与便捷性作为考量标准，对上述几种跨境购物模式做了一个比较：

无疑， 亚马逊自贸区仓储模式将是最为安全、便捷的，事实上就像直接通过中国亚马逊购物一样；与之相比， 亚马逊直邮模式则需耗费更多时间（根据官方测试来看，从美国直邮中国，大约需要 7-10 天），且由于直邮多采用空运，在邮费方面的负担也会更大，加上商品运输时间越长，安全性自然也会降低。

再看看当下我们常用的海淘与境外代购模式：选择海淘，意味着我们不得不让商品通过转运公司来邮递，增加的一层运输过程将带来商品的安全保障降低、费用增加等可能存在的问题，并且往往需要等上一个月才可能收到商品；选择 境外代购，则必须给代购人支付一定的“辛苦费”，代购服务水平、商品的物流渠道与运输时长更是参差不齐。如此看来，海淘与境外代购在购物安全和便捷性方面的存在着不少不可控的问题，而两者在价格方面的优势，也意味着还需面临海关抽税、扣押的风险。

如何聪明的跨境购物？

据悉，亚马逊入驻自贸区后，并不打算搞价格战，所有商品都将按照商品品类与售价收取相应的行邮税。依据中国海关总署的相关规定，行邮税分为 10%、20%、30%、50% 四档税率，详细的划分可以看看下图：

值得一提的是，凡是税费在 50 元以下的，可直接减免。至于最终实施的细则，无论是亚马逊还是自贸区方面，都暂未作出回应。

这里，我们回到一开始的话题：境外代购哪种更省钱： 当需要购买一些日常生活用品时，通过亚马逊跨境购物渠道完成，既快又安全，并且能尽可能的避免和节省税费； 当需要购买稍贵一些的数码、家电类产品时，则可以考虑在海淘与亚马逊跨境购物渠道间进行对比， 倘若愿意接受亚马逊跨境渠道需要多支付的金额，来保证商品的安全性（尤其数码类），则不妨选择从自贸区拿货或是直邮； 当购买的商品已是高端腕表、化妆品等高税率级别（30-50%），海淘或许会是一个更为经济省钱的方式（即便被海关抽税，税费也可能相差不多），这时你需要的将是找一家靠谱的转运公司来保障物品的安全；而 当你需要购买一些限量的、非亚马逊商品时，代购或许能帮助你更多。

总的来说，尽管亚马逊跨境购物渠道尚未正式开启，但其影响力已经开始显现。它天生具备的方便、快速、安全优势将改变当下跨境购物格局，让更多的消费者参与进来，去消费和挑选更好更满意的商品。同时，也可能促进国内海淘与境外代购市场的规范与转型。

我们认为，未来的海淘将变得更为系统化、专业化，在细分市场下有针对性的发展下去；而境外代购党们，也将经历一次大浪淘沙，那些靠着赚差价过活的代购人将很难再维持，而真正活下来的则会走向小众与精品化，从普通代购转型为买手，为国内消费者提供更多精致限量的、一定要加入人的审美眼光才能买到的商品。

↧

android回调函数总结

August 27, 2014, 9:12 am

≫ Next: 约架完毕，罗永浩扒下测评行业的底裤

≪ Previous: 亚马逊入驻自贸区将改变什么？境外代购哪种更省钱？

android回调函数总结

回调函数就是那些自己写的，但是不是自己来调，而是给别人来掉的函数。

消息响应函数就可以看成是回调函数，因为是让系统在合适的时候去调用。这不过消息响应函数就是为了处理消息的，
所以就拿出来单做一类了。其实本质上就是回调函数。

但是回调函数不是只有消息响应函数一种，比如在内核编程中，驱动程序就要提供一些回调函数，
当一个设备的数据读写完成后，让系统调用这些回调函数来执行一些后续工作。

回调函数赋予程序员这样一种能力，让自己编写的代码能够跳出正常的程序控制流，
适应具体的运行环境在正确的时间执行。

回调函数总结

别人给回调的定义：

所谓回调，就是对象A调用另一对象B中的某个方法b，然后B又在某个时候反过来调用A中的某个函数c，对于B来说，这个c便叫做回调函数。
回调是一种双向调用模式，也就是说，被调用方在接口被调用时也会调用对方的接口.

我的理解，和一般的类之间的组合类似。就只是A对象调用B对象的一个方法b。只不过方法b是抽象的，是后期绑定的。

java回调代码。

    1，定义回调接口。
复制代码

package com.smart;
/**
* 定义回调接口
*/
public   interface CallBack {
    void execute();
}

package com.smart;
/**
* 定义回调接口
*/
public interface CallBack {
    void execute();
}

package com.smart;
/**
* 工具类
*/
public   class Tools {
    public   void test(CallBack callBack){
        long begin = System.currentTimeMillis(); //测试起始时间
        callBack.execute();///进行回调操作
        long end = System.currentTimeMillis(); //测试结束时间
        System.out.println("[use time]:" + (end - begin)); //打印使用时间

    }
    public   static   void main(String[] args){
        Tools tools = new Tools();
        tools.test(new CallBack(){
            public   void execute() {
                //A.method(); 测试类A的某个方法执行的时间
                //B.method(); 测试类B的某个方式执行的时间
                System.out.print("回调" );
            }
        });
    }
}

package com.smart;
/**
* 工具类
*/
public class Tools {
    public void test(CallBack callBack){
        long begin = System.currentTimeMillis();//测试起始时间
        callBack.execute();///进行回调操作
        long end = System.currentTimeMillis();//测试结束时间
        System.out.println("[use time]:" + (end - begin));//打印使用时间

    }
    public static void main(String[] args){
        Tools tools = new Tools();
        tools.test(new CallBack(){
            public void execute() {
                //A.method(); 测试类A的某个方法执行的时间
                //B.method(); 测试类B的某个方式执行的时间
                System.out.print("回调");
            }
        });
    }
}

   优点：我个人认为优点主要是将代码中变与不变的部分相分离,从而大大提高了程序的重用性和扩展性。

已有 0人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

↧

约架完毕，罗永浩扒下测评行业的底裤

August 27, 2014, 9:08 am

≫ Next: Spring MVC 3 深入总结

≪ Previous: android回调函数总结

经过几周的预热和三个多小时唇枪舌剑，罗永浩、王自如的吵架终于完毕。锤子确实又制造了一个新热点。Zealer也得到了宣传，不过这个宣传的效果恐怕是王自如始料未及的。

这个关注度很高的视频，让评测的一些黑幕公之于众，未必不是一件好事，只是Zealer 团队的公信力就会被质疑了。

一、互联网评测的乱象

其实，早期有评测的不是智能手机，而是电脑，最早的评测是在服务器上，为了评估服务器的性能有人专门写软件，是为了实际应用。后来PC进入家庭，也就有了相应的PC类评测软件。今天手机上的评测软件，很多前身就是PC上的评测软件。

有个评测工具以后，就有了对产品的评测。现在的汽车之家老板李想，当年做的网站叫显卡之家，后来改名叫PCPOP。在飞翔鸟之后，和小熊在线，Gzeasy、ZOL、Pconline都算是知名的网站。

应该说早年这些评测都是有一定水平的，Gzeasy的CHO甚至可以与芯片厂商的技术人员直接讨论技术细节问题，就差自己设计GPU了。

后来进入智能手机时代，各种爱好者自媒体出现，评测就变了。以前的媒体网站成立没有那么容易，早期甚至还要挂靠一个正规单位，有上级部门，不能乱来。

而新时代自媒体都是自己来，没有管理者，本身对产品的理解就是爱好者水平。更关键是没有管理、唯利是图，甚至给厂商利用当工具，这就乱了。

二、Zealer的问题

Zealer 初期是王自如作为一个爱好者的个人评测。做评测的很多，有的网站明码标价收评测费，有的爱好者只要求提供测试机，但是无论什么方式，各个厂商都应该一视同仁，你给我测试机，我给你出评测，优点缺点都说到，语气用词可以尽量不得罪你。

目前来看，Zealer 所做的已经不仅仅只是个发烧友，它需要盈利。所以玩的就有点出圈了。一方面标明自己公正、客观、独立、第三方，一方面拿厂家的咨询费，拿厂家的投资；一方面要建立评测标准，一方面标准是个黑箱，得分和表现完全对不起来，不可重复，不可验证。

这次被罗永浩吊打，根本原因还是收了锤子的咨询费不干活，反而替给钱更多的出力倒打一耙。这都能忍就不是罗永浩了。谁给钱，就帮谁打击竞争对手，甚至已经交了保护费的也不放过。

其实，我个人也不喜欢罗永浩的风格，对锤子产品本身也不好看，也写过一些文章分析问题。罗永浩看过，但只是让他的公关经理做技术上澄清，把商榷之处提出来，把确认的地方反馈给开发人员。

有网站也做锤子的跌落测试，锤子并没有做任何干预。

其实原因也很简单，某网站没拿锤子和其他厂商一分钱投资，测试用的锤子手机是自己花钱买的。而Zealer 是拿过小米等厂商投资，还拿了锤子咨询费的。

一段时间，Zealer 是被厂商投资的，也就是罗永浩说的被包养。经济不独立，人格难免被怀疑。

三、媒体应该有良心

辩论会后，某网站主编发博客，“我也想要有人投资，我也喜欢有人养我，我也收车马费。面对金主，我的原则是：我可以大量夸赞你优秀的地方，我可以对你的缺陷闭口不提，但是我真心做不到把你的缺陷包装成优点去夸赞。”

我个人认为，这个标准不算高，应该是缺点必须要提，但是注意语气婉转。绝口不提对消费者也会构成误导。

收钱了说好话，也说坏话，是良心；收了钱只说好话，不说坏话，是本分；收了钱，只替收钱的说话，打击没给钱的，甚至给钱少的也不放过，是黑社会，还是不讲规矩的那种。

希望这次罗永浩和王自如的辩论，能让不讲规矩的黑社会少一点。

↧

Spring MVC 3 深入总结

August 27, 2014, 8:53 am

≫ Next: Android4.4支持使用DevTools对原生Android应用程序WebViews内容进行调试

≪ Previous: 约架完毕，罗永浩扒下测评行业的底裤

一、前言：

大家好，Spring3 MVC是非常优秀的MVC框架，由其是在3.0版本发布后，现在有越来越多的团队选择了Spring3 MVC了。Spring3 MVC结构简单，应了那句话简单就是美，而且他强大不失灵活，性能也很优秀。

官方的下载网址是： http://www.springsource.org/download （本文使用是的Spring 3.0.5版本）

Struts2也是比较优秀的MVC构架，优点非常多比如良好的结构。但这里想说的是缺点，Struts2由于采用了值栈、OGNL表达式、struts2标签库等，会导致应用的性能下降。Struts2的多层拦截器、多实例action性能都很好。可以参考我写的一篇关于Spring MVC与Struts2与Servlet比较的文章 http://elf8848.iteye.com/admin/blogs/698217

Spring3 MVC的优点：

1、Spring3 MVC的学习难度小于Struts2，Struts2用不上的多余功能太多。呵呵，当然这不是决定因素。

2、Spring3 MVC很容易就可以写出性能优秀的程序，Struts2要处处小心才可以写出性能优秀的程序（指MVC部分）

3、Spring3 MVC的灵活是你无法想像的，Spring的扩展性有口皆碑，Spring3 MVC当然也不会落后，不会因使用了MVC框架而感到有任何的限制。

Struts2的众多优点：略... (呵呵，是不是不公平？)

众多文章开篇时总要吹些牛，吸引一下读者的眼球，把读者的胃口调起来，这样大家才有兴趣接着往后看。本文也没能例外。不过保证你看了之后不会后悔定有收获。

二、核心类与接口：

先来了解一下，几个重要的接口与类。现在不知道他们是干什么的没关系，先混个脸熟，为以后认识他们打个基础。

DispatcherServlet -- 前置控制器

HandlerMapping接口 -- 处理请求的映射

HandlerMapping接口的实现类：

SimpleUrlHandlerMapping 通过配置文件，把一个URL映射到Controller

DefaultAnnotationHandlerMapping 通过注解，把一个URL映射到Controller类上

HandlerAdapter接口 -- 处理请求的映射

AnnotationMethodHandlerAdapter类，通过注解，把一个URL映射到Controller类的方法上

Controller接口 -- 控制器

由于我们使用了@Controller注解，添加了@Controller注解注解的类就可以担任控制器（Action）的职责,

所以我们并没有用到这个接口。

HandlerInterceptor 接口--拦截器

无图，我们自己实现这个接口，来完成拦截的器的工作。

ViewResolver接口的实现类

UrlBasedViewResolver类通过配置文件，把一个视图名交给到一个View来处理

InternalResourceViewResolver类，比上面的类，加入了JSTL的支持

View接口

JstlView类

LocalResolver接口

HandlerExceptionResolver接口 --异常处理

SimpleMappingExceptionResolver实现类

ModelAndView类

无图。

三、核心流程图

本图是我个人画的，有不严谨的地方，大家对付看吧。总比没的看强。

四、DispatcherServlet说明

使用Spring MVC,配置DispatcherServlet是第一步。

DispatcherServlet是一个Servlet,所以可以配置多个DispatcherServlet。

DispatcherServlet是前置控制器，配置在web.xml文件中的。拦截匹配的请求，Servlet拦截匹配规则要自已定义，把拦截下来的请求，依据某某规则分发到目标Controller(我们写的Action)来处理。

“某某规则”：是根据你使用了哪个HandlerMapping接口的实现类的不同而不同。

先来看第一个例子：

Xml代码

<web-app>
<servlet>
<servlet-name>example </servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet </servlet-class>
<load-on-startup>1 </load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>example </servlet-name>
<url-pattern>*.form </url-pattern>
</servlet-mapping>
</web-app>

<load-on-startup>1</load-on-startup>是启动顺序，让这个Servlet随Servletp容器一起启动。

<url-pattern>*.form</url-pattern> 会拦截*.form结尾的请求。

<servlet-name>example</servlet-name>这个Servlet的名字是example，可以有多个DispatcherServlet，是通过名字来区分的。每一个DispatcherServlet有自己的WebApplicationContext上下文对象。同时保存的ServletContext中和Request对象中，关于key，以后说明。

在DispatcherServlet的初始化过程中，框架会在web应用的 WEB-INF文件夹下寻找名为[servlet-name]-servlet.xml 的配置文件，生成文件中定义的bean。

第二个例子：

Xml代码

<servlet>
<servlet-name>springMVC </servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet </servlet-class>
<init-param>
<param-name>contextConfigLocation </param-name>
<param-value>classpath*:/springMVC.xml </param-value>
</init-param>
<load-on-startup>1 </load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springMVC </servlet-name>
<url-pattern>/ </url-pattern>
</servlet-mapping>

指明了配置文件的文件名，不使用默认配置文件名，而使用springMVC.xml配置文件。

其中<param-value>**.xml</param-value> 这里可以使用多种写法
1、不写,使用默认值:/WEB-INF/<servlet-name>-servlet.xml
2、<param-value>/WEB-INF/classes/springMVC.xml</param-value>
3、<param-value>classpath*:springMVC-mvc.xml</param-value>
4、多个值用逗号分隔

Servlet拦截匹配规则可以自已定义，Servlet拦截哪种URL合适？

当映射为@RequestMapping("/user/add")时：
1、拦截*.do，例如：/user/add.do，弊端：所有的url都要以.do结尾。不会影响访问静态文件。
2、拦截/app/*，例如：/app/user/add，弊端：请求的url都要包含/app，@RequestMapping("/user/add")中不须要包含/app。
3、拦截/，例如：/user/add，弊端：对jpg,js,css静态文件的访问也被拦截不能正常显示。后面有解决办法。
4、拦截/*，可以走到Action中，但转发到jsp时再次被拦截，不能访问到jsp。

五、双亲上下文的说明

如果你使用了listener监听器来加载配置，一般在Struts+Spring+Hibernate的项目中都是使用listener监听器的。如下

Java代码

<listener>
<listener- class>org.springframework.web.context.ContextLoaderListener</listener- class>
</listener>

Spring会创建一个全局的WebApplicationContext上下文，称为 根上下文 ，保存在 ServletContext中，key是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE属性的值。可以使用工具类取出上下文：WebApplicationContextUtils.getWebApplicationContext(ServletContext);

DispatcherServlet是一个Servlet,可以同时配置多个，每个 DispatcherServlet有一个自己的 WebApplicationContext上下文，这个上下文继承了 根上下文 中所有东西。保存在 ServletContext中，key是"org.springframework.web.servlet.FrameworkServlet.CONTEXT"+Servlet名称。当一个Request对象产生时，会把这个WebApplicationContext上下文保存在Request对象中，key是DispatcherServlet.class.getName() + ".CONTEXT"。可以使用工具类取出上下文：RequestContextUtils.getWebApplicationContext(request);

Spring中的 ApplicationContext实例可以被限制在不同的作用域（scope）中。
在web MVC框架中，每个 DispatcherServlet有它自己的WebApplicationContext ，这个context继承了根 WebApplicationContext 的所有bean定义。
这些继承的bean也可以在每个serlvet自己的所属的域中被覆盖（override），覆盖后的bean 可以被设置上只有这个servlet实例自己使用的属性。

总结：不使用listener监听器来加载spring的配置，改用DispatcherServlet来加载spring的配置，不要双亲上下文，只使用一个DispatcherServlet，事情就简单了，什么麻烦事儿也没有了。

六、springMVC-mvc.xml 配置文件片段讲解 （未使用默认配置文件名）

Xml代码

<context:component-scan base-package="com.app,com.core,JUnit4" ></context:component-scan>
<mvc:annotation-driven />
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver" >
<property name="prefix" value="/WEB-INF/jsp/" />
<property name="suffix" value=".jsp" />
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
</bean>
<mvc:interceptors>
<bean class="com.core.mvc.MyInteceptor" />
</mvc:interceptors>
<mvc:default-servlet-handler/>
<mvc:resources mapping="/images/**" location="/images/" cache-period="31556926" />
<mvc:resources mapping="/js/**" location="/js/" cache-period="31556926" />
<mvc:resources mapping="/css/**" location="/css/" cache-period="31556926" />

<context:component-scan/> 扫描指定的包中的类上的注解，常用的注解有：

@Controller 声明Action组件
@Service    声明Service组件    @Service("myMovieLister")
@Repository 声明Dao组件
@Component   泛指组件, 当不好归类时.
@RequestMapping("/menu") 请求映射
@Resource 用于注入，( j2ee提供的 ) 默认按名称装配，@Resource(name="beanName")
@Autowired 用于注入，(srping提供的) 默认按类型装配
@Transactional( rollbackFor={Exception.class}) 事务管理
@ResponseBody
@Scope("prototype")   设定bean的作用域

<mvc:annotation-driven /> 是一种简写形式，完全可以手动配置替代这种简写形式，简写形式可以让初学都快速应用默认配置方案。<mvc:annotation-driven /> 会自动注册DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter 两个bean,是spring MVC为@Controllers分发请求所必须的。
并提供了：数据绑定支持，@NumberFormatannotation支持，@DateTimeFormat支持，@Valid支持，读写XML的支持（JAXB），读写JSON的支持（Jackson）。
后面，我们处理响应ajax请求时，就使用到了对json的支持。
后面，对action写JUnit单元测试时，要从spring IOC容器中取DefaultAnnotationHandlerMapping与AnnotationMethodHandlerAdapter 两个bean，来完成测试，取的时候要知道是<mvc:annotation-driven />这一句注册的这两个bean。

<mvc:interceptors/> 是一种简写形式。通过看前面的大图，知道，我们可以配置多个HandlerMapping。<mvc:interceptors/>会为每一个HandlerMapping，注入一个拦截器。其实我们也可以手动配置为每个HandlerMapping注入一个拦截器。

<mvc:default-servlet-handler/> 使用默认的Servlet来响应静态文件。

<mvc:resources mapping="/images/**" location="/images/" cache-period="31556926"/> 匹配URL /images/** 的URL被当做静态资源，由Spring读出到内存中再响应http。

七、如何访问到静态的文件，如jpg,js,css？

如何你的 DispatcherServlet拦截 *.do这样的URL，就不存在访问不到静态资源的问题。如果你的DispatcherServlet拦截“/”，拦截了所有的请求，同时对*.js,*.jpg的访问也就被拦截了。

目的：可以正常访问静态文件，不要找不到静态文件报404。

方案一：激活Tomcat的defaultServlet来处理静态文件

Xml代码

<servlet-mapping>
<servlet-name>default </servlet-name>
<url-pattern>*.jpg </url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default </servlet-name>
<url-pattern>*.js </url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default </servlet-name>
<url-pattern>*.css </url-pattern>
</servlet-mapping>
要配置多个，每种文件配置一个

要写在DispatcherServlet的前面，让 defaultServlet先拦截，这个就不会进入Spring了，我想性能是最好的吧。

Tomcat, Jetty, JBoss, and GlassFish 默认 Servlet的名字 -- "default"
Google App Engine 默认 Servlet的名字 -- "_ah_default"
Resin 默认 Servlet的名字 -- "resin-file"
WebLogic 默认 Servlet的名字 -- "FileServlet"
WebSphere 默认 Servlet的名字 -- "SimpleFileServlet"

方案二：在spring3.0.4以后版本提供了mvc:resources
mvc:resources 的使用方法：

Xml代码

<mvc:resources mapping="/images/**" location="/images/" />

/images/**映射到ResourceHttpRequestHandler进行处理，location指定静态资源的位置.可以是web application根目录下、jar包里面，这样可以把静态资源压缩到jar包中。cache-period 可以使得静态资源进行web cache

如果出现下面的错误，可能是没有配置<mvc:annotation-driven />的原因。
报错WARNING: No mapping found for HTTP request with URI [/mvc/user/findUser/lisi/770] in DispatcherServlet with name 'springMVC'

使用<mvc:resources/>元素,把mapping的URI注册到SimpleUrlHandlerMapping的urlMap中,
key为mapping的URI pattern值,而value为ResourceHttpRequestHandler,
这样就巧妙的把对静态资源的访问由HandlerMapping转到ResourceHttpRequestHandler处理并返回,所以就支持classpath目录,jar包内静态资源的访问.
另外需要注意的一点是,不要对SimpleUrlHandlerMapping设置defaultHandler.因为对static uri的defaultHandler就是ResourceHttpRequestHandler,
否则无法处理static resources request.

方案三，使用<mvc:default-servlet-handler/>

Xml代码

<mvc:default-servlet-handler/>

会把"/**" url,注册到SimpleUrlHandlerMapping的urlMap中,把对静态资源的访问由HandlerMapping转到org.springframework.web.servlet.resource.DefaultServletHttpRequestHandler处理并返回.
DefaultServletHttpRequestHandler使用就是各个Servlet容器自己的默认Servlet.

补充说明：多个HandlerMapping的执行顺序问题：

DefaultAnnotationHandlerMapping的order属性值是：0

<mvc:resources/ >自动注册的 SimpleUrlHandlerMapping的order属性值是： 2147483646

<mvc:default-servlet-handler/>自动注册的SimpleUrlHandlerMapping 的order属性值是： 2147483647

spring会先执行order值比较小的。当访问一个a.jpg图片文件时，先通过 DefaultAnnotationHandlerMapping 来找处理器，一定是找不到的，我们没有叫a.jpg的Action。再按order值升序找，由于最后一个 SimpleUrlHandlerMapping 是匹配 "/**"的，所以一定会匹配上，再响应图片。

访问一个图片，还要走层层匹配。真不知性能如何？改天做一下压力测试，与Apache比一比。

最后再说明一下，如何你的 DispatcherServlet拦截 *.do这样的URL，就不存上述问题了。

八、请求如何映射到具体的Action中的方法？
方案一：基于xml配置映射，可以利用SimpleUrlHandlerMapping、BeanNameUrlHandlerMapping进行Url映射和拦截请求。
配置方法略。

方案二：基于注解映射，可以使用DefaultAnnotationHandlerMapping。

Xml代码

<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" > </bean>

但前面我们配置了<mvc:annotation-driven />，他会自动注册这个bean,就不须要我们显示的注册这个bean了。

以上都可以注入interceptors，实现权限控制等前置工作。
我们使用第2种，基于注解来使用spring MVC

并在action类上使用：
@Controller
@RequestMapping("/user")

九、Spring中的拦截器：
Spring为我们提供了：
org.springframework.web.servlet.HandlerInterceptor接口，

org.springframework.web.servlet.handler.HandlerInterceptorAdapter适配器，
实现这个接口或继承此类，可以非常方便的实现自己的拦截器。

有以下三个方法：

Action之前执行:
public boolean preHandle(HttpServletRequest request,
   HttpServletResponse response, Object handler);

生成视图之前执行
public void postHandle(HttpServletRequest request,
   HttpServletResponse response, Object handler,
   ModelAndView modelAndView);

最后执行，可用于释放资源
public void afterCompletion(HttpServletRequest request,
   HttpServletResponse response, Object handler, Exception ex)

分别实现预处理、后处理（调用了Service并返回ModelAndView，但未进行页面渲染）、返回处理（已经渲染了页面）
在preHandle中，可以进行编码、安全控制等处理；
在postHandle中，有机会修改ModelAndView；
在afterCompletion中，可以根据ex是否为null判断是否发生了异常，进行日志记录。
参数中的Object handler是下一个拦截器。

十、如何使用拦截器？
自定义一个拦截器，要实现HandlerInterceptor接口：

Java代码

public class MyInteceptor implements HandlerInterceptor {
略。。。
}

Spring MVC并没有总的拦截器，不能对所有的请求进行前后拦截。
Spring MVC的拦截器，是属于HandlerMapping级别的，可以有多个HandlerMapping ，每个HandlerMapping可以有自己的拦截器。
当一个请求按Order值从小到大，顺序执行HandlerMapping接口的实现类时，哪一个先有返回，那就可以结束了，后面的HandlerMapping就不走了，本道工序就完成了。就转到下一道工序了。
拦截器会在什么时候执行呢？一个请求交给一个HandlerMapping时，这个HandlerMapping先找有没有处理器来处理这个请求，如何找到了，就执行拦截器，执行完拦截后，交给目标处理器。
如果没有找到处理器，那么这个拦截器就不会被执行。

在spring MVC的配置文件中配置有三种方法：

方案一，（近似）总拦截器，拦截所有url

Java代码

<mvc:interceptors>
<bean class="com.app.mvc.MyInteceptor" />
</mvc:interceptors>

为什么叫“近似”，前面说了，Spring没有总的拦截器。

<mvc:interceptors/>会为每一个HandlerMapping，注入一个拦截器。总有一个HandlerMapping是可以找到处理器的，最多也只找到一个处理器，所以这个拦截器总会被执行的。起到了总拦截器的作用。

方案二，（近似）总拦截器，拦截匹配的URL。

Xml代码

<mvc:interceptors >
<mvc:interceptor>
<mvc:mapping path="/user/*" />
<bean class="com.mvc.MyInteceptor" ></bean>
</mvc:interceptor>
</mvc:interceptors>

就是比方案一多了一个URL匹配。

方案三,HandlerMappint上的拦截器

Xml代码

<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping" >
<property name="interceptors" >
<list>
<bean class="com.mvc.MyInteceptor" ></bean>
</list>
</property>
</bean>

如果使用了<mvc:annotation-driven />，它会自动注册DefaultAnnotationHandlerMapping 与AnnotationMethodHandlerAdapter 这两个bean,所以就没有机会再给它注入interceptors属性，就无法指定拦截器。

当然我们可以通过人工配置上面的两个Bean，不使用 <mvc:annotation-driven />，就可以给interceptors属性注入拦截器了。

其实我也不建议使用<mvc:annotation-driven />，而建议手动写配置文件，来替代 <mvc:annotation-driven />，这就控制力就强了。

十一、如何实现全局的异常处理？

在spring MVC的配置文件中：

Xml代码

<bean id="exceptionResolver" class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver" >
<property name="defaultErrorView" >
<value>/error/error </value>
</property>
<property name="defaultStatusCode" >
<value>500 </value>
</property>
<property name="warnLogCategory" >
<value>org.springframework.web.servlet.handler.SimpleMappingExceptionResolver </value>
</property>
</bean>

这里主要的类是SimpleMappingExceptionResolver类，和他的父类AbstractHandlerExceptionResolver类。

具体可以配置哪些属性，我是通过查看源码知道的。

你也可以实现HandlerExceptionResolver接口，写一个自己的异常处理程序。spring的扩展性是很好的。

通过SimpleMappingExceptionResolver我们可以将不同的异常映射到不同的jsp页面（通过exceptionMappings属性的配置）。

同时我们也可以为所有的异常指定一个默认的异常提示页面（通过defaultErrorView属性的配置），如果所抛出的异常在exceptionMappings中没有对应的映射，则Spring将用此默认配置显示异常信息。

注意这里配置的异常显示界面均仅包括主文件名，至于文件路径和后缀已经在viewResolver中指定。如/error/error表示/error/error.jsp

显示错误的jsp页面：

Html代码

<%@ page language="java" contentType="text/html; charset=GBK"
pageEncoding="GBK"% >
<%@ page import="java.lang.Exception"% >
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" >
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=GBK" >
<title>错误页面 </title>
</head>
<body>
<h1>出错了 </h1>
<%
Exception e = (Exception)request.getAttribute("exception");
out.print(e.getMessage());
% >
</body>
</html>

其中一句：request.getAttribute("exception")，key是exception，也是在SimpleMappingExceptionResolver类默认指定的，是可能通过配置文件修改这个值的，大家可以去看源码。

参考文章：

http://www.blogjava.net/wuxufeng8080/articles/191150.html

http://fangjunai.blog.163.com/blog/static/1124970520108102013839/

十二、如何把全局异常记录到日志中？

在前的配置中，其中有一个属性warnLogCategory，值是“SimpleMappingExceptionResolver类的全限定名”。我是在SimpleMappingExceptionResolver类父类AbstractHandlerExceptionResolver类中找到这个属性的。查看源码后得知：如果warnLogCategory不为空，spring就会使用apache的org.apache.commons.logging.Log日志工具，记录这个异常，级别是warn。

值：“org.springframework.web.servlet.handler.SimpleMappingExceptionResolver”，是“SimpleMappingExceptionResolver类的全限定名”。这个值不是随便写的。因为我在log4j的配置文件中还要加入log4j.logger.org.springframework.web.servlet.handler.SimpleMappingExceptionResolver=WARN，保证这个级别是warn的日志一定会被记录，即使log4j的根日志级别是ERROR。

十三、如何给spring3 MVC中的Action做JUnit单元测试？

使用了spring3 MVC后，给action做单元测试也很方便，我以前从来不给action写单元测试的，再在不同了，方便了，所以一定要写。

JUnitActionBase类是所有JUnit的测试类的父类

Java代码

package test;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.junit.BeforeClass;
import org.springframework.mock.web.MockServletContext;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.XmlWebApplicationContext;
import org.springframework.web.servlet.HandlerAdapter;
import org.springframework.web.servlet.HandlerExecutionChain;
import org.springframework.web.servlet.HandlerMapping;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter;
import org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping;
/**
* 说明： JUnit测试action时使用的基类
*
* @author Kipa
* @version 创建时间：2011-2-2 下午10:27:03
*/
public class JUnitActionBase {
private static HandlerMapping handlerMapping;
private static HandlerAdapter handlerAdapter;
/**
* 读取spring3 MVC配置文件
*/
@BeforeClass
public static void setUp() {
if (handlerMapping == null) {
String[] configs = { "file:src/springConfig/springMVC.xml" };
XmlWebApplicationContext context = new XmlWebApplicationContext();
context.setConfigLocations(configs);
MockServletContext msc = new MockServletContext();
context.setServletContext(msc); context.refresh();
msc.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, context);
handlerMapping = (HandlerMapping) context
.getBean(DefaultAnnotationHandlerMapping. class);
handlerAdapter = (HandlerAdapter) context.getBean(context.getBeanNamesForType(AnnotationMethodHandlerAdapter. class)[0]);
}
}
/**
* 执行request对象请求的action
*
* @param request
* @param response
* @return
* @throws Exception
*/
public ModelAndView excuteAction(HttpServletRequest request, HttpServletResponse response)
throws Exception {
HandlerExecutionChain chain = handlerMapping.getHandler(request);
final ModelAndView model = handlerAdapter.handle(request, response,
chain.getHandler());
return model;
}
}

这是个JUnit测试类，我们可以new Request对象，来参与测试，太方便了。给request指定访问的URL，就可以请求目标Action了。

Java代码

package test.com.app.user;
import org.junit.Assert;
import org.junit.Test;
import org.springframework.mock.web.MockHttpServletRequest;
import org.springframework.mock.web.MockHttpServletResponse;
import org.springframework.web.servlet.ModelAndView;
import test.JUnitActionBase;
/**
* 说明：测试OrderAction的例子
*
* @author Kipa
* @version 创建时间：2011-2-2 下午10:26:55
*/
public class TestOrderAction extends JUnitActionBase {
@Test
public void testAdd() throws Exception {
MockHttpServletRequest request = new MockHttpServletRequest();
MockHttpServletResponse response = new MockHttpServletResponse();
request.setRequestURI("/order/add");
request.addParameter("id", "1002");
request.addParameter("date", "2010-12-30");
request.setMethod("POST");
// 执行URI对应的action
final ModelAndView mav = this.excuteAction(request, response);
// Assert logic
Assert.assertEquals("order/add", mav.getViewName());
String msg=(String)request.getAttribute("msg");
System.out.println(msg);
}
}

需要说明一下 ：由于当前最想版本的Spring(Test) 3.0.5还不支持@ContextConfiguration的注解式context file注入，所以还需要写个setUp处理下，否则类似于Tiles的加载过程会有错误，因为没有ServletContext。3.1的版本应该有更好的解决方案，参见： https://jira.springsource.org/browse/SPR-5243 。

参考： http://www.iteye.com/topic/828513

十四、转发与重定向

可以通过redirect/forward:url方式转到另一个Action进行连续的处理。

可以通过redirect:url 防止表单重复提交。

写法如下：

return "forward:/order/add";

return "redirect:/index.jsp";

十五、处理ajax请求

1、引入下面两个jar包，我用的是1.7.2，好像1.4.2版本以上都可以，下载地址： http://wiki.fasterxml.com/JacksonDownload

jackson-core-asl-1.7.2.jar

jackson-mapper-asl-1.7.2.jar

2、spring的配置文件中要有这一行，才能使用到spring内置支持的json转换。如果你手工把POJO转成json就可以不须要使用spring内置支持的json转换。

<mvc:annotation-driven />

3、使用@ResponseBody注解

Java代码

/**
* ajax测试
* http://127.0.0.1/mvc/order/ajax
*/
@RequestMapping("/ajax")
@ResponseBody
public Object ajax(HttpServletRequest request){
List<String> list= new ArrayList<String>();
list.add("电视");
nbsp; list.add("洗衣机");
list.add("冰箱");
list.add("电脑");
list.add("汽车");
list.add("空调");
list.add("自行车");
list.add("饮水机");
list.add("热水器");
return list;

已有 0人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

↧

Android4.4支持使用DevTools对原生Android应用程序WebViews内容进行调试

August 28, 2014, 6:46 am

≫ Next: 浅谈过载保护

≪ Previous: Spring MVC 3 深入总结

从Android4.4（KitKat）开始，可以使用DevTools对原生Android应用程序的Android WebViews内容进行调试。

调试WebViews要求：

1.在Android设备或模拟器运行Android4.4或更高版本，并且Android设备上启用USB调试模式。
2.Chrome 30或更高版本。更强大的WebView界面调试功能需要Chrome31或更高版本。
3.Android应用程序中的WebView配置为可调试模式。

配置WebViews为可调试：

在Chrome中启用设置“USB web debugging”不会影响WebViews。在WebView中进行调试，需要通过在应用程序中以编程方式调用WebView类的静态方法setWebContentsDebuggingEnabled。

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
   WebView.setWebContentsDebuggingEnabled(true);
}

注意web调测不受app manifest文件中debuggable标记状态的影响，如果希望仅debuggable为true时才能使用web调测，那么运行时检测此标记。

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
   if ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) ) {
   WebView.setWebContentsDebuggingEnabled(true);
   }
}

在DevTools中打开 WebView

在DevTools调试WebView：

1.使用USB数据线将移动设备连接到开发机器。
将移动设备连接到开发机器时，可能会看到USB调试警报“设备请求权限”。
为了避免每次调试时看到此警告，勾选“总是允许从这台计算机”，并单击“确定”。

2.在开发机器的Chrome上，打开检查about:inspect。

3.就能看到应用程序和调试的WebView列表的名称。单击旁边标签中inspect链接，就能在DevTools查看WebView的内容。

注：在Chrome 31及更高版本，about:inspect页面提供了一个图形表示WebView的大小和相对设备屏幕的位置。在Chrome 31之前：about:inspect页面仅支持提供的WebView的标题。设置WebViews标题的过程中，选择正确的WebView。

作者：offbye 发表于2014-8-28 13:46:35 原文链接

阅读：56 评论：0 查看评论

↧

浅谈过载保护

August 28, 2014, 6:39 am

≫ Next: JAVA爬虫Nutch、WebCollector的正则约束

≪ Previous: Android4.4支持使用DevTools对原生Android应用程序WebViews内容进行调试

浅谈过载保护

雪球：对于时延敏感的服务，当外部请求超过系统处理能力，如果系统没有做相应保护，可能导致历史累计的超时请求达到一定规模，像雪球一样形成恶性循环。由于系统处理的每个请求都因为超时而无效，系统对外呈现的服务能力为0，且这种情况下不能自动恢复。

作者bison，腾讯后台开发技术总监。

　　过载保护，看似简单，但是要做好并不容易。这里用两个曾经经历的反面案例，给出过载保护的直观展现，并附上一点感想。

案例一基本情况

　　如下图，进程A是一个单进程系统，通过udp套接字接收前端请求进行处理。在处理过程中，需要访问后端系统B，是同步的方式访问后端系统B，根据后端系统B的SLA，超时时间设置是100ms。前端用户请求的超时时间是1s。

　　进程A的时序是：

Step1: 从socket接收缓冲区接收用户请求

Step2: 进行本地逻辑处理

Step3: 发送请求到后端系统B

Step4: 等待后端系统B返回

Step5: 接收后端系统B的应答

Step6: 应答前端用户，回到step1处理下一个请求

正常情况下的负载

　　正常情况下：

1、前端请求报文大小约100Bytes。前端请求的峰值每分钟1800次，即峰值每秒30次。

2、后端系统B并行能力较高，每秒可以处理10000次以上，绝大多数请求处理时延在20ms内。

3、进程A在处理请求的时候，主要时延是在等待后端系统B，其他本地运算耗时非常少，小于1ms

　　这个时候，我们可以看出，系统工作良好，因为处理时延在20ms内，每秒进程A每秒中可以处理50个请求，足以将用户每秒峰值30个请求及时处理完。

导火索

　　某天，后端系统B进行了新特性发布，由于内部逻辑变复杂，导致每个请求处理时延从20ms延长至50ms，根据sla的100ms超时时间，这个时延仍然在正常范围内。当用户请求达到峰值时间点时，灾难出现了，用户每次操作都是“服务器超时无响应”，整个服务不可用。

过载分析

　　当后端系统B处理时延延长至50ms的时候，进程A每秒只能处理20个请求（1s / 50ms = 20 ）。小于正常情况下的用户请求峰值30次/s。这个时候操作失败的用户往往会重试，我们观察到前端用户请求增加了6倍以上，达到200次/s，是进程A最大处理能力（20次/s）的10倍！

　　这个时候为什么所有用户发现操作都是失败的呢？为什么不是1/10的用户发现操作能成功呢？因为请求量和处理能力之间巨大的差异使得5.6s内就迅速填满了socket接收缓冲区（平均能缓存1000个请求，1000/(200-20)=5.6s），并且该缓冲区将一直保持满的状态。这意味着，一个请求被追加到缓冲区里后，要等待50s（缓存1000个请求，每秒处理20个，需要50s）后才能被进程A 取出来处理，这个时候用户早就看到操作超时了。换句话说，进程A每次处理的请求，都已经是50s以前产生的，进程A一直在做无用功。雪球产生了。

案例二基本情况

　　前端系统C通过udp访问后端serverD，后端server D的udp套接字缓冲区为4MB，每个请求大小约400字节。后端serverD偶尔处理超时情况下，前端系统C会重试，最多重试2次。

正常情况下的负载

　　正常情况，后端serverD单机收到请求峰值为300次/s，后端serverD单机处理能力是每秒1500次，时延10ms左右。这个时候工作正常。

导火索

　　由于产品特性（例如提前通知大量用户，未来某某时刻将进行一项秒杀活动；类似奥运门票，大量用户提前得知信息：某日开始发售门票），大量的用户聚集在同一时刻发起了大量请求，超出了后台serverD的最大负载能力。操作响应失败的用户又重试，中间系统的重试，进一步带来了更大量的请求(正常情况下的9倍)。导致所有用户操作都是失败的。

过载分析

　　只是导火索不一样，同案例一，巨大的请求和处理能力之间的鸿沟，导致后端serverD的4M大小的接收缓冲区迅速填满（4秒就填满），且过载时间内，接收缓冲区一直都是满的。而处理完缓冲区内的请求，ServerD需要6秒以上（4MB / 400 / 1500 = 6.7S）。所以serverD处理的请求都是6s之前放入缓冲区的，而该请求在最前端早已经超时。雪球形成了。

启示

1、每个系统，自己的最大处理能力是多少要做到清清楚楚。例如案例一中的前端进程A，他的最大处理能力不是50次/s，也不是20次/S，而是10次/S。因为它是单进程同步的访问后端B，且访问后端B的超时时间是100ms，所以他的处理能力就是1S/100ms=10次/S。而平时处理能力表现为50次/S，只是运气好。

2、每个系统要做好自我保护，量力而为，而不是尽力而为。对于超出自己处理能力范围的请求，要勇于拒绝。

3、每个系统要有能力发现哪些是有效的请求，哪些是无效的请求。上面两个案例中，过载的系统都不具备这中慧眼，逮着请求做死的处理，雪球时其实是做无用功。

4、前端系统有保护后端系统的义务，sla中承诺多大的能力，就只给到后端多大的压力。这就要求每一个前后端接口的地方，都有明确的负载约定，一环扣一环。

5、当过载发生时，该拒绝的请求（1、超出整个系统处理能力范围的；2、已经超时的无效请求）越早拒绝越好。就像上海机场到市区的高速上，刚出机场就有电子公示牌显示，进入市区某某路段拥堵，请绕行。

6、对于用户的重试行为，要适当的延缓。例如登录发现后端响应失败，再重新展现登录页面前，可以适当延时几秒钟，并展现进度条等友好界面。当多次重试还失败的情况下，要安抚用户。

7、产品特性设计和发布上，要尽量避免某个时刻导致大量用户集体触发某些请求的设计。发布的时候注意灰度。

8、中间层server对后端发送请求，重试机制要慎用，一定要用的话要有严格频率控制。

9、当雪球发生了，直接清空雪球队列（例如重启进程可以清空socket 缓冲区）可能是快速恢复的有效方法。

10、过载保护很重要的一点，不是说要加强系统性能、容量，成功应答所有请求，而是保证在高压下，系统的服务能力不要陡降到0，而是顽强的对外展现最大有效处理能力。

　　对于“每个系统要有能力发现哪些是有效的请求，哪些是雪球无效的请求”，这里推荐一种方案：在该系统每个机器上新增一个进程：interface进程。Interface进程能够快速的从socket缓冲区中取得请求，打上当前时间戳，压入channel。业务处理进程从channel中获取请求和该请求的时间戳，如果发现时间戳早于当前时间减去超时时间（即已经超时，处理也没有意义），就直接丢弃该请求，或者应答一个失败报文。

　　Channel是一个先进先出的通信方式，可以是socket，也可以是共享内存、消息队列、或者管道，不限。

　　Socket缓冲区要设置合理，如果过大，导致及时interface进程都需要处理长时间才能清空该队列，就不合适了。建议的大小上限是：缓存住超时时间内interface进程能够处理掉的请求个数（注意考虑网络通讯中的元数据）。

作者：keda8997110 发表于2014-8-28 13:39:05 原文链接

阅读：11 评论：0 查看评论

↧

JAVA爬虫Nutch、WebCollector的正则约束

August 28, 2014, 6:08 am

≫ Next: hive 的分隔符、orderby sort by distribute by的优化

≪ Previous: 浅谈过载保护

爬虫爬取时，需要约束爬取的范围。基本所有的爬虫都是通过正则表达式来完成这个约束。

最简单的，正则：

http://www.xinhuanet.com/.*

代表"http://www.xinhuanet.com/"后加任意个任意字符（可以是0个）。

通过这个正则可以约束爬虫的爬取范围,但是这个正则并不是表示爬取新华网所有的网页。新华网并不是只有www.xinhuanet.com这一个域名，还有很多子域名，类似:news.xinhuanet.com

这个时候我们需要定义这样一个正则:

http://([a-z0-9]*\.)*xinhuanet.com/

这样就可以限制爬取新华网所有的网页了。

每种爬虫的正则约束系统都有一些区别，这里拿Nutch、WebCollector两家爬虫的正则系统做对比：

Nutch官网： http://nutch.apache.org/

WebCollector官网: http://crawlscript.github.io/WebCollector/

1.Nutch:

nutch的正则约束是依赖一个配置文件 conf/regex-urlfilter.txt 来实现的。例如：

+^http://www.xinhuanet.com/
+^http://news.xinhuanet.com/
-^http://blog.xinhuanet.com/

nutch的正则约束原则是：

1）逐行扫描，对每一行进行如下操作：

去掉正则前面的加号或减号，获取正则式。看待爬取网页的url中是否包含当前正则的模式。如果包含，看正则前的符合。如果为+，则当前url无需过滤，返回当前url，如果为-，则当前url需要过滤，返回null。如果待爬取网页url中不包含当前正则的模式，则跳过（继续下一行操作）。

2）如果扫描到文件结尾，都没有返回：

返回null。

有2个地方需要注意：

1）nutch的正则过滤时，采用的匹配函数式Patterm.matcher，而不是Patterm.matches。

Patterm.mather在匹配时，只要找到待爬取网页的url的子串和正则匹配，就通过。

Patterm.matcher要求待爬取网页的url和regex完全匹配。例如:

待爬取网页的网址是 http://www.xinhuanet.com/index.html

正则是^http://([a-z0-9]*\.)*xinhuanet.com

这个正则用Patterm.matcher和网页url可以匹配。因为网页url的字串http://www.xinhuanet.com和正则能匹配。

但是用Patterm.matches就不能匹配。正则需要改成^http://([a-z0-9]*\.)*xinhuanet.com.*才可以和网页的URL匹配。

也就是说nutch的正则其实是和找url中是否有字串符合正则。所以做nutch的正则配置文件时，要在http前加入^符号，如果正则没有加^符号，例如+http://www.xinhuanet.com ,下面网址也是可以匹配的:

http://www.abc.com/index.php?name=http://www.xinhuanet.com

2）nutch正则过滤时，是逐行扫描，一旦扫描到匹配行就返回结果。所以正则式的顺序很重要。例如可以通过下面的配置文件来完成全网爬取（需要过滤图片等文件为不爬取）：

-\.(gif|GIF|jpg|JPG|ico|ICO|css|sit|eps|wmf|zip|ppt|mpg|xls|gz|rpm|tgz|mov|MOV|exe)$
+.

先扫描第一行，遇到gif、JPG等文件，会匹配正则，由于前面符号是-,所以返回null，url被过滤。

如果当前url不对应gif、JPG等文件，会继续扫描第二行，第二行可以匹配任意字符串。由于前面符号是+，所以返回当前url，当前url被接受。

2.WebCollector:

WebCollector的正则约束是直接通过程序指定的：

BreadthCrawler crawler=new BreadthCrawler();
.....
.....
crawler.addRegex("+http://www\\.xinhuanet\\.com/.*");
crawler.addRegex("-http://www\\.xinhuanet\\.com/special/.*");
crawler.addRegex("-http://www\\.xinhuanet\\.com/info/.*");

WebCollector中正则有两种，正例正则，和反例正则。url要被接受，需要符合下面2个条件。

1.至少符合一条正例正则。

2.不能符合任意一条反例正则。

正例正则以+开头，反例正则以-开头（如果前面不加符号，默认是正例正则)。

上面代码中，http://www.xinhuanet.com/auto/index.html就可以被接受。因为它符合一条正例http://www.xinhuanet.com/.* ，不符合任意一条反例正则(http://www.xinhuanet.com/special/.*和http://www.xinhuanet.com/info/.*)。

必须给出至少一条正例正则，才可以进行爬取，如果没有正例正则，不能符合上面的条件一。

WebCollector中正则匹配采用的是Patterm.matches，要求正则与URL完全匹配。如果上面代码中你的正则写成+http://www.xinhuanet.com/，而不是+http://www.xinhuanet.com/.*，那么只有网页http://www.xinhuanet.com/可以被接受，网页http://www.xinhuanet.com/index.html就不能被接收。

下面给出一个例子，爬取新华网的news.xinhuanet.com子域名，过滤掉gif和jpg图像：

BreadthCrawler crawler=new BreadthCrawler();
.....
.....
crawler.addRegex("+http://news\\.xinhuanet\\.com/.*");
crawler.addRegex("-.*gif.*");
crawler.addRegex("-.*jpg.*");

作者：AJAXHu 发表于2014-8-28 13:08:55 原文链接

阅读：63 评论：0 查看评论

↧

hive 的分隔符、orderby sort by distribute by的优化

August 28, 2014, 6:06 am

≫ Next: 让你的Node.js应用跑得更快的10个技巧

≪ Previous: JAVA爬虫Nutch、WebCollector的正则约束

一、Hive 分号字符

分号是SQL语句结束标记，在HiveQL中也是，但是在HiveQL中，对分号的识别没有那么智慧，例如：

select concat(cookie_id,concat(';',’zoo’)) fromc02_clickstat_fatdt1 limit 2;

FAILED: Parse Error: line 0:-1 cannot recognize input'<EOF>' in function specification

可以推断，Hive解析语句的时候，只要遇到分号就认为语句结束，而无论是否用引号包含起来。

解决的办法是，使用分号的八进制的ASCII码进行转义，那么上述语句应写成：

select concat(cookie_id,concat('\073','zoo')) fromc02_clickstat_fatdt1 limit 2;

为什么是八进制ASCII码？

我尝试用十六进制的ASCII码，但Hive会将其视为字符串处理并未转义，好像仅支持八进制，原因不详。这个规则也适用于其他非SELECT语句，如CREATE TABLE中需要定义分隔符，那么对不可见字符做分隔符就需要用八进制的ASCII码来转义。

二、insert 新增数据

根据语法Insert必须加“OVERWRITE”关键字，也就是说每一次插入都是一次重写。那如何实现表中新增数据呢？

假设Hive中有表manbu,

hive> DESCRIBE manbu;

id int

value int

hive> SELECT * FROM manbu;

3 4

1 2

2 3

现增加一条记录:

hive> INSERT OVERWRITE TABLE manbu

SELECT id, value FROM (

SELECT id, value FROM manbu

UNION ALL

SELECT 4 AS id, 5 AS value FROM manbu limit 1

) u;

结果是:

hive>SELECT * FROM p1;

3 4

4 5

2 3

1 2

其中的关键在于, 关键字UNION ALL的应用, 即将原有数据集和新增数据集进行结合, 然后重写表.

三、初始值

INSERT OVERWRITE TABLE在插入数据时, 后面的字段的初始值应注意与表定义中的一致性. 例如, 当为一个STRING类型字段初始为NULL时:

NULL AS field_name // 这可能会被提示定义类型为STRING, 但这里是void

CAST(NULL AS STRING) AS field_name // 这样是正确的

又如, 为一个BIGINT类型的字段初始为0时:

CAST(0 AS BIGINT) AS field_name

四、orderby sort by distribute by的优化

Hive的排序关键字是SORT BY，它有意区别于传统数据库的ORDER BY也是为了强调两者的区别–SORT BY只能在单机范围内排序。

例如:

set mapred.reduce.tasks=2;(设置reduce的数量为2 )

原值:

1.selectcookie_id,page_id,id from c02_clickstat_fatdt1

where cookie_idIN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2')

1.193.148.164.1288609861509.2 113181412886099008861288609901078194082403 684000005

1.193.148.164.1288609861509.2 127001128860563972141288609859828580660473 684000015

1.193.148.164.1288609861509.2 113181412886099165721288609915890452725326 684000018

1.193.131.218.1288611279693.0 01c183da6e4bc50712881288611540109914561053 684000114

1.193.131.218.1288611279693.0 01c183da6e4bc22412881288611414343558274174 684000118

1.193.131.218.1288611279693.0 01c183da6e4bc50712881288611511781996667988 684000121

1.193.131.218.1288611279693.0 01c183da6e4bc22412881288611523640691739999 684000126

1.193.131.218.1288611279693.0 01c183da6e4bc50712881288611540109914561053 684000128

2. selectcookie_id,page_id,id from c02_clickstat_fatdt1 where

cookie_idIN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2')

SORT BYCOOKIE_ID,PAGE_ID;

SORT排序后的值

1.193.131.218.1288611279693.0 684000118 01c183da6e4bc22412881288611414343558274174 684000118

1.193.131.218.1288611279693.0 684000114 01c183da6e4bc50712881288611540109914561053 684000114

1.193.131.218.1288611279693.0 684000128 01c183da6e4bc50712881288611540109914561053 684000128

1.193.148.164.1288609861509.2 684000005 113181412886099008861288609901078194082403 684000005

1.193.148.164.1288609861509.2 684000018 113181412886099165721288609915890452725326 684000018

1.193.131.218.1288611279693.0 684000126 01c183da6e4bc22412881288611523640691739999 684000126

1.193.131.218.1288611279693.0 684000121 01c183da6e4bc50712881288611511781996667988 684000121

1.193.148.164.1288609861509.2 684000015 127001128860563972141288609859828580660473 684000015

selectcookie_id,page_id,id from c02_clickstat_fatdt1

where cookie_idIN('1.193.131.218.1288611279693.0','1.193.148.164.1288609861509.2')

ORDER BYPAGE_ID,COOKIE_ID;