Hystrix断路器

概述

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败

服务雪崩

多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”,如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”

对于高流量的应用来说,单—的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。

所以,通常当你发现—个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。

Hystrix概述

Hystriⅸ是—个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等, Hystriⅸ能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。

“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应( FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩

Hystrix作用

停更说明



官方推荐使用 Resilience4j ,而国内大多数使用 Sentinel

Hystrix重要概念

服务降级

服务器忙,请稍后再试,不让客户端等待并立刻返回一个友好提示, fallback

在以下情况下发生降级:

  • 程序运行异常
  • 超时
  • 服务熔断触发服务降级
  • 线程池/信号量打满也会导致服务降级

服务熔断

类比保险丝达到最大服务访问后,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示

服务的降级->进而熔断->恢复调用链路

服务限流

秒杀高并发等操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序进行

测试案例

  1. 创建一个新的 module
  2. 导入 hystrix pom依赖
<!-- netflix-hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
  1. 新增配置文件
server:
port: 8003 spring:
application:
name: provider-hystrix-service
datasource:
username: root
password: 123456
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://localhost:3306/springcloud?useUnicode=true&charaterEncoding=utf-8&serverTimezone=Asia/Shanghai
type: com.alibaba.druid.pool.DruidDataSource # Eureka 省略 # 整合 mybatis
mybatis:
type-aliases-package: com.he.entities
mapper-locations: classpath:mapper/*.xml

4.Service 层

/**
* 正常访问成功 测试方法
* @param id
* @return
*/
String paymentInfo_success(@Param("id") Long id); /**
* 测试超时失败 测试方法
* @param id
* @return
*/
String paymentInfo_Timeout(@Param("id") Long id); # ServiceImpl类
@Override
public String paymentInfo_success(Long id) {
return "Success线程池" + Thread.currentThread().getName() + "paymentInfo,id:" + id;
} @Override
public String paymentInfo_Timeout(Long id) {
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "Timeout线程池" + Thread.currentThread().getName() + "paymentInfo,id:" + id;
}
  1. Controller 层
/**
* 测试正常连接
* @param id
* @return
*/
@GetMapping(value = "/payment/success/{id}")
public String paymentInfo_success(@PathVariable(value = "id") Long id){
String result = paymentService.paymentInfo_success(id);
log.info(result);
return serverPort;
} /**
* 超时测试
* @return
*/
@GetMapping(value = "/payment/timeout/{id}")
public String paymentInfo_Timeout(@PathVariable(value = "id") Long id){
String result = paymentService.paymentInfo_Timeout(id);
log.info(result);
return serverPort;
}

模拟复杂业务和简单业务测试,以这为根基,从正确=>错误=>降级熔断=>恢复

Jmeter 测试高并发情况

服务者测试

Jmeter 压力测试工具:http://jmeter.apache.org/

测试20000个并发访问超时测试 paymentInfo_Timeout 的方法



保存测试发送 HTTP 请求



测试结果:

正常访问的 success 也开始变得缓慢,这种高并发情况下,tomcat的默认的工作线程数被打满了,没有多余的线程来分解压力和处理。

上面还是服务提供者8001自己测试,假如此时外部的消费者80也来访问那消费者只能干等,最终导致消费端80不满意,服务端8001直接被拖死

消费者测试

搭配 Feign 来使用

  1. 新建 module
  2. pom依赖
<!-- openfeign -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<!-- netflix-hystrix -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

3.yml 配置

server:
port: 80 spring:
application:
name: consumer-service # Eureka 省略 # 设置 Feign 客户端的超时控制(OpenFeign默认支持 Ribbon)
ribbon:
# 指的是建立连接所用的超时时间,适用于网络状况正常的情况下,两端连接所用的时间
ReadTimeout: 5000
# 指的是建立连接后从服务器读取到可用资源所用的时间
ConnectTimeout: 5000 # 日志功能
logging:
level:
# Feign 日志以什么级别监管哪个接口
com.he.service.PaymentFeignService: debug
  1. 主启动类开启 @EnableFeignClients
  2. Service 层
@Component
@FeignClient(value = "PROVIDER-HYSTRIX-SERVICE")
public interface PaymentHystrixService { /**
* 测试正常连接
* @param id
* @return
*/
@GetMapping(value = "/payment/success/{id}")
public String paymentInfo_success(@PathVariable(value = "id") Long id); /**
* 超时测试
* @return
* @param id
*/
@GetMapping(value = "/payment/timeout/{id}")
public String paymentInfo_timeout(@PathVariable(value = "id") Long id);
}
  1. Controller 层
@RestController
@Slf4j
public class OrderHystrixController { @Resource
PaymentHystrixService paymentHystrixService; /**
* 测试正常连接
* @param id
* @return
*/
@GetMapping(value = "/consumer/payment/success/{id}")
public String paymentInfo_success(@PathVariable(value = "id") Long id){
String result = paymentHystrixService.paymentInfo_success(id);
log.info(result);
return result;
} /**
* 超时测试
* @return
*/
@GetMapping(value = "/consumer/payment/timeout/{id}")
public String paymentInfo_Timeout(@PathVariable(value = "id") Long id){
String result = paymentHystrixService.paymentInfo_timeout(id);
log.info(result);
return result;
}
}
  1. 高并发测试

    出现转圈等待,或者直接消费端爆超时错误



    故障现象和导致原因
  • 8001同一层次的其它接口服务被困死,因为tomcat线程池里面的工作线程已经被挤占完毕80,此 时调用8001,客户端访问响应缓慢,转圈圈
  • 超时导致服务器变慢(转圈):超时不再等待
  • 出错(宕机或程序运行出错):出错要有兜底

解决方法

服务降级

降级配置:@HystrixCommand

服务提供者

设置自身调用超时时间的峰值,峰值内可以正常运行,超过了需要有兜底的方法处理,作服务降级 fallback

一旦调用服务方法失败并抛出了错误信息后,会自动调用@HystrixCommand标注好的fallback Method调用类中的指定方法

  • 业务类
/**
* 此时当这个程序跑满,要设置一个方法来进行兜底,fallbackMethod = "TimeoutHandler"
* @param id
* @return
*/
@Override
@HystrixCommand(fallbackMethod = "TimeoutHandler")
public String paymentInfo_Timeout(Long id) {
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "Timeout线程池" + Thread.currentThread().getName() + "paymentInfo,id:" + id;
} /**
* 超时后的回调处理方法
* @param id
* @return
*/
@Override
public String TimeoutHandler(Long id){
return "TimeoutHandler:" + Thread.currentThread().getName() + "paymentInfo,id:" + id;
}
  • 主启动类激活 @EnableCircuitBreaker

服务消费者

我们自己配置过的热部署方式对java代码的改动明显,旦对@HystrixCommand内属性的修改建议重启微服务

  • 配置 yml 配置文件
# 开启 hystrix
feign:
hystrix:
enabled: true
  • 业务类
/**
* 超时测试
* @return
*/
@GetMapping(value = "/consumer/payment/timeout/{id}")
@HystrixCommand(fallbackMethod = "TimeoutHandler",commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "5000")
})
public String paymentInfo_Timeout(@PathVariable(value = "id") Long id){
String result = paymentHystrixService.paymentInfo_timeout(id);
log.info(result);
return result;
} /**
* 超时后的回调处理方法
* @param id
* @return
*/
public String TimeoutHandler(Long id){
return "消费者 TimeoutHandler:" + Thread.currentThread().getName() + "系统繁忙或者运行超时,请稍后再试";
}

问题

每个业务方法都需要一个回调的方法,这样会使得代码膨胀,重复造轮子

进行统一和自定义分开,进行设置全局fallback方法和特殊自定义方法

通用和独享的各自分开

全局配置

除了个别重要核心业务有专属,其它普通的可以通过@DefaultProperties(default Fallback=")统一跳转到统处理结果页

  • 业务类
@RestController
@Slf4j
@DefaultProperties(defaultFallback = "CommandFallBack")
public class OrderHystrixController {
@Resource
PaymentHystrixService paymentHystrixService; ...... /**
* 全局配置 FallBack 方法
* @return
*/
public String CommandFallBack(){
return "全局异常处理信息,请稍后再试";
}
}



面临问题

在客户端这种情况下,虽然解决了不需要每个方法去配置,直接用全局配置,但是与业务逻辑混合在一起,会造成高耦合的情况

还可能面对的异常,运行时异常,超时异常,宕机异常

  • 宕机异常

    下面针对 Feign 接口进行配置

    服务降级,客户端去调用服务端,碰上服务端宕机或关闭,这案例服务降级处理是在客户端实现完成的,与服务端没有关系

    只需要为 Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦,针对接口进行解耦

    解耦以后统一做服务降级
  1. 重新创建一个类PaymentFallbackService,实现 Feign 接口,统一为接口里的方法进行异常处理

    当调用 PaymentHystrixService接口 里的方法,服务端宕机或者关闭,会直接到 PaymentFallbackService 这个类里返回对应的回调方法
@Component
public class PaymentFallbackService implements PaymentHystrixService {
@Override
public String paymentInfo_success(Long id) {
return "服务端连接失败";
} @Override
public String paymentInfo_timeout(Long id) {
return "服务端连接失败,请稍后重试";
}
}
  1. 配置 yml 文件
# 开启 hystrix
feign:
hystrix:
enabled: true
  1. PaymentHystrixService接口,进行调用
@FeignClient(value = "PROVIDER-HYSTRIX-SERVICE",fallback = PaymentFallbackService.class)

测试,正常启动Eureka集群,服务端和消费端,测试访问正常,这时把服务端停掉,模拟宕机,客户端再进行访问服务端

就会出现刚才配置的宕机异常时的服务降级,让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器

服务熔断

熔断机制概述

熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇岀链路的棊个微服务岀错不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。

当检测到该节点微服务调用响应正常后,恢复调用链路。

在 Spring Cloud框架里,熔断机制通过 Hystrix实现。Hystⅸ会监控微服务间调用的状况当失败的调用到定阈值,缺省是5秒内20次调用失败,就会启动熔断机制。

熔断机制的注解是@ HystrixCommand

熔断测试

  1. 修改服务端 Service 层
// 服务熔断
/**
* 断路器,服务熔断,如果出错,就由 paymentCircuitBreaker_Fallback 这个方法来回调
* (name = "circuitBreaker.enabled",value = "true") :是否开启断路器
* (name = "circuitBreaker.requestVolumeThreshold",value = "10") :请求次数
* (name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000") : 时间窗口期
* (name = "circuitBreaker.errorThresholdPercentage",value = "60") : 失败率达到多少后跳闸
*
* @param id
* @return
*/
@Override
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_Fallback",commandProperties = {
@HystrixProperty(name = "circuitBreaker.enabled",value = "true"),
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),
@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"),
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),
})
public String paymentCircuitBreaker(Long id){
if (id < 0){
throw new RuntimeException("id 不能为负数");
}
return "提供者CircuitBreaker:" + Thread.currentThread().getName();
} /**
* 断路器回调的方法
* @param id
* @return
*/
public String paymentCircuitBreaker_Fallback(Long id){
return "id 不能为负数,id:" + id;
}
  1. controller 层
/**
* 服务熔断测试
* @param id
* @return
*/
@GetMapping(value = "/payment/circuitBreaker/{id}")
public String paymentCircuitBreaker(@PathVariable(value = "id")Long id){
String result = paymentService.paymentCircuitBreaker(id);
log.info(result);
return result;
}
  1. 此时当访问负数时,正常进入方法



    进行连续错误十几次的调用后,输入正数进行调用



    可以看到此时服务器已经熔断,正常访问已经不行了,过一段时间后,恢复正常

官方说明:https://github.com/Netflix/Hystrix/wiki/How-it-Works

涉及到断路器的三个重要参数:快照时间窗、请求总数阀值、错误百分比阀值

  • 快照时间窗(sleepWindowInMilliseconds):断路器确定是否打开需要统计一些请求和错误数据,而统计的时间范围就是快照时间窗,默认为最近的10秒
  • 请求总数阀值(requestVolumeThreshold):在快照时间窗内,必须满足请求总数阀值才有资格熔断。默认为20,意味着在10秒内,如果该 hysterⅸ命令的调用次数不足20次,即使所有的请求都超时或其他原因失败,断路器都不会打开
  • 错误百分比阀值(errorThresholdPercentage):当请求总数在快照时间窗内超过了阀值,比如发生了30次调用,如果在这30次调用中,有15次发生了超时异常,也就是超过50%的错误百分比,在默认设定50%阀值情况下,这时候就会将断路器打开

基本流程

  • 当满足一定的阀值的时候(默认10秒内超过20个请求次数)
  • 当失败率达到之定的时候(默认10秒内超过50%的请求失败)
  • 到达以上阀值,断路器将会开启
  • 当开启的时候,所有请求都不会进行转发
  • 一段时间之后(默认是5秒),这个时候断路器是半开状态,会让其中一个请求进行转发如果成功,断路器会关闭,若失败,继续开启。重复4和5

在 HystrixCommandProperties 这个类中也详细说明



原理



熔断类型:

  • Open 打开:请求不再进行调用当前服务,内部设置时钟一般为MTTR(平均故障处理时间),当打开时长达到所设时钟则进入半熔断状态
  • Closed 关闭:熔断关闭不会对服务进行熔断部分请求
  • Half Open 半开:根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断



    常用配置
@HystrixCommand(fallbackMethod = "str_ fallbackMethod",
groupKey = "strGroupCommand",
commanakey = "strCommand",
threadPoolKey = "strThreadPool", commandProperties = {
//设隔离策略,THREAD表示线程池 SEMAPHORE:信号燃隔离
@HystrixProperty (name = "execution.isolation.strategy",value ="THREAD"),
//当隔离策略选择信号地隔离的时候,用来设置信号地的大小(最大并发数)
@HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests",value ="10"),
//配置命令执行的超时时间
@HystrixProperty(name = "execution.isolation.thread.timeoutinMilliseconds", value="10"),
//是否启用超时时间
@HystrixProperty(name = "execution.timeout.enabled",value="true"),
//执行超时的时候是否中断
@HystrixProperty(name = "execution.isolation.thread.interruptonTimeout",value ="true"),
//允许回调方法执行的最大并发数
@HystrixProperty(name = "fallback.isolation.semaphore.maxConcurrentRequests",value ="10"),
//服务降级是否启用,是否执行回调函数
@HystrixProperty(name = "fallback.enabled", value ="true"),
//是否启用断路器
@HystrixProperty(name = "circuitBreaker.enabled", value ="true"),
//该属性用来设置在滚动时间窗中,断路器熔断的最小请求数,例如,默认该值为20的时候,
//如果动时间窗(计10秒)内仅收到19个请求,即使这19个请求部失败了,断路器也不会打开。
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "20"),
//该属性用来设置当断路器打开之后的体眠时间窗。
//休眠时间窗结柬之后,会将断路器置为"半开”状态,尝试熔断的请求命令,
//如果依然失败就将断路器继续设置为“打开”状态,如果成功就设置为“关闭”状态
@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "5000"),
//该属性用来设置在动时间窗中,
//表示在动时间窗中,在请求数量超过circuitBreaker. requestVolume Threshold的情况下,
//如错误请求数的百分比超过50就把断路器设置为"打开”状态,否则就设置为"关团”扰态。
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "50"),
//断路器强制打开
@HystrixProperty(name = "circuitBreaker.forceOpen",value = "false"),
//断路器强制关闭
@HystrixProperty(name = "circuitBreaker.forceClosed",value = "false"),
//滚动时间窗设置,该时间用于断路器判断健康度时需要收集信的持续时间
@HystrixProperty(name = "metrics.rollingStats.timeinMilliseconds",value = "10000"),
//该属性用来设置滚动时间窗统计指标信息时划分“桶”的数量,断路器在收集指标信息的时候
//会根据设置的时间窗长度拆分成多个“桶”来累计各度量值,每个“桶”记录了一段时间内的来集指标
//比如10秒内拆分成10个“桶”收集这样,所以 timeinMilliseconds必须能被 numBuckets整除。否则会抛异常
@HystrixProperty(name = "metrics.rollingStats.numBuckets",value = "10"),
//该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果设置为 false,那么所有的概受统计都将返回-1。
@HystrixProperty(name = "metrics.rollingPercentile.enabled",value = "false"),
//该属性用来设置百分位统计的滚动窗口的持续时间,单位为毫秒。
@HystrixProperty(name = "metrics.rollingPercentile.timeinMilliseconds",value = "60000"),
//该属性用来没置百分位统计动口中使用“桶”的数量。
@HystrixProperty(name = "metrics.rollingPercentile.numBuckets",value = "60000"),
//该属性用来置在执过程中每个“桶”中保的最大执行次数。如在滚动时间窗内发生超过核定值的执行次数,
//就从最初的位置开始重写。例如,将该值没置为100,滚动窗口为10秒,若在10秒内一个“桶”中发生了500执行,
//那么该“桶”中只保留最后的100的热行的统计。另外,增加该值的大小将会增加内存量的消耗,并增加排序百分位数所需的计算时间。
@HystrixProperty(name = "metrics.rollingPercentile.bucketSize",value = "100"),
//该属性用来设置来采集影响断路器状态的健康快照(请求的成功、错误百分比)的间隔等待时间
@HystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds",value = "500"),
//是否开启缓存
@HystrixProperty(name = "requestCache.enabled",value = "true"),
//HystrixCommand的执行和事件是否打印日志到 HystrixRequestLog
@HystrixProperty(name = "requestLog.enabled",value = "true"),
},
threadPollProperties = {
//该参数用来设置执行命令线程地的核心线程数,该值也就是命令执行的最大并发量
@HystrixProperty(name = "coreSize",value = "10"),
//该参数用来设置线程地的最大队列大小。当设置为-1时,线程池将使用 SynchronousQueue实现的队列,
//否则将使用 LinkedBLockingQueue实现的队列
@HystrixProperty(name = "maxQueueSize",value = "-1"),
//该参数用来为队列设置拒绝阀值。过该参数,即使队列没有达到最大值也能拒绝请求
//该参数主要是对 LinkedBLockingQueue队列的补充,
//因为LinkedBlockingQueue队列不能动态修改它的对象大小,而通过该属性就可纵调整拒绝请求的队列大小了。
@HystrixProperty(name = "queueSizeRejectionTreshold,value = "5"),
}
)
服务监控

服务监控hystrixDashboard

除了隔离依赖服务的调用以外, Hystrix还提供了实时的调用监控( Hystrix Dashboard), Hystrix 会持续地记录所有通过 Hystrix 发记的请求的执行信息,并以统计报表和图形的形式展示给用户,包括每秒执行多少请求多少成功,多少失败等。Netifx通过hystrix-metrics-event-stream项目实现了对以上指标的监控。 Spring Cloudi提供了 Hystrix Dashboard的整合,对监控内容转化成可视化界面。

  1. pom依赖
<!-- hystrix-dashboard -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
  1. yml 配置文件
server:
port: 9001
  1. 主启动类加上开启注解 @EnableHystrixDashboard
  2. 测试启动 访问 http://localhost:9001/hystrix

监控断路器测试

注意:新版本 Hystrix 需要在主启动类中指定监控路径

  1. Pom依赖

    图形化界面需要的依赖
<!-- spring-boot-starter-actuator -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency> <!-- spring-boot-starter-web -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
  1. 主启动类添加配置
@SpringBootApplication
@EnableEurekaClient
@EnableDiscoveryClient
@RestController
@EnableHystrix
@EnableHystrixDashboard
@EnableCircuitBreaker
public class ServiceHiApplication { /**
* 访问地址 http://localhost:8003/hystrix.stream
* @param args
*/ public static void main(String[] args) {
SpringApplication.run( ServiceHiApplication.class, args );
} @Value("${server.port}")
String port; @RequestMapping("/hi")
@HystrixCommand(fallbackMethod = "hiError")
public String home(@RequestParam(value = "name", defaultValue = "forezp") String name) {
return "hi " + name + " ,i am from port:" + port;
} public String hiError(String name) {
return "hi,"+name+",sorry,error!";
} }

如果不添加这个配置,监控平台就会出现



3. 监控熔断器测试 http://localhost:8003/hystrix.stream



最新文章

  1. MongoDB-安装&amp;启动
  2. read
  3. libsvm使用详细说明
  4. Yslow网站性能优化工具
  5. zookeeper 集群搭建
  6. 边工作边刷题:70天一遍leetcode: day 89
  7. thinkphp模型层Model、Logic、Service讲解
  8. does not match bootstrap parameter
  9. 将商品SKU数据按商品分组,组装成json数据
  10. Android Studio SDK Manager无法正常下载如何设置
  11. Android驱动之 Linux Input子系统之TP——A/B(Slot)协议
  12. 网络编程TCP协议-聊天室
  13. Omi教程-使用group-data通讯
  14. SQL SERVER大话存储结构(2)_非聚集索引如何查找到行记录
  15. vue2+webpack使用1--初识默认展示页面
  16. sql server 常用的查询语句
  17. 关于EffictiveC++笔记
  18. Windows下查看硬连接引用技术
  19. XML 和 JSON
  20. window bat 运行 cmd 命令

热门文章

  1. STL栈
  2. 00.从0实现一个JVM语言系列
  3. 微信小程序和H5之间相互跳转
  4. Python数据格式:%s字符串,%d整型,%f浮点型
  5. 微信小程序在Android和Ios端的获取时间兼容性问题
  6. Python基础【基本数据类型】
  7. 如何在 ASP.Net Core 中实现 健康检查
  8. POj1860(floyd+正权回路)
  9. javaIO中的序列化和反序列化
  10. CVE-2020-1472 Zerologon