为什么mysql存储数据要用b+tree去做，为什么时序数据库又是用lsm去做索引，为什么es又是用倒排索引，各种索引之间有什么不同？我们又该在什么时候选择什么索引呢？我将一一揭晓这些答案。
??性能优化，服务监控方面的知识往往涉及量广且比较零散，希望将这部分知识整理成册，愿以后性能排查不再抓瞎。
我又和redis超时杠上了 服务监控系列文章 服务监控系列视频 背景 经过上次redis超时排查，并联系云服务商解决之后，redis超时的现象好了一阵子，但是最近又有超时现象报出，但与上次不同的是，这次超时的现象发生在业务高峰期，在简单看过服务器的各项指标以后，发现只有cpu的使用率在高峰期略高，我们是8核cpu，高峰期能达到90%的使用率，其余指标都相对正常。 但究竟是不是cpu占比高的问题导致
(5)500行代码手写docker-实现硬件资源限制cgroups 本系列教程主要是为了弄清楚容器化的原理，纸上得来终觉浅，绝知此事要躬行，理论始终不及动手实践来的深刻，所以这个系列会用go语言实现一个类似docker的容器化功能，最终能够容器化的运行一个进程。 本章的源码已经上传到github，地址如下: https://github.com/HobbyBear/tinydocker/tre
https 实践篇 基于https原理篇，这篇文章将会用openssl 工具以及golang程序来演示下https加解密过程。 依据前文已经知道 声明一个https服务需要为其颁发证书已经它的私钥。 生成服务器私钥 openssl genrsa -out server.key 2048 生成x509证书 openssl req -new -x509 -key server.key -out s
https 原理篇 经典三问，是什么，为什么，怎么做? 是什么 是一种http的安全协议，在tcp ip网络模型里，http应用层是在tcp 传输层之上的，https协议规定了在tcp传输层之上还有一层tls/ssl层，这一层对http应用层发出去和接收的报文做加密和解密。 为什么 出现https原因，在我看来有两点 1，因为http是明文传输，极不安全，需要对报文进行加密。 2，我们无法确认浏
(4)500代码行代码手写docker-设置网络命名空间 本系列教程主要是为了弄清楚容器化的原理，纸上得来终觉浅，绝知此事要躬行，理论始终不及动手实践来的深刻，所以这个系列会用go语言实现一个类似docker的容器化功能，最终能够容器化的运行一个进程。 本章的源码已经上传到github，地址如下: https://github.com/HobbyBear/tinydocker/tree/cha
(3)500行代码代码手写docker-将rootfs设置为只读镜像 本系列教程主要是为了弄清楚容器化的原理，纸上得来终觉浅，绝知此事要躬行，理论始终不及动手实践来的深刻，所以这个系列会用go语言实现一个类似docker的容器化功能，最终能够容器化的运行一个进程。 本章的源码已经上传到github，地址如下: https://github.com/HobbyBear/tinydocker/tr
(2)500行代码手写docker-以新命名空间运行程序 本系列教程主要是为了弄清楚容器化的原理，纸上得来终觉浅，绝知此事要躬行，理论始终不及动手实践来的深刻，所以这个系列会用go语言实现一个类似docker的容器化功能，最终能够容器化的运行一个进程。 本章的源码已经上传到github，地址如下: https://github.com/HobbyBear/tinydocker/tree/cha
(1)500行代码手写docker开篇-goland远程编译环境配置 本系列教程主要是为了弄清楚容器化的原理，纸上得来终觉浅，绝知此事要躬行，理论始终不及动手实践来的深刻，所以这个系列会用go语言实现一个类似docker的容器化功能，最终能够容器化的运行一个进程。 代码最终运行效果 本系列源码已经上传到githuhub，地址如下: https://github.com/HobbyBear/t
一次排查某某云上的redis读超时经历 问题背景 最近一两天线上老是偶现的redis读超时报警，并且是业务低峰期间，甚是不解，于是开始着手排查。 以下是我的排查思路。 排查思路 查阅 redis 慢查询日志 既然是redis超时，首先想到的还是 对于redis的操作命令存在慢查询导致的。 redis的慢查询阈值是10ms,唯一的慢查询是备份时的bgrewriteaof语句，并不是业务命令，既然从
一次系统延迟性优化案例问题背景线上隔三差五晚上10点左右总会有sql报警出现，且是同样的sql，我们的sql报警是在应用程序内部通过对sql操作增加钩子函数，对sql前后执行的位置记录下时间戳，然后sql执行完毕后，对时间戳进行相减得到sql执行时长，大于1s则报警。晚上10点正好是我们的业务高峰。部分接口也会在此期间出现超过2s的响应。探索过程排查sql慢查询由于是执行sql的地方出现报警，所以
mysql invalid conn排查问题背景我们的服务端程序是使用golang进行开发 ，mysql的客户端库是go-mysql-driver ,系统测试环境频繁总时不时报出invalid conn 错误，但实际拿sql执行时却是正常执行。排查思路原因分析客户端使用了无效连接由于报错信息是invalid conn 连接无效的提示，首先考虑了客户端使用了过期连接。mysql服务器端和客户端都能配
一次goroutine 泄漏排查案例背景这是一个比较经典的golang协程泄漏案例。背景是这样，今天看到监控大盘数据发现协程的数量监控很奇怪。呈现上升趋势，然后骤降。虽然对协程数量做了报警机制，但是协程数量还是没有达到报警阈值，所以没有报警产生。不过有经验的开发应该应该能一眼看出，这个肯定是协程泄漏了，因为协程数量一直在上涨，没有下降趋势，，中间下降的曲线其实是服务器重启造成的。pprof分析为了
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
