前言:


最近忙着微服务项目的开发,脱更了半个月多,今天项目的初版已经完成,所以打算继续我们的微服务学习,由于Hystrix这一块东西好多,只好多拆分几篇文章写,对于一般对性能要求不是很高的项目中,可以使用其基础上开发的Feign进行容错保护。Hystrix学到现在我认为它的好处在于可以更灵活的调整熔断时间和自定义的线程隔离策略,设置请求缓存与请求合并,还可以降低被调用服务的负载,配合仪表盘和Turbine进行服务状态监控等,更加深入的还请阅读书籍,理解浅薄,还望看官莫笑。 由于篇幅有限,请求合并的使用放在下一篇博客中

本文主要浅析Hystrix的请求缓存的使用

前情提要:


之前我们学习了自定义HystrixCommand,包括继承和注解两种方式实现了同步请求和异步请求,也正是这里我们开始使用了整个的项目管理我们的代码,防止了项目过于分散丢笔记的情况。

如果是和我一样在搭建并测试的,请来Github clone我的项目,地址是:https://github.com/HellxZ/SpringCloudLearn 欢迎大家对这个项目提建议。

正文:


在高并发的场景中,消费者A调用提供者B,如果请求是相同的,那么重复请求势必会加重服务提供者B的负载,一般我们做高并发场景会理所应当的想到用缓存,那么针对这种情况Hystrix有什么方式来应对么?

Hystrix有两种方式来应对高并发场景,分别是请求缓存与请求合并

回顾一下我们前几篇文章中搭建的服务提供者项目,它会在有请求过来的时候打印此方法被调用。为了这次的测试,我们先在服务提供者项目中提供一个返回随机数的接口,作为测试请求缓存的调用的接口,方便验证我们的看法。

在EurekaServiceProvider项目中的GetRequestController中添加如下方法

    /**
* 为了请求测试Hystrix请求缓存提供的返回随机数的接口
*/
@GetMapping("/hystrix/cache")
public Integer getRandomInteger(){
Random random = new Random();
int randomInt = random.nextInt(99999);
return randomInt;
}
注意:以下有些注释写的很清楚的地方,就不重复写了

接下来我们先介绍请求缓存

请求缓存

请求缓存是在同一请求多次访问中保证只调用一次这个服务提供者的接口,在这同一次请求第一次的结果会被缓存,保证同一请求中同样的多次访问返回结果相同。

PS:在写这篇文章之前,本人将Hystrix与Redis进行了类比,后来证明我是理解错了。在认识到问题的情况下,我又重新为这篇文章重写了正确的代码

正解:请求缓存不是只写入一次结果就不再变化的,而是每次请求到达Controller的时候,我们都需要为HystrixRequestContext进行初始化,之前的缓存也就是不存在了,我们是在同一个请求中保证结果相同,同一次请求中的第一次访问后对结果进行缓存,缓存的生命周期只有一次请求!

这里分别介绍使用继承和使用注解两种方式,这里使用前文用到的RibbonConsumHystix项目

1. 1继承方式

1.1.1 开启请求缓存 与 清除请求缓存

com.cnblogs.hellxz.hystrix包下,因为和UserCommand类中的返回值不同,为了不破坏已有代码,我们在hystrix新建一个CacheCommand类,如下:

package com.cnblogs.hellxz.hystrix;

import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandKey;
import com.netflix.hystrix.HystrixRequestCache;
import com.netflix.hystrix.strategy.concurrency.HystrixConcurrencyStrategyDefault;
import org.springframework.web.client.RestTemplate; /**
* <p><b>描 述</b>: 请求缓存HystrixCommand</p>
*
* <p><b>创建日期</b> 2018/5/18 10:26 </p>
*
* @author HELLXZ 张
* @version 1.0
* @since jdk 1.8
*/
public class CacheCommand extends HystrixCommand<Integer> { private RestTemplate restTemplate;
private static Long id; public CacheCommand(Setter setter, RestTemplate restTemplate, Long id){
super(setter);
this.restTemplate = restTemplate;
this.id = id;
} /**
* 这里我们调用产生随机数的接口
*/
@Override
protected Integer run() throws Exception {
return restTemplate.getForObject("http://eureka-service/hystrix/cache",Integer.class);
} /**
* 开启请求缓存,只需重载getCacheKey方法
* 因为我们这里使用的是id,不同的请求来请求的时候会有不同cacheKey所以,同一请求第一次访问会调用,之后都会走缓存
* 好处: 1.减少请求数、降低并发
* 2.同一用户上下文数据一致
* 3.这个方法会在run()和contruct()方法之前执行,减少线程开支
*/
@Override
public String getCacheKey() {
return String.valueOf(id); //这不是唯一的方法,可自定义,保证同一请求返回同一值即可
} /**
* 清理缓存
* 开启请求缓存之后,我们在读的过程中没有问题,但是我们如果是写,那么我们继续读之前的缓存了
* 我们需要把之前的cache清掉
* 说明 : 1.其中getInstance方法中的第一个参数的key名称要与实际相同
* 2.clear方法中的cacheKey要与getCacheKey方法生成的key方法相同
* 3.注意我们用了commandKey是test,大家要注意之后new这个Command的时候要指定相同的commandKey,否则会清除不成功
*/
public static void flushRequestCache(Long id){
HystrixRequestCache.getInstance(
HystrixCommandKey.Factory.asKey("test"), HystrixConcurrencyStrategyDefault.getInstance())
.clear(String.valueOf(id));
} public static Long getId() {
return id;
} }

说明一下,使用继承的方式,只需要重写getCacheKey(),有了开启缓存自然有清除缓存的方法,用以确保我们在同一请求中进行写操作后,让后续的读操作获取最新的结果,而不是过时的结果。

需要注意的地方:

1.flushRequestCache(Long id),其中.clear()中的cacheKey的生成方法相同,只有把正确需要清除的key清掉才会连同value一同清掉,从而达到清除缓存的作用。
2.清除缓存时机:我们应该在同一个Controller中进行写操作之后,如果这个操作之后还有访问同一资源的请求,那么必须加清除缓存,从而保证数据同步,如果后面没有读操作,无须清除缓存,因为在下一次请求到来的时候HystrixRequestContext会重置,缓存自然也没有了

为了更好的演示,这里扩充一下RibbonService,添加如下代码:

    /**
* 继承方式开启请求缓存,注意commandKey必须与清除的commandKey一致
*/
public void openCacheByExtends(){
CacheCommand command1 = new CacheCommand(com.netflix.hystrix.HystrixCommand.Setter.withGroupKey(
HystrixCommandGroupKey.Factory.asKey("group")).andCommandKey(HystrixCommandKey.Factory.asKey("test")),
restTemplate,1L);
CacheCommand command2 = new CacheCommand(com.netflix.hystrix.HystrixCommand.Setter.withGroupKey(
HystrixCommandGroupKey.Factory.asKey("group")).andCommandKey(HystrixCommandKey.Factory.asKey("test")),
restTemplate,1L);
Integer result1 = command1.execute();
Integer result2 = command2.execute();
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
} /**
* 继承方式清除请除缓存
*/
public void clearCacheByExtends(){
CacheCommand.flushRequestCache(1L);
LOGGER.info("请求缓存已清空!");
}

RibbonController添加如下代码,设计实验:

    /**
* 继承方式开启请求缓存,并多次调用CacheCommand的方法
* 在两次请求之间加入清除缓存的方法
*/
@GetMapping("/cacheOn")
public void openCacheTest(){
//初始化Hystrix请求上下文
HystrixRequestContext.initializeContext();
//开启请求缓存并测试两次
service.openCacheByExtends();
//清除缓存
service.clearCacheByExtends();
//再次开启请求缓存并测试两次
service.openCacheByExtends();
}
注意:之前说过,每次Controller被访问的时候,Hystrix请求的上下文都需要被初始化,这里可以用这种方式作测试,但是生产环境是用filter的方式初始化的,这种方式放到请求缓存的结尾讲

分别启动注册中心、服务提供者、RibbonConsumHystrix(当前项目)

使用postman get 请求访问:http://localhost:8088/hystrix/cacheOn

我们会看到有以下输出:

2018-05-18 12:41:42.274  INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService   : first request result is:63829 ,and secend request result is: 63829
2018-05-18 12:41:42.274 INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService : 请求缓存已清空!
2018-05-18 12:41:42.281 INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService : first request result is:65775 ,and secend request result is: 65775

达到目的,接下来我们讲讲注解的方式!

1.2 注解方式

继承方式自然没有注解开发快而且省力,想必大家期待已久了,在此之前我们需要了解三个注解:

注解 描述 属性
@CacheResult 该注解用来标记请求命令返回的结果应该被缓存,它必须与@HystrixCommand注解结合使用 cacheKeyMethod
@CacheRemove 该注解用来让请求命令的缓存失效,失效的缓存根据commandKey进行查找。 commandKey,cacheKeyMethod
@CacheKey 该注解用来在请求命令的参数上标记,使其作为cacheKey,如果没有使用此注解则会使用所有参数列表中的参数作为cacheKey value

本人实测总结三种注解方式均可用,实现大同小异,与大家分享之

1.2.1 方式1 :使用getCacheKey方法获取cacheKey

扩充RibbonService

    /**
* 使用注解请求缓存 方式1
* @CacheResult 标记这是一个缓存方法,结果会被缓存
*/
@CacheResult(cacheKeyMethod = "getCacheKey")
@HystrixCommand(commandKey = "commandKey1")
public Integer openCacheByAnnotation1(Long id){
//此次结果会被缓存
return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
} /**
* 使用注解清除缓存 方式1
* @CacheRemove 必须指定commandKey才能进行清除指定缓存
*/
@CacheRemove(commandKey = "commandKey1", cacheKeyMethod = "getCacheKey")
@HystrixCommand
public void flushCacheByAnnotation1(Long id){
LOGGER.info("请求缓存已清空!");
//这个@CacheRemove注解直接用在更新方法上效果更好
} /**
* 第一种方法没有使用@CacheKey注解,而是使用这个方法进行生成cacheKey的替换办法
* 这里有两点要特别注意:
* 1、这个方法的入参的类型必须与缓存方法的入参类型相同,如果不同被调用会报这个方法找不到的异常
* 2、这个方法的返回值一定是String类型
*/
public String getCacheKey(Long id){
return String.valueOf(id);
}

扩充RibbonController

    /**
* 注解方式请求缓存,第一种
*/
@GetMapping("/cacheAnnotation1")
public void openCacheByAnnotation1(){
//初始化Hystrix请求上下文
HystrixRequestContext.initializeContext();
//访问并开启缓存
Integer result1 = service.openCacheByAnnotation1(1L);
Integer result2 = service.openCacheByAnnotation1(1L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
//清除缓存
service.flushCacheByAnnotation1(1L);
//再一次访问并开启缓存
Integer result3 = service.openCacheByAnnotation1(1L);
Integer result4 = service.openCacheByAnnotation1(1L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
}
测试

使用postman get 请求访问 http://localhost:8088/hystrix/cacheAnnotation1

查看输出
2018-05-18 15:39:11.971  INFO 4180 --- [nio-8088-exec-5] o.s.web.bind.annotation.RestController   : first request result is:59020 ,and secend request result is: 59020
2018-05-18 15:39:11.972 INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService : 请求缓存已清空!
2018-05-18 15:39:11.979 INFO 4180 --- [nio-8088-exec-5] o.s.web.bind.annotation.RestController : first request result is:51988 ,and secend request result is: 51988

测试通过!

1.2.2 方式2 :使用@CacheKey指定cacheKey

扩充RibbonService

    /**
* 使用注解请求缓存 方式2
* @CacheResult 标记这是一个缓存方法,结果会被缓存
* @CacheKey 使用这个注解会把最近的参数作为cacheKey
*
* 注意:有些教程中说使用这个可以指定参数,比如:@CacheKey("id") , 但是我这么用会报错,网上只找到一个也出这个错误的贴子没解决
* 而且我发现有一个问题是有些文章中有提到 “不使用@CacheResult,只使用@CacheKey也能实现缓存” ,经本人实测无用
*/
@CacheResult
@HystrixCommand(commandKey = "commandKey2")
public Integer openCacheByAnnotation2(@CacheKey Long id){
//此次结果会被缓存
return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
} /**
* 使用注解清除缓存 方式2
* @CacheRemove 必须指定commandKey才能进行清除指定缓存
*/
@CacheRemove(commandKey = "commandKey2")
@HystrixCommand
public void flushCacheByAnnotation2(@CacheKey Long id){
LOGGER.info("请求缓存已清空!");
//这个@CacheRemove注解直接用在更新方法上效果更好
}

扩充RibbonController

    /**
* 注解方式请求缓存,第二种
*/
@GetMapping("/cacheAnnotation2")
public void openCacheByAnnotation2(){
//初始化Hystrix请求上下文
HystrixRequestContext.initializeContext();
//访问并开启缓存
Integer result1 = service.openCacheByAnnotation2(2L);
Integer result2 = service.openCacheByAnnotation2(2L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
//清除缓存
service.flushCacheByAnnotation2(2L);
//再一次访问并开启缓存
Integer result3 = service.openCacheByAnnotation2(2L);
Integer result4 = service.openCacheByAnnotation2(2L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
}
测试

使用postman get 请求访问 http://localhost:8088/hystrix/cacheAnnotation2

查看输出
2018-05-18 15:40:49.803  INFO 4180 --- [nio-8088-exec-6] o.s.web.bind.annotation.RestController   : first request result is:47604 ,and secend request result is: 47604
2018-05-18 15:40:49.804 INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService : 请求缓存已清空!
2018-05-18 15:40:49.809 INFO 4180 --- [nio-8088-exec-6] o.s.web.bind.annotation.RestController : first request result is:34083 ,and secend request result is: 34083

测试通过!

1.2.3 方式3 :使用默认所有参数作为cacheKey

扩充RibbonService

    /**
* 使用注解请求缓存 方式3
* @CacheResult 标记这是一个缓存方法,结果会被缓存
* @CacheKey 使用这个注解会把最近的参数作为cacheKey
*
* 注意:有些教程中说使用这个可以指定参数,比如:@CacheKey("id") , 但是我这么用会报错,网上只找到一个也出这个错误的贴子没解决
* 而且我发现有一个问题是有些文章中有提到 “不使用@CacheResult,只使用@CacheKey也能实现缓存” ,经本人实测无用
*/
@CacheResult
@HystrixCommand(commandKey = "commandKey3")
public Integer openCacheByAnnotation3(Long id){
//此次结果会被缓存
return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
} /**
* 使用注解清除缓存 方式3
* @CacheRemove 必须指定commandKey才能进行清除指定缓存
*/
@CacheRemove(commandKey = "commandKey3")
@HystrixCommand
public void flushCacheByAnnotation3(Long id){
LOGGER.info("请求缓存已清空!");
//这个@CacheRemove注解直接用在更新方法上效果更好
}

扩充RibbonController

    /**
* 注解方式请求缓存,第三种
*/
@GetMapping("/cacheAnnotation3")
public void openCacheByAnnotation3(){
//初始化Hystrix请求上下文
HystrixRequestContext.initializeContext();
//访问并开启缓存
Integer result1 = service.openCacheByAnnotation3(3L);
Integer result2 = service.openCacheByAnnotation3(3L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
//清除缓存
service.flushCacheByAnnotation3(3L);
//再一次访问并开启缓存
Integer result3 = service.openCacheByAnnotation3(3L);
Integer result4 = service.openCacheByAnnotation3(3L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
}
测试

使用postman get 请求访问 http://localhost:8088/hystrix/cacheAnnotation3

查看输出
2018-05-18 15:41:19.655  INFO 4180 --- [nio-8088-exec-8] o.s.web.bind.annotation.RestController   : first request result is:24534 ,and secend request result is: 24534
2018-05-18 15:41:19.656 INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService : 请求缓存已清空!
2018-05-18 15:41:19.662 INFO 4180 --- [nio-8088-exec-8] o.s.web.bind.annotation.RestController : first request result is:85409 ,and secend request result is: 85409

测试通过!

1.4 出现的问题

1.4.1 HystrixRequestContext 未初始化
2018-05-17 16:57:22.759 ERROR 5984 --- [nio-8088-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.netflix.hystrix.exception.HystrixRuntimeException: UserCommand failed while executing.] with root cause

java.lang.IllegalStateException: Request caching is not available. Maybe you need to initialize the HystrixRequestContext?
at com.netflix.hystrix.HystrixRequestCache.get(HystrixRequestCache.java:104) ~[hystrix-core-1.5.12.jar:1.5.12]
……省略多余输出……

初始化HystrixRequestContext方法:

两种方法

1、在每个用到请求缓存的Controller方法的第一行加上如下代码:

        //初始化Hystrix请求上下文
HystrixRequestContext context = HystrixRequestContext.initializeContext();
//省略中间代码上下文环境用完需要关闭
context.close();

2、使用Filter方式:

在启动类加入@ServletComponentScan注解

在con.cnblogs.hellxz.filter包下创建HystrixRequestContextServletFilter.java,实现Filter接口,在doFilter方法中添加方法1中的那一行代码,并在一次请求结束后关掉这个上下文

package com.cnblogs.hellxz.filter;

import com.netflix.hystrix.strategy.concurrency.HystrixRequestContext;
import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import java.io.IOException; /**
* <b>类名</b>: HystrixRequestContextServletFilter
* <p><b>描 述</b>: 实现Filter用于初始化Hystrix请求上下文环境</p>
*
* <p><b>创建日期</b>2018/5/18 16:13</p>
* @author HELLXZ 张
* @version 1.0
* @since jdk 1.8
*/
@WebFilter(filterName = "hystrixRequestContextServletFilter",urlPatterns = "/*",asyncSupported = true)
public class HystrixRequestContextServletFilter implements Filter {
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
//初始化Hystrix请求上下文
HystrixRequestContext context = HystrixRequestContext.initializeContext();
try {
//请求正常通过
chain.doFilter(request, response);
} finally {
//关闭Hystrix请求上下文
context.shutdown();
}
} @Override
public void init(FilterConfig filterConfig) throws ServletException { } @Override
public void destroy() { }
}

此时注释掉RibbonController中每个Controller方法中的HystrixRequestContext.initializeContext();(不注掉也没事)

重启RibbonConsumHystrix项目,访问其中用到请求缓存的接口http://localhost:8088/hystrix/cacheAnnotation1

查看输出
2018-05-18 16:17:36.002  INFO 7268 --- [nio-8088-exec-4] o.s.web.bind.annotation.RestController   : first request result is:35329 ,and secend request result is: 35329
2018-05-18 16:17:36.005 INFO 7268 --- [RibbonService-8] c.cnblogs.hellxz.servcie.RibbonService : 请求缓存已清空!
2018-05-18 16:17:36.013 INFO 7268 --- [nio-8088-exec-4] o.s.web.bind.annotation.RestController : first request result is:88678 ,and secend request result is: 88678

一切正常!

结语


通过这篇文章我们学习了Hystrix的请求缓存的使用,在写本文过程中纠正了很多只看书学到的错误知识,并不是说书中写错了,可能是spring cloud的不同版本所造成的问题,所以,学习还是推荐大家动手实践。受限于篇幅的限制,本来是想把请求合并一并写出来的,想了下暂时请求合并的代码我还没有测试通过,所以,综上所述,请求合并部分,我会在下篇文章中写。可能不会快,但一定会有。


本文引用文章出处:

  1. Request caching is not available. Maybe you need to initialize the HystrixRequestContext?
  2. Spring Cloud中Hystrix的请求缓存
  3. Spring Cloud @HystrixCommand和@CacheResult注解使用,参数配置
>声明:本文为本人实操笔记,如需转载请注明出处:https://www.cnblogs.com/hellxz/p/9056806.html

Spring-cloud (八) Hystrix 请求缓存的使用的更多相关文章

  1. Spring Cloud中Hystrix、Ribbon及Feign的熔断关系是什么?

    导读 今天和大家聊一聊在Spring Cloud微服务框架实践中,比较核心但是又很容易把人搞得稀里糊涂的一个问题,那就是在Spring Cloud中Hystrix.Ribbon以及Feign它们三者之 ...

  2. Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失问题分析

    最近spring boot项目中由于使用了spring cloud 的hystrix 导致了threadLocal中数据丢失,其实具体也没有使用hystrix,但是显示的把他打开了,导致了此问题. 导 ...

  3. 架构师系列文:通过Spring Cloud组件Hystrix合并请求

    在前文里,我们讲述了通过Hystrix进行容错处理的方式,这里我们将讲述通过Hystrix合并请求的方式 哪怕一个URL请求调用的功能再简单,Web应用服务都至少会开启一个线程来提供服务,换句话说,有 ...

  4. Spring Cloud断路器Hystrix

    在微服务架构中,存在着那么多的服务单元,若一个单元出现故障,就会因依赖关系形成故障蔓延,最终导致整个系统的瘫痪,这样的架构相较传统架构就更加的不稳定.为了解决这样的问题,因此产生了断路器模式. 什么是 ...

  5. Spring Cloud之Hystrix服务保护框架

    服务保护利器 微服务高可用技术 大型复杂的分布式系统中,高可用相关的技术架构非常重要. 高可用架构非常重要的一个环节,就是如何将分布式系统中的各个服务打造成高可用的服务,从而足以应对分布式系统环境中的 ...

  6. Spring Cloud 之 Hystrix.

    一.概述  在微服务架构中,我们将系统拆分成了很多服务单元,各单元的应用间通过服务注册与订阅的方式互相依赖.由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依 ...

  7. 详解Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失

    在Spring Cloud中我们用Hystrix来实现断路器,Zuul中默认是用信号量(Hystrix默认是线程)来进行隔离的,我们可以通过配置使用线程方式隔离. 在使用线程隔离的时候,有个问题是必须 ...

  8. 为Spring Cloud Ribbon配置请求重试(Camden.SR2+)

    当我们使用Spring Cloud Ribbon实现客户端负载均衡的时候,通常都会利用@LoadBalanced来让RestTemplate具备客户端负载功能,从而实现面向服务名的接口访问. 下面的例 ...

  9. 从零开始学spring cloud(十一) -------- hystrix监控

    一.官方文档阅读 服务启动后,可以通过/health和hystrix.stream查看效果,实际上,访问上述两个地址,会出现404,这是因为spring boot版本的问题, 我在这里使用的sprin ...

随机推荐

  1. come on,逆战

    腾讯游戏       琳琅天上        逆战                                                                            ...

  2. fstream使用简介

    fstream用来进行输入/输出文件的操作. fstream file1; 定义了fstream类的一个对象file1file1.open("filename",...) 打开名为 ...

  3. POJ (线段相交 最短路) The Doors

    题意: 一个正方形中有n道竖直的墙,每道墙上开两个门.求从左边中点走到右边中点的最短距离. 分析: 以起点终点和每个门的两个端点建图,如果两个点可以直接相连(即不会被墙挡住),则权值为两点间的欧几里得 ...

  4. open MMT.distributions = null on transaction type: WIP Lot Split

    open MMT.distributions = null on transaction type:  WIP Lot Split       打开物料事务处理界面,发现事务处理类型为:WIP Lot ...

  5. APP打包提交审核的步骤

  6. str 操作

    str 认识字符串(重点, 多) 字符: 单一的文字符号 字符按照固定的顺序连成串 被' 或者" 或者''' 或者"""括起来的内容 索引 编号, 顺序 从0开 ...

  7. CentOS7.4 + Hadoop2.7.5安装配置管理(伪分布式)

    1.  规划 1.1.  机器列表 NameNode SecondaryNameNode DataNodes 192.168.1.80 192.168.1.80 192.168.1.80 1.2.  ...

  8. 安装 android4.0 到 vmware的注意点

    我发现无论如何,wmware上是出不来声音的. 我放弃 android-x86-4.3-20130725.iso 在 声音上有问题 现在安装这个版本: android-x86-4.0-RC2-eeep ...

  9. Spring集成Mybatis配置文件的简单理解

    详情可见官方文档http://www.mybatis.org/spring/zh/index.html 一.需要配置的对象实例 1.SqlSessionFactoryBean 在 MyBatis-Sp ...

  10. 本地搭建sass运行环境

    1.安装node.js 安装文件为msi文件,可到node.js官网下载安装包,下载路径为:https://nodejs.org/en/download/ 安装路径为默认路径,安装完成之后配置环境变量 ...