心跳机制

1. TCP连接 当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的 经典的三次握手示意图： 经典的四次握手关闭图： 2. TCP短连接 我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作 短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段 3.TCP长连接 接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。 首先说一下TCP/IP详解上讲到的TCP保活功能

1. TCP连接 当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的。 经典的三次握手示意图： 经典的四次握手关闭图： 2. TCP短连接 我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作 短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段 3.TCP长连接 接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。 首先说一下TCP/IP详解上讲到的TCP保活功能

目录 前言 一、pom文件 二、配置项 三、消息类型分离器 四、编码器 五、解码器 六、公用控制器 七、客户端 八、客户端控制器 九、服务端 十、服务端控制器 十一、测试 1、启动服务端 2、启动客户端 3、客户端发消息 前言    本博客参考自 ： netty 实现长连接，心跳机制，以及重连    该大佬为 ： CN-LILU   参考上面的博客搭建之后可以成功实现长连接、心跳及重连并且原博主可进行消息通信。但是我这里并不能进行消息通信。   （ps：原文中在子线程创建channel的同时，主线程判断channel是否为空，我这边测试是一直失败的，也就是说我这边sendData循环1000遍之后，子线程创建channel有可能仍然没有成功。个人认为这之前应该有判断，而不是靠运气来判断主线程for的时间和子线程创建channel的时间。下面做一个简单测试：） package com . gzky . study ; import com . gzky . study . netty . MsgPckDecode ; import com . gzky . study . netty . MsgPckEncode ; import io . netty . bootstrap . Bootstrap ; import io . netty . channel . * ; import

import { baseUrl } from "../assets/js/baseUrl" ; class WS { ws : any | null = null ; timeOut : number = 5000 ; timer : any = null ; serverTimer : any = null ; connect ( ) { this . ws = new WebSocket ( baseUrl ) ; this . ws . onopen = function ( ) { this . initHeart ( ) ; //启动心跳机制 console . log ( "连接成功" ) ; } ; this . ws . onmessage = function ( evt : any ) { this . initHeart ( ) ; //重置心跳机制 var received_msg = evt . data ; console . log ( "数据已接收..." ) ; } ; this . ws . onerror = function ( ) { } ; this . ws . onclose = function ( ) { // 关闭 websocket console . log ( "关闭" ) ; } ; } close ( ) {

Cobar 是阿里巴巴开源的一个数据库中间件，为了解决类似proxy这类的问题。目前同类型的有奇虎360开源的Atlas。类似的有基本在线上用起来很不爽，问题多多的比如MySQL Proxy和SQL Relay，基本可以忽略。 Cobar 下载： https://github.com/alibaba/cobar Atlas 下载： https://github.com/Qihoo360/Atlas =============================================================== MyCat：取代Cobar数据库中间件 什么是MyCAT?简单的说，MyCAT就是： 一个彻底开源的，面向企业应用开发的“大数据库集群” 支持事务、ACID、可以替代Mysql的加强版数据库 ? 一个可以视为“Mysql”集群的企业级数据库，用来替代昂贵的Oracle集群 ? 一个融合内存缓存技术、Nosql技术、HDFS大数据的新型SQL Server ? 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品 ? 一个新颖的数据库中间件产品。 目标 低成本的将现有的单机数据库和应用平滑迁移到“云”端，解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。 关键特性 支持 SQL 92标准 支持Mysql集群，可以作为Proxy使用

​ ​本文是Spring Cloud专栏的第三篇文章，了解前两篇文章内容有助于更好的理解后面文章： Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览 Spring Cloud第二篇 | 使用并认识Eureka注册中心 ​ 一、Eureka注册中心高可用集群概述 1-1、传统架构 在微服务架构的这种分布式系统中,我们要充分考虑各个微服务组件的高可用性问题,不能有单点故障,由于注册中心Eureka本身也是一个服务,如果它只有一个节点,那么它有可能发生故障,这样我们就不能注册与查询服务了,所以我们需要—个高可用的服务注册中心,这就需要通过注册中心集群来解决。Eureka服务注册中心它本身也是一个服务,它也可以看做是一个提供者,又可以看做是一个消费者,我们之前通过配置eureka.client.register-with-eureka= false让注册中心不注册自己,但是我们可以向其他注册中心注册自己。 Eureka server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己,这样就会形成一组互相注册的服务注册中心,进而实现服务清单的互相同步,往注册中心A上注册的服务,可以被复制同步到注册中心B上,所以从任何一台注册中心上都能查询到已经注册的服务,从而达到高可用的效果。 ​ 二、Eureka注册中心高可用集群搭建

一.心跳介绍 　　网络中的接收和发送数据都是使用操作系统中的 SOCKET 进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。 1.心跳机制： 　　是服务端和客户端定时的发送一个心跳包 ( 自定义的数据结构体 ) ，让对方知道自己还活着，处于在线状态，以确保连接真实有效的一种机制。 2.心跳检查： 　　 心跳检查是查看服务端和客户端是否定时的在正常的发送心跳包。 　　 在 java 的定时线程任务中，我们也可以去实现定时的一些轮询任务，但是 netty 给我们提供了一些自身封装实现好的一些心跳检查机制，我们可以利用 netty 来实现高效的心跳检查机制。 二.netty 提供的心跳 　　netty4.x 中为我们提供了 IdleStateHandler 来检查服务端和客户端的心跳。 IdleStateHandler 类中是这样描述的：triggers an {@link IdleStateEvent} when a {@link Channel} has not performed read, write, or both operation for a while. 解释：在一段时间内，如果有读、写、读写空闲时发生时，会触发这个这个事件 IdleStateHandler会记录IdleStateEvent事件(读空闲、写空闲、读写空闲

为什么会进行心跳检测 简单地说是为了证明客户端和服务器还活着。websocket 在使用过程中，如果遭遇网络问题等，这个时候服务端没有触发 onclose 事件，这样会产生多余的连接，并且服务端会继续发送消息给客户端，造成数据丢失。因此需要一种机制来检测客户端和服务端是否处于正常连接的状态，心跳检测和重连截止就产生了。 如何进行心跳检测和重连 思路是 ： 每隔一段指定的时间（计时器），向服务器发送一个数据，服务器收到数据后再发送给客户端，正常情况下客户端通过 onmessage 事件是能监听到服务器返回的数据的，说明请求正常。 如果再这个指定时间内，客户端没有收到服务器端返回的响应消息，就判定连接断开了，使用 websocket.close 关闭连接。 这个关闭连接的动作可以通过 onclose 事件监听到，因此在 onclose 事件内，我们可以调用 reconnect 事件进行重连操作。 具体代码实现 $(function () { var path = basePath; var jspCode = $("#userId").val(); var websocket; createWebSocket(); /** * websocket启动 */ function createWebSocket() { try { if ('WebSocket' in window) {

在使用 var ws = new WebSocket(url); ws.onclose = function () { //something }; ws.onerror = function () { //something }; ws.onopen = function () { //something }; ws.onmessage = function (event) { //something } 复制代码 微信小程序 websocket过程中，可能会出现网络断开的情况，比如信号不好，或者网络临时性关闭，这时候websocket的连接已经断开， 而浏览器不会执行websocket 的 onclose方法，我们无法知道是否断开连接，也就无法进行重连操作。 如果当前发送websocket数据到后端，一旦请求超时，onclose便会执行，这时候便可进行绑定好的重连操作。 因此websocket心跳重连就应运而生。 如何实现 在websocket实例化的时候，我们会绑定一些事件： var ws = new WebSocket(url); ws.onclose = function () { //something }; ws.onerror = function () { //something }; ws.onopen = function () { //something }

Eureka Client 是一个Java 客户端，用于简化与Eureka Server的交互，客户端同时也具备一个内置的、使用轮询负载算法的负载均衡器。 在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)，如果Eureka Server在多个心跳周期没有收到某个节点的心跳，Eureka Server 将会从服务注册表中把这个服务节点移除(默认90秒)。 Eureka Client具有缓存的机制，即使所有的Eureka Server 都挂掉的话，客户端依然可以利用缓存中的信息消费其它服务的API。下面我们一起来看客户端相关操作。 1.从启动类入手 我们还是和分析 Eureka Server 源码一样，从启动类的 @EnableDiscoveryClient 注解入手看调用流程。 进入 EnableDiscoveryClient 之后，通过注释知道它的作用是为了激活 DiscoveryClient： 首先是在类头使用了 import 注解引入了：EnableDiscoveryClientImportSelector。该类的主要作用是实例化：AutoServiceRegistrationConfiguration。 @Order(Ordered.LOWEST_PRECEDENCE - 100) public class