背景 最近有个业务场景需要服务端(简称S)与客户端(简称C)设计一套基于UDP的通信协议--要求尽可能快的前提下可容忍一定丢包率，得以比较深入地学习和了解UDP通信和实践，在开发调试期间先后碰到了C端UDP发包无响应、响应Host Unreachable、响应Port Unreachable、再次C
背景 作为程序员，应该都听说过NAT(Network Address Transfer，网络地址转换)这一技术名词，并或多或少大概知道其原理与作用--NAT是用于解决IPv4地址不够用，保证我们能够在IPv6普及前依然可以正常使用互联网而广泛使用的一个技术，其原理正如其名称所示：其可以将私网IP通过
背景 最近接触docker的网络配置方式，发现其默认会创建一个docker0的Linux Bridge，宿主机上运行的容器可以通过连接该birdge实现与外网的通信，根据bridge这个命名很自然的认为这就是一个传统意义上的硬件网桥的软件实现，然而进一步探究后发现并非如此，Linux Bridge其
背景 一个安静的晚上，突然接到小伙伴电话线上CDN回源异常，具体表现为请求量飙升，且伴有少量请求404，其中回源请求量飙升已经持续两天但一直未被发现，直到最近404请求触发了告警后分析log才同时发现回源量飙升这一问题。 触发问题的原因很快被发现并修复上线，这里分享一下跟进过程中进一步学习到的CDN
背景 nginx 499在服务端推送流量高峰期长期以来都是存在的，间或还能达到告警阈值触发一小波告警，但主观上一直认为499是客户端主动断开，可能和推送高峰期的用户打开推送后很快杀死app有关，没有进一步探究问题根源。 然而近期在非高峰期也存在499超过告警阈值的偶发情况，多的时候一天几次，少的时候
## 背景 最近一组业务redis数据不断增长需要扩容内存，而扩容内存则需要重启云主机，在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障，这里记录分享一下。 ## 业务redis高可用架构 该组业务redis使用的是一主一从，通过sentinel集群实现故障时的自动主
## 背景 线上启用memcached(以下简称mc)作为热点缓存组件已经多年，其稳定性和性能都经历住了考验，这里记录一下踩过的几个坑。 ## 大key存储 某年某月某日，观察mysql的读库CPU占比有些异常偏高，去check慢查询log，发现部分应有缓存的慢sql居然存在几秒执行一次情况，不符合
## 背景 最近有一个业务场景需要用Python自行实现一个简单的LRU cache，不可避免的接触到了弱引用这一概念，这里记录一下。 ## 强引用 Python内存回收由垃圾回收器自动管理，当一个对象的引用计数归0时，其内存就可能被回收掉，而引用计数器的数值其实就是代表有多少个强引用指向该对象，我
## 背景 近期一个大版本上线后，Python编写的api主服务使用内存有较明显上升，服务重启后数小时就会触发机器的90%内存占用告警，分析后发现了本地cache不当使用导致的一个内存泄露问题，这里记录一下分析过程。 ## 问题分析 ### LocalCache实现分析 该cache大概实现代码如下
背景： 环境未配置DG Broker，手工切换ADG，19c也要比11g时代的切换更简单。 使用自己的测试环境，具体可参见： 单实例Primary快速搭建Standby RAC参考手册(19.16 ADG) 1.主库demo切换到RAC环境demorac： 在主库demo执行命令： SQL> alt
# 背景 线上跑了多年的一个网关业务，随着部门的拆分，逐渐有了一个痛点。该网关业务主要处理app端请求，app端发起的请求，采用http协议，post方法，content-type采用`application/x-www-form-urlencoded`，表单中有一个固定的字段，叫功能号，即func
# 背景 这篇文章是写给有缘人的，为什么这么说呢，因为本篇主要讲讲数据库连接池之c3p0-0.9.1.2版本。 年轻的朋友，可能没怎么听过c3p0了，或者也仅限于听说，这都很正常，因为c3p0算是200几年时比较流行的技术，后来，作者消失了好几年，12年重新开始维护，这时候已经出现了很多第二代线程池
# 背景 本篇是c3p0连接泄露问题的第二篇，在前面一篇里面，大体介绍了问题，问题就是，我们发现线上服务不响应的原因是拿不到连接。而为啥拿不到连接呢，因为空闲链表为空，那么为什么空闲链表为空呢？ 这个我一开始的猜测就是，估计是某处代码从连接池里获取了连接，用完了没有归还，那么，怎么才能找到这些罪恶的
# 背景 怎么会讲这个话题，这个说来真的长了。但是，长话短说，也是可以的。 我前面的文章提到，线上的服务用了c3p0数据库连接池，会偶发连接泄露问题，而分析到最后，又怀疑是db侧主动关闭连接，或者是服务所在机器和db之间有防火墙，防火墙主动关闭了连接。导致我们这边socket看着还健康，实际在对端已
# 背景 我前面写了几篇文章，讲c3p0数据库连接池发生了连接泄露，但是随机出现，难以确定根因，最终呢，为了快速解决问题，我是先写了个shell脚本，脚本主要是检测服务的接口访问日志，看看过去的30s内是不是接口几乎都超时了，如果是的话，咱们就重启服务。然后把这个shell加入到了crontab里，
# 背景 测试环境有一个后台服务，部署在内网服务器A上（无外网地址），给app提供接口。app访问这个后台服务时，ip地址是公网地址，那这个请求是如何到达我们的内网服务器A呢，这块我咨询了网络同事，我画了简图如下： ，就是说这个事的。在文章里，最终查到是nginx的全连接队列满了（每个监听端口有个队列，完成三
