# nginx在代理到upstream时的默认行为 最近准备用openresty替换nginx，替换的效果当然是需要保证效果和nginx一致，不然可能就会导致线上在用的服务出现问题。 替换成openresty后，在本地进行了一个请求，header如下： ```http POST /servlet/j
# 背景 线上跑了多年的一个网关业务，随着部门的拆分，逐渐有了一个痛点。该网关业务主要处理app端请求，app端发起的请求，采用http协议，post方法，content-type采用`application/x-www-form-urlencoded`，表单中有一个固定的字段，叫功能号，即func
# 背景 这篇文章是写给有缘人的，为什么这么说呢，因为本篇主要讲讲数据库连接池之c3p0-0.9.1.2版本。 年轻的朋友，可能没怎么听过c3p0了，或者也仅限于听说，这都很正常，因为c3p0算是200几年时比较流行的技术，后来，作者消失了好几年，12年重新开始维护，这时候已经出现了很多第二代线程池
# 背景 本篇是c3p0连接泄露问题的第二篇，在前面一篇里面，大体介绍了问题，问题就是，我们发现线上服务不响应的原因是拿不到连接。而为啥拿不到连接呢，因为空闲链表为空，那么为什么空闲链表为空呢？ 这个我一开始的猜测就是，估计是某处代码从连接池里获取了连接，用完了没有归还，那么，怎么才能找到这些罪恶的
# 前言 本篇其实是承接前面两篇的，都是讲定位线上的c3p0数据库连接池，发生连接泄露的问题。 第二篇讲到，可以配置两个参数，来找出是哪里的代码借了连接后没有归还。但是，在我这边的情况是，对于没有归还的连接，借用者的堆栈确实是打印到日志了，但是我在本地模拟的时候，发现其实这些场景是有归还连接的，所以
# 背景 怎么会讲这个话题，这个说来真的长了。但是，长话短说，也是可以的。 我前面的文章提到，线上的服务用了c3p0数据库连接池，会偶发连接泄露问题，而分析到最后，又怀疑是db侧主动关闭连接，或者是服务所在机器和db之间有防火墙，防火墙主动关闭了连接。导致我们这边socket看着还健康，实际在对端已
# 简介 iptables的文章多如牛毛，但是，我读了一些，发现虽然成体系，但是不便理解，今天就结合自己的理解，好好讲解下，另外，我们也会使用iptables来实验一个nat地址转换的demo，nat转换，通俗地讲，一般是为了解决ipv4公网地址不够用的问题，因此在学校、公司等机构的有公网ip的服务
# 前言 超时，应该是程序员很不爱处理的一种状态。当我们调用某服务、某个中间件、db时，希望对方能快速回复，正确就正常，错误就错误，而不是一直不回复。目前在后端领域来说，如java领域，调用服务时以同步阻塞调用为主，此时一般会阻塞当前线程，等待结果。如果我们设置了超时时间还好，一段时间等不到就报错了
# 背景 我前面写了几篇文章，讲c3p0数据库连接池发生了连接泄露，但是随机出现，难以确定根因，最终呢，为了快速解决问题，我是先写了个shell脚本，脚本主要是检测服务的接口访问日志，看看过去的30s内是不是接口几乎都超时了，如果是的话，咱们就重启服务。然后把这个shell加入到了crontab里，
# 前言 本周协助测试同事对一套测试环境进行扩容，我们扩容很原始，就是新申请一台机器，直接把jdk、resin容器（一款servlet容器）、容器中web应用所在的目录，全拷贝到新机器上，servlet容器和其中的应用启动没问题。以为ok了，等到测试时，web应用报错，初始化某个类出错。报错的类长下
# 背景 测试环境有一个后台服务，部署在内网服务器A上（无外网地址），给app提供接口。app访问这个后台服务时，ip地址是公网地址，那这个请求是如何到达我们的内网服务器A呢，这块我咨询了网络同事，我画了简图如下： ，就是说这个事的。在文章里，最终查到是nginx的全连接队列满了（每个监听端口有个队列，完成三
# 背景 现在信创是搞得如火如荼，在这个浪潮下，数据库也是从之前熟悉的Mysql换到了某国产数据库。 该数据库我倒是想吐槽吐槽，它是基于Postgre 9.x的基础上改的，至于改了啥，我也没去详细了解，当初的数据库POC测试和后续的选型没太参与，但对于我一个开发人员的角度来说，它给我带来的不便主要是
# 背景 公司之前部门拆分，但一些服务并没有拆分清楚。其中一个老服务，两个部门都在用，现在为了避免互相影响，决定克隆该服务。克隆就要克隆全套，当然也包括数据库，我们这个老服务，用的oracle，所以，就涉及到从旧的oracle中导出数据，然后再导入到另一套新的oracle实例中。 届时在线上肯定是要
版本1的抓包命令 这两天排查一个小问题，需要在服务器上使用tcpdump24小时不间断抓包，这里简单记录下。 先看下tcpdump的语法： tcpdump [ -AbdDefhHIJKlLnNOpqStuUvxX# ] [ -B buffer_size ] [ -c count ] [ -C fil
背景 为什么讲这么小的一个问题呢？因为今天在进行系统上线的时候遇到了这个问题。 这次的上线动作还是比较大的，由于组织架构拆分，某个接入层服务需要在两个部门各自独立部署，以避免频繁的跨部门沟通，提升该接入层服务的变更效率。 该接入层服务之前是使用cookie + 内存session机制的，这次要独立部
背景 这个事情也是最近做的，因为线上nginx被我换成了openresty，然后接入层服务也做了较大改动，虽然我们这个app（内部办公类）并发不算高，但好歹还是压测一下，上线时心里也稳一点。 于是用jmeter简单压测下看看，这里记录一下。 这次也就找了几个接口来压：登录接口、登录后获取用户信息接口
