大家好 我是贺同学。
前段时间在工作业务中碰到一个技术问题 在发现问题 思考问题 解决问题的过程中 突然对底层原理有了一些思考 这里分享一下给大家。
在业务中使用到了 Redis 数据库来存储数据 但是在存储大数据量的 string 的时候 监控却发现内存增长异常。
string 类型 作为 Redis 中唯一的“键-单值”类型 操作简单 易于理解 按道理只是存一下字符型的数据 怎么会这么消耗内存 这是怎么回事呢
怀着刨根问底的精神 我自己在我的 Mac 机器上动手实战了一番 写了一段 Python 代码 准备数据长度 7 位数 共 100 万条数据 开始跑数据。
结果发现 使用 string 占用 70 MB 使用 hash ziplist 只占用 9 MB 效果非常明显。
测试结果
begin write 100w before: used_memory_human:1.87M before: used_memory_human:70.90M end write 100w, using: 72380608
这数据效果 没有对比就没有差距。
百思不得其解之际 上网搜了搜别人的回答 看了一些但感觉一直没有说到点子上 直到今天在极客时间的专栏上 学习了 Redis 的 string 底层源码。
Redis 的 string 类型和 hash ziplist 的底层数据结构不同导致了存储大小的差异 我才发现 原来是这么回事
这下我直呼好家伙。
string 类型 常常被当作 Redis 中的万金油 但是它有一个明显的短板 就是它保存数据时所消耗的内存空间最多。
对于不了解 Redis 底层原理的人 很容易误以为最简单的类型 理应消耗最少的资源。但实际情况不是这样的。
Redis string 底层结构 使用了额外的数据结构来保存数据 从而造成了额外的开销 类似这样
这让我想起了之前的一个业务问题 一个老服务修改了一个功能上线了之后 测试同学反映 压测耗时直线飙升。
大家都觉得很奇怪 这个老服务的耗时一直都很稳定 而且 这次修改也只是正常的业务逻辑 大家又百思不得其解 花了一天的时间排查摸底。
最后我们发现 罪魁祸首居然是线上日志数据太满了 导致机器内存瞬间上升 直接影响到了压测耗时的统计。
后来 我发现 当时这个服务编译的有个选项 开启 log debug 模式 如果当时能提前了解这个的背后原理 估计就可能避免这个坑了。
内心的疑问互联网行业 更新迭代非常快 今天学了这个 明天可能又要学那个 在不断持续学习的过程中 相信你心里有时会反问自己 底层原理有那么重要吗 会用不就行了吗
这个时候 可能会有另一个声音在你耳边响起 万丈高楼平地起 计算机基础知识就像程序员金字塔的地基 理解了计算机系统的底层原理 在写程序的道路上才能越走越远啊。
话是这么说没错 但这真的够吗
更深处的原因在于
经常用一些不知其所以然的技术 我会感到不安
在这个数据爆炸的年代 很多系统对于项目性能的优化有很高的要求。那么如何调优成为了程序员不可避免的问题
再就是如果你对计算机系统的底层原理不太了解 可能你平时写的程序都是错误的。
比如我们一直以为两个正数的和或者积一定为正 但是用二进制补码表示的正数和或者积却不一定
程序员和编译器不能用 x-y 0 来代替 x y ,因为前者会产生溢出等等。
更进一步 互联网大厂面试 上来就问底层源码、JVM 的结构、TCP/IP 的三次握手、四次挥手 微信/拼多多用户的数据怎么满足高并发 等等。
像这些问题 如果我们不懂计算机底层知识肯定是不能过关的。
底层原理为何那么重要开篇的例子引入 其实是想说 底层原理的学习非常重要 就好比数据结构和算法是程序员的内功一样。
最近下班在学习极客时间专栏《MySQL实战 45讲》 作者林晓斌老师分享了这段话 我觉得写得非常棒 在这里分享给大家。
我在带新人的时候 要求大家在写 SQL 语句的时候 心里是有数的 知道每个语句执行的结果 以及这些代码会消耗什么资源、如果慢了会慢在哪里、每个语句执行会占用哪些锁等等。
