Skip to main content

December 2018

Druid的存活检测问题

Submitted by taotao on Sun, 12/30/2018 - 10:52

概述

在Druid数据库连接池中有两个参数,分别为: testWhileIdle,timeBetweenEvictionRunsMillis 根据字面意思理解是连接池会定时的对处于idle状态的连接进行一次存活检测, 目的是为了防止返回一个已经关闭的JDBC的连接给应用使用。 但是在本地验证该参数的行为的时后,发现并不是如上的期望。 如果配置了该参数,Druid会在每一次应用获取连接的时后,进行一次存活检测, 如果发现连接不可用,那么就从connection pool中重新获取一个connection返回给应用。 如下是本地的验证的一个过程。

验证过程

在本地启动Java应用,应用直连数据库,配置Druid每间隔30秒进行一次链接检测, 配置数据库的max_timeout为60秒,validationQuery为SELECT 1,如下:

kingshard的连接问题调查(二)

Submitted by taotao on Wed, 12/26/2018 - 12:35

继续之前的分析 kingshard的连接问题调查(一) 中的推测,是由于JDBC的connection pool中的链接失效导致发生如下错误

communications link failure the last packet sent successfully to the server was 0 milliseconds ago

为了验证这个推测,在本地模拟了一个测试场景,具体如下:

  • 将Mysql Server的超时时间调整为30秒
  • 将应用中JDBC连接池(Druid)连接最大闲置检查时间间隔设置为60秒
  • 应用启动后,等待30秒之后再去访问一个有数据库查询的Http接口

当过了30秒之后,Mysql服务端就有如下的日志信息:

ApacheHttpClient的连接池引起Jetty工作线程被耗尽后的TCP的连接状态分析

Submitted by taotao on Tue, 12/25/2018 - 19:10

文章ApacheHttpClient的连接池引起Jetty工作线程被耗尽 中提到的,

如果应用中没有对如下代码中:

HttpResponse response = httpClient.execute(httpHost, httpPost);

response 对象执行如下方法,释放链接:

EntityUtils.consumeQuietly(response.getEntity());

就会导致connection不能回归到connection pool中。

今天对这些不能回归的connection从系统层面进行分析,

看看是处于什么状态。

模拟多次接口调用后,Jetty的工作线程都阻塞在 connectionPool中的get方法调用上:

关于我

Submitted by taotao on Sun, 12/23/2018 - 17:06

关于我

大家好,我是王震华,从事IT行业有12年的历史,这个博客主要记录我工作、生活中的 所思所想,有些观点可能不正确,甚至有些偏激,所以请读者独立思考,去伪存真。

联系方式

邮件地址: weiyan.2017@yandex.com

将基于Spring-Boot开发工程调整成多Maven-Module的实战总结

Submitted by taotao on Sun, 12/23/2018 - 08:47

概述

在基于Spring Boot开发的项目中,为了便于后期的维护, 需要将项目按照模块进行划分,先将项目按照业务逻辑模块进行划分, 然后根据划分的业务模块再基于Maven的Module形式组织工程。

下面主要记录我将UC项目中单Module的Spring Boot工程,调整成多Module的形式的过程, 以及碰到的问题和解决过程。

调整过程

将项目按照如下三个大的module进行划分: API/Core/Web, 其中API定义所有的模块的行为但是不定义如何实现的,Core是基于API中接口的具体实现, Web是提供Http接口服务模块。基于这个边界的定义,自然我们就有如下的上下关系:

    web
     ^
     |
     |
    core
     ^
     |
     |
    api

API模块举例说明,比如我们在该模块中,有一个子模块为api-authentication, 该模块主要定义了和用户认证逻辑的所有业务接口,比如:

kingshard的连接问题调查(一)

Submitted by taotao on Sat, 12/22/2018 - 10:05

cat-head

kingshard是一个基于mysql读写分离的中间件,公司目前按照目前的体量和发展速度, 急需要一个能够支持读写分离的中间件支撑业务的发展需要,在各种背景下,我们目前选择了 kingshard作为首先验证的一个中间件。 为了验证kingshard的稳定性,先在内网的环境部署kingshard服务, 然后让项目使用kingshard进行验证,内网的开发环境、测试环境都是使用频次比较高的环境,打算在这两个环境中验证1-2个星期看稳定性如何。在这个过程中频繁出现如下的 错误:

ApacheHttpClient的连接池引起Jetty工作线程被耗尽

Submitted by taotao on Fri, 12/21/2018 - 20:28

tomjerry

概述

12月20日下午2点到4点左右,商城商品的商品评论不能被加载出来,当时生产环境有3个商品服务的实例,根据日志报错信息来看,有大量的超时

报错信息,超时是由于调用用户中心的服务接口导致的,再排查用户中心的服务的状态,发现用户中心的3个服务的网络流量比平时都大了10倍,

为了尽快恢复服务,将用户中心的服务再平行扩展出一个节点,然后再将商品评论的3个服务中的两个重启,保留一个服务作为问题调查的现场。然后线上

TCP/IP学习日志五-IP包

Submitted by taotao on Wed, 12/19/2018 - 12:48

寄送快递的过程

圣诞节快到了,小王要快递寄送一个礼物给他的女朋友小于, 他先在商品精心挑选了一个礼物后,然后又用彩纸将礼物 精心包裹起来。然后再打电话给快递员小张上门收快递, 小张收到要寄送的物品后,又用快递专用的盒子将小王的 礼物包裹起来,最后在包裹外面贴上快递单,包含如下信息:

目的地址
发送地址
发件人
收件人
发件人联系电话
收件人联系电话

到此为止,发送的环节都已经结束了。

收快递的过程

快递公司收到快递后经过内部的分包和合包转运过程, 将礼物送到了小于的手上。小于先将快递公司的包装解拆掉, 再将小王的彩纸包装拆掉,然后就看到了小王送的圣诞礼物。

关联

寄送快递时的步骤是封包过程,收取快递是一个解包过程, 这是现实生活中的一个例子。而我们的IP包也有一个同样的过程, 数据发送方先将原始数据组织好,然后通过TCP/IP 协议在每一层 进行封包,经过分组协议交换传输后,到达应用接受方,接受方 再一层层的解包,最后取到原始信息

Tags

TCP/IP学习日志四-分层设计

Submitted by taotao on Mon, 12/17/2018 - 21:48

layer-design

什么是分层

在一个组织中,我们经常会看到有小组长、 项目经理、总监这些角色,每个角色的管理范围都不一样, 小组长管理自己手下的几个人,项目经理管理手下几个组长,总监负责管理手下的几个PM, 这种组织架构就是分层的概念的体现。

为什么要分层设计

分层设计的好处是,每个人都有一个明确的汇报对象, 总监只需要问责几个PM就可以把所有的事情梳理清楚, 而无需过问到每一个具体一线员工。 试想如果不是这样的汇报机制, 我们假设有10个事情是总监在推进的, 这10个事情需要10个开发人员负责实施, 其中每个事情都有交叉协作的地方, 如果没有PM、小组长这两层,总监需要关注很多人和事, 精力就会分散在各个事情的细节上, 注意力都纠结在局部事情上, 无暇从全局考虑事情,所以最后也可能不会有一个好整体结果,所以进行分层的汇报机制设计是很有必要的事情。

Tags