keepalive

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我用512M的vps，访问量不大，但内存占用很大，甚至宕机。 我用top，然后shitf+m发现，httpd占用内存极大。经过网上找资料设置后，用过一段时间终于没再出现内存问题了。 首先查找配置文件的位置，可以用如下命令： find / -name httpd.conf 找到配置文件/usr/local/apache/conf/extra/httpd-mpm.conf，修改设置Apache MPM Prefork模块 StartServers 3 MinSpareServers 2 MaxSpareServers 5 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 40 我原来的MaxRequestsPerChild是为0，问题应该在此。 StartServers设置了服务器启动时建立的子进程数量 MinSpareservers和MaxSpareServers分别设置空闲子进程的最小和最大数量 ServerLimit则是控制MaxClients所能使用的最大值。缩减MaxClients能让运行动态内容（比如：WordPress）的服务器有很大的改变。如果你的VPS遭遇到流量的大幅增加，而你的MaxClients设置的太高的话

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1) MPM（多处理模块）配置（主要负责管理网络连接，调度请求） Apache有3个MPM，分别是: event , prefork和worker。 event这个MPM是在Apache2.4后才有稳定版,比较适用于大量连续连接的情况。event为不同的任务使用单独的线程池. KeepAlive的好处是,可以同一个tcp连接中响应多个请求,这种方式，可以使一个包含大量图片和html文档的请求加速50％,在Apache配置文件httpd.conf中设置KeepAlive设置为On. prefork是一个非线程的MPM。它的特点:不快但很稳定.它能够隔离每个请求，所以如果某个请求出现故障，不会影响其他请求.使用prefork最重要的一个参数是MaxClients。这个MaxClients足够大，这样可以在访问高峰时发挥很好的性能,但是同时又不能太大，致使Apache所需内存超过物理内存。 worker这个MPM，速度比prefork快很多,由于使用多线程进行访问处理，所以能够处理相对海量的请求，而系统资源的占用要小于基于进程的服务器.work有2个比较重要的参数:ThreadPerChild和MaxClients.ThreadPerChild是用来控制每个子进程允许建立的线程数

理解Keepalive(1) 大家都听过keepalive，但是其实对于keepalive这个词还是很晦涩的，至少我一直都只知道一个大概，直到之前排查线上一些问题，发现keepalive还是有很多玄机的。其实keepalive有两种，一种是TCP层的keepalive，另一种是HTTP层的Keep-Alive。这篇文章先说说tcp层的keepalive tcp keepalive 设想有一种场景：A和B两边通过三次握手建立好TCP连接，然后突然间B就宕机了，之后时间内B再也没有起来。如果B宕机后A和B一直没有数据通信的需求，A就永远都发现不了B已经挂了，那么A的内核里还维护着一份关于A&B之间TCP连接的信息，浪费系统资源。于是在TCP层面引入了keepalive的机制，A会定期给B发空的数据包，通俗讲就是心跳包，一旦发现到B的网络不通就关闭连接。这一点在LVS内尤为明显，因为LVS维护着两边大量的连接状态信息，一旦超时就需要释放连接。 Linux内核对于tcp keepalive的调整主要有以下三个参数 1. tcp_keepalive_time the interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe;

前景： 在日常使用的时候，我们经常需要返回上一级页面的时候，不刷新页面，保持页面不变，这里就需要使用以下方法： 思路： 因为vue是单页面应用，进入其他页面时会销毁该页面，用keep-alive不让其刷新，具体实现为： (1).在App.vue中加入：这里是所有页面切换到地方，下面代码分别对不同的设置，采用不同的渲染方式。 < template > < div id = "app" > < ! -- < router - view / > -- > < ! -- 页面返回不刷新 -- > < keep - alive > < router - view v - if = "$route.meta.keepAlive" > < / router - view > < / keep - alive > < router - view v - if = "!$route.meta.keepAlive" > < / router - view > < / div > < / template > (2).index.js页面 在需要设置不刷新的页面中，只需要添加 keepAlive: true就可以。 export default new Router ( { routes : [ { path : '/' , name : 'index' , component : index ,

HTTP上的一些API及应用 HTTP模块上的服务（server）与响应(response) HTTP模块上的消息（message） HTTP模块上的代理（agent）与请求（request） HTTP模块的简单实践 一、HTTP上的一些API及应用 http.Agent：http请求代理，用来管理客户端连接的持久性和重用。 http.ClientRequest：由http.request()产生，用来管理已被放入请求队列中的请求，比如可以通过setHeader(name, value)向请求头添加请求头。 http.Server：该类继承net.server，用来管理来自客户端的http请求。 http.ServerResponse：此类型的对象由 HTTP 服务器在内部创建，而不是由用户创建，用来管理服务端接收到http请求后响应客户端的相关内容。 它作为第二个参数传给 'request' 事件。 http.IncomingMessage：此类型的对象由 http.Server 或 http.ClientRequest 创建，并分别作为第一个参数传给 'request' 和 'response' 事件，用来表示接收到的http请求的模型。 它可用于访问响应状态、消息头、以及数据。 http.METHODS：该属性用来获取当前node环境下支持的http请求方法，比如：[GET,

由于业务开发需要，需要对数据库代理进行研究，在研究 MySQL Proxy 实现原理的过程中，对一些功能点进行了分析总结。本文主要讲解下 MySQL Proxy 的 daemon 和 keepalive 功能实现原理。 MySQL Proxy 是数据库代理实现中的一种，提供了 MySQL server 与 MySQL client 之间的通信功能。由于 MySQL Proxy 使用的是 MySQL 网络协议，故其可以在不做任何修改的情况下，配合任何符合该协议的且与 MySQL 兼容的客户端一起使用。 在最基本的配置下，MySQL Proxy 仅仅是简单地将自身置于服务器和客户端之间，负责将 query 从客户端传递到服务器，再将来自服务器的应答返回给相应的客户端。在高级配置下，MySQL Proxy 可以用来监视和改变客户端和服务器之间的通信。查询注入(query interception) 功能允许你按需要添加性能分析命令 (profiling) ，且可以通过 Lua 脚本语言对注入的命令进行脚本化控制。 本文不讨论 MySQL Proxy 作为数据库代理在功能上和实践中的优劣，而是着重讲述其源码实现中的两个功能点：daemon 功能和 keepalive 功能。 通过命令行启动 MySQL Proxy 时经常会用到如下两个配置项： --daemon 和 –keepalive

mysql router使用配置 参考资料： https://www.jianshu.com/p/7fc8d77bea59 一、架构图 介绍： MySQL Router是处于应用client和dbserver之间的轻量级代理程序，它能检测，分析和转发查询到后端数据库实例，并把结果返回给client。是mysql-proxy的一个替代品。 Router实现读写分离，程序不是直接连接数据库IP，而是固定连接到mysql router。MySQL Router对前端应用是透明的。应用程序把MySQL Router当作是普通的mysql实例，把查询发给MySQL Router,而MySQL Router会把查询结果返回给前端的应用程序。 从数据库服务器故障，业务可以正常运行。由MySQL Router来进行自动下线不可用服务器。程序配置不需要任何修改。 主数据库故障，由MySQL Router来决定主从自动切换，业务可以正常访问。程序配置不需要做任何修改。 二、读写分离原理 MySQL Router接受前端应用程序请求后，根据不同的端口来区分读写，把连接读写端口的所有查询发往主库，把连接只读端口的select查询以轮询方式发往多个从库，从而实现读写分离的目的。读写返回的结果会交给MySQL Router,由MySQL Router返回给客户端的应用程序。 三、实验环境 编号 主机名 IP

UPSTREAM 语法: upstream name { ... } 默认值: — 上下文: http Defines a group of servers. Servers can listen on different ports. In addition, servers listening on TCP and UNIX-domain sockets can be mixed. 定义一组服务器。 这些服务器可以监听不同的端口。 而且，监听TCP和UNIX域套接字的服务器可以混用。 Example: upstream backend { server backend1.example.com weight=5; server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com backup; } By default, requests are distributed between the servers using a weighted round-robin balancing method. In the above example, each 7 requests will be distributed as

TCP协议:传输控制协议。 一、TCP保证可靠性的机制 1、校验和 TCP报头有16位检验和: 由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分. 2、序列号(按序到达) 序列号：TCP将每个字节的数据都进行了编号, 即为序列号。 3、确认应答 每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据，下一次你要从哪里开始发. 比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据，1003, 1004, 1005都没收到.此时客户端就会从1003开始重发. 4、超时重传 两种场景： (a)客户端发给服务端时失败:客户端在一个特定时间间隔内没有收到服务端发来的确认应答, 就会进行重发; (b)服务端返回客户端确认失败：服务端可能会收到很多重复数据，通过序列号区分重复数据并且把重复的丢弃; 5、连接管理 5.1 建立连接-三次握手： 三次握手状态变化： 客户端发送SYN包给服务器，客户端进入SYN-SEND状态：CLOSED-->SYN-SEND； 服务器收到SYN包后将建立连接的SYN包和应答包一起发送给客户端，并且进入SYN-RCVD状态：LISTEN-->SYN-RCVD；

低读低写并发、低数据量方案 方案一：双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库，另一台B作为备份库；A库故障后B库作为读写库；A库恢复后A作为备库。 3.开发说明 此种情况下，数据源配置中的数据库IP地址，可采用虚拟的IP地址。虚拟IP地址由两台数据库机器上的keepalive配置，并互相检测心跳。当其中一台故障后，虚拟IP地址会自动漂移到另外一台正常的库上。 数据库的主备配置、故障排除和数据补全，需要DBA和运维人员来维护。而程序代码或配置并不需要修改。 具体配置可参考资料： http://lizhenliang.blog.51cto.com/7876557/1362313 http://database.51cto.com/art/201012/237204.htm http://gaoke.iteye.com/blog/2283890 4.适应场景 读和写都不高的场景（单表数据低于500万），双机高可用。 5.优缺点 优点是一个机器故障了可以自动切换；缺点是只有一个库在工作，读写并未分离，并发有限制。 方案二：主从结构方案 1.数据库架构图 2.特点 一台机器A作为写库，另一台B作为读库；A库故障后B库充当读写，A修复后，B库为写库，A库为读库。 3.开发说明 这种方案的实现，要借助数据库中间件Mycat来实现，Mycat的datahost配置如下