长连接

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 　　这几天用了下ASyncSocket完成前后台即时通讯，当时有想过用消息推送的技术实现的，可是后来想到消息推送的不可靠性还是算了。于是使用了tcp/ip实现后台主动发送数据给前台的功能。 最开始设计后台的时候，我有考虑到数据量比较大的问题，所以数据大的时候我会使用分包和组包的功能去实现。TCP/IP在传输数据的时候，一般不会大于1500字节，所以我每512字节分了 一个包。然后当一次性数据包接收太多的时候，就出现了粘包的问题。因为我在数据传输的时候使用的是json，每一个分包都是由{}括起来的，所以我就想着在包头上加上一段基本不会重复 的分割字符串，然后服务器接收到分包的时候每次都根据这个字符串分割一下，第一次分割的时候第一行绝对是空字符串 例如：@Hinagiku{“Name”=“桂雏菊”}， 我分割出来结果是： “”，“桂雏菊”，所以说第一行我就可以直接跳过，每次取分包的时候从第二行开始取。然后后台根据包的ID号，序号进行组包。如果当前分包在5分钟内没有接收完毕，就代表当前分包接收失败 了，要求客户端或服务器重新发送。粘包问题解决完毕之后，我开始实现心跳包功能，当时想的是，每隔1分钟发一次心跳包，服务器放一个线程。每隔几秒钟判断一次，当前的所有TCP连接的 最后一次访问时间是多少号

定义： 短连接：例如普通的web请求，在三次握手之后建立连接，发送数据包并得到服务器返回的结果之后，通过客户端和服务端的四次握手进行关闭断开。 长连接：区别于短连接，由于三次握手链接及四次握手断开，在请求频繁的情况下，链接请求和断开请求的开销较大，影响效率。采用长连接方式，执行三次握手链接后，不断开链接，保持客户端和服务端通信，直到服务器超时自动断开链接，或者客户端主动断开链接。 适用场景 ： 短连接：适用于网页浏览等数据刷新频度较低的场景。 长连接：适用于客户端和服务端通信频繁的场景，例如聊天室，实时游戏等。 学习详细地址：http://www.cnblogs.com/cswuyg/p/3653263.html 来源： https://www.cnblogs.com/feiyujinghong/p/6265361.html

在网上查了一下资料，发现轮询和长轮询还有不同的定义： 轮询 ：客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。 优点：后端程序编写比较容易。 缺点：请求中有大半是无用，浪费带宽和服务器资源。 实例：适于小型应用。 长轮询 ：客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。 优点：在无消息的情况下不会频繁的请求。 缺点：服务器hold连接会消耗资源。 实例：WebQQ、Hi网页版、Facebook IM。 另外，对于长连接和socket连接也有区分： 长连接 ：在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。 优点：消息即时到达，不发无用请求。 缺点：服务器维护一个长连接会增加开销。 实例：Gmail聊天 Flash Socket ：在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信，JavaScript在收到服务器端传送的信息后控制页面的显示。 优点：实现真正的即时通信，而不是伪即时。 缺点：客户端必须安装Flash插件；非HTTP协议，无法自动穿越防火墙。

到目前为止，我们已经基本掌握了MQ的相关核心工作原理，同时一起设计了消息路由中心 （ 消息中间件路由中心你会设计吗，不会就来学学 ）和 Broker 主从架构( 消息队列Broker主从架构详细设计方案，这一篇就搞定主从架构 )，现在如果让你基于它的基本原理去设计一套 MQ 的生产部署架构出来，你准备怎么去思考呢？ 在这套架构中，你需要着重考虑的就是高可用问题，也就是说要保证整个系统在运行过程中，其中的任何一个环节宕机都不能影响整个系统。今天我们就来打卡如何设计一套高可用的消息中间件生产部署架构。 NameServer 集群化，保证路由高可用 首先，我们就是需要将NameServer 集群化部署，这里建议可以部署三台机器，这样可以充分的保证我们消息路由中心的可用性，哪怕其中的两台挂了，也还有一台 NameServer 在运行，这样就能保证我们 MQ 系统的稳定性。 前面我们也知道我们的NameServer 设计采用的是Peer-to-Peer 模式，即可以支持集群化部署的，每台机器是独立运行的，他们彼此直接不直接通信。 每台NameServer 机器都拥有所有的路由信息，包括所有的 Broker 节点信息、数据信息等 ，这样只要有一台 NameServer 存活就不会影响系统的稳定性。 所以，消息路由中心 NameServer 的集群化是我们整个MQ生产部署的第一步。

简介 该项目使用c++11，参考muduo实现的静态web服务器。muduo网络库使用线程池+电平触发式epoll+NIO的Reactor模式实现。该项目汲取muduo的优点，并简化设计。采用线程池+边沿触发式epoll+NIO的Reactor模式实现，各个工作线程采用RR方式(Round Robin)来公平分配请求，同时引入了应用层心跳，来处理超时连接。该webserver支持长、短连接，采用被动式关闭，能优雅的断开连接。 该项目参考muduo网络库Tcp骨架，针对Http协议处理过程设计而成。主要引入了HttpServer、HttpConnection和HttpHandler和HttpManager几个类，已应对接受Http请求、解析Http请求、应答Http请求以及管控Http连接的需要。 采用压力测试工具webbench 1.5，实验得出：采用环回地址测试时，在10k长连接状态下，60s能处理1500w+个请求，响应能力为35 M/s。采用局域网地址测试时，在10k长连接状态下，60s能处理750w+个请求，响应能力为1.67 M/s。启动webserver时内存占用为1.8MB；10k长连接下，平均占用15MB内存。 为方便测试，该项目也加入了简易的资源监控脚本、内存泄露检测脚本、一键启动webserver脚本，以及压力测试脚本。 目录结构 ├── code │ ├──

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文详细讲述58同城高性能移动Push推送平台架构演进的三个阶段，并介绍了什么是移动Push推送，为什么需要，原理和方案对比；移动Push推送第一阶段（单平台）架构如何设计；移动Push推送典型性能问题分析解决，以及高可用、高性能、高稳定性如何保证。 什么是移动Push推送 移动Push推送是移动互联网最基础的需求之一，用于满足移动互联环境下消息到达App客户端。以转转（58赶集旗下真实个人的闲置交易平台）为例，当买家下单后，我们通过移动Push推送消息告诉卖家，当卖家已经发货时，我们通过移动Push消息告诉买家，让买卖双方及时掌握二手商品交易的实时订单动态。 为什么需要移动Push推送？ 移动互联网络环境下，经常会出现弱网环境，特别是2G、3G等网络环境下，网络不够稳定，App客户端和相应服务器端的长连接已经断开，消息无法触达App客户端。而我们业务需要把Message（转转App交易消息等）、Operation（转转App运营活动等）、Alert（转转红包未消费提醒等）等消息推送给App客户端，从而触发用户看到这些消息，通过点击这些Push消息达到相应目标。 推送原理和方案对比 移动Push推送主要有以下三种实现方式。 移动App轮询方式（PULL） App客户端定期发起Push消息查询请求

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> spring4 + websocket + echarts 长连接，解决echarts 在使用过程中实时刷新页面的问题（echarts 动态数据 ）； 源码链接部分： http://git.oschina.net/alexgaoyh/MutiModule-parent/tree/master/MutiModule-echarts 详细可看README.md文件： #2015124 创建Echarts与WebSocket的关联关系； echarts在初始化到页面的过程中，客户端（浏览器）直接与服务端创建长连接，后期服务端主动向客户端发送消息，echart页面则开始刷新； Demo: http://127.0.0.1:8080/MutiModule-echarts/init 初始化echart页面，页面中展现一个图标信息 另开一个页面访问 http://127.0.0.1:8080/MutiModule-echarts/send 服务器主动向客户端发送消息，则看到之前init链接对应的页面内容发生了变化； 至此，echarts与WebSocket之间则解决了交互问题，并且可以通过服务端控制客户端页面的展现内容相关； 来源： oschina 链接： https://my.oschina.net/u/859156

问题背景 　　我们这边是一个基于Nginx的API网关（以下标记为A），最近两天有调用方反馈，偶尔会出现502错误，我们从Nginx的error日志里看，就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志，翻译过来其实就是上游服务过早的关闭了连接，意思很清楚，但是为什么会出现这种情况呢。而且是在业务低峰出现这种情况（也只是小概率的出现），在业务高峰的时候没有出现这种情况，而且上游服务方（以下标记为B）说出问题的请求他们那边没有收到，也就是没有任何记录，这就比较诡异了。测试环境不知道如何去复现，也就不好排查。 排查过程 　　1、在服务器上开启tcpdump抓包 tcpdump -nps0 -iany -w /tmp/20180617.pcap net [ip] and net [ip]，如果不知道tcpdump怎么使用的同学可以百度一下。 　　2、在nginx的error.log中观察到到有两条" upstream prematurely closed connection while reading response header from upstream"错误日志，分别是2018/06/07 20:41:27和2018/06/08

上周，我们举办了第二届技术沙龙，我这边主要演讲了消息队列技术的议题，现分享给大家： 在我们团队内部，随着消息应用中心（任务中心）的广泛应用，有时候我们感觉不到消息队列的存在，但这不影响消息队列在高可用、分布式、高并发架构下的核心地位。 消息队列都应用到了哪些实际的应用场景中？ 一、再谈消息队列的应用场景 异步处理：例如短信通知、终端状态推送、App推送、用户注册等 数据同步：业务数据推送同步 重试补偿：记账失败重试 系统解耦：通讯上下行、终端异常监控、分布式事件中心 流量消峰：秒杀场景下的下单处理 发布订阅：HSF的服务状态变化通知、分布式事件中心 高并发缓冲：日志服务、监控上报 但是，我们对消息队列的底层技术和原理还是不了解，那么我们马上开始吧… 二、消息队列的一些基本概念和简单原理 1. Broker Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。 2. 消息的生产者、消费者 消息生产者Producer：发送消息到消息队列。 消息消费者Consumer：从消息队列接收消息。 3. 点对点消息队列模型 消息生产者向一个特定的队列发送消息，消息消费者从该队列中接收消息； 消息的生产者和消费者可以不同时处于运行状态。 每一个成功处理的消息都由消息消费者签收确认（Acknowledge）。如图： 4. 发布订阅消息模型 -Topic

Copy from http://developer.51cto.com/art/201003/189724.htm java.net.SocketException在我们使用的时候会出现很多异常，这些会影响到我们的学习和使用。下面我们就仔细的研究一下。 AD： 2014WOT全球软件技术峰会北京站 课程视频发布 java.net.SocketException如何才能更好的使用呢？这个就需要我们先要了解有关这个语言的相关问题。希望大家有所帮助。那么我们就来看看有关 java .net.SocketException的相关知识。 第1个异常是 java.net.BindException:Address already in use: JVM_Bind。 该异常发生在服务器端进行new ServerSocket(port)（port是一个0，65536的整型值）操作时。异常的原因是以为与port一样的一个端口已经被启动，并进行监听。此时用netstat –an命令，可以看到一个Listending状态的端口。只需要找一个没有被占用的端口就能解决这个问题。 使用Java JDK中Java.net包控制UDP协议 通过Java.net.Socket 类抓取网页内容 通过java.net.Socket类抓取网页内容 通过Java.net包建立双向通讯 用来访问HTTP服务器的仿java