大家好，我是贺同学。

前段时间在工作业务中碰到一个技术问题， 在发现问题，思考问题，解决问题的过程中，突然对底层原理有了一些思考，这里分享一下给大家。

背景

在业务中使用到了 redis 数据库来存储数据，但是在存储大数据量的 string 的时候，监控却发现内存增长异常。

string 类型，作为 Redis 中唯一的“键-单值”类型，操作简单，易于理解，按道理只是存一下字符型的数据，怎么会这么消耗内存，这是怎么回事呢F1f;

怀着刨根问底的精神，我自己在我的 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 语句的时候，心里是有数的，知道每个语句执行的结果，以及这些代码会消耗什么资源、如果慢了会慢在哪里、每个语句执行会占用哪些锁等等。

有的新人会问“为什么需要这么麻烦，我执行一下，看看结果对不对，对了就行，不对就改，是不是也可以？”我说不可以。因为如果这样，我们就会受到很多局限，即使我们定位自己是业务开发人员。

这里我说一个限制：

这会限制基于数据库的业务架构能力。一个语句可以试，一个五个语句的事务分析就要试很多次，一个复杂业务系统的数据库设计，是试不出来的。

原理可以帮我们剪枝，排除掉那些理论上明显错误的方案，这样才有精力真的去试那些有限的、可能正确的方案。

我们不需要 100% 精通 MySQL (我自己离这个目标也相去甚远），但是只要多知道一些原理，就能多剪一些枝，架构设计就能少一些错误选项的干扰，设计出来的项目架构正确的可能性更高。

我自己特别喜欢这个剪枝的过程和感觉，他表示我用以前学习的时间，来节省了现在工作的时间。

当然，“原理”是一个很大的概念，有的原理更接近实战，有的远一些。这个专栏我挑的是跟平时使用相关的原理，以便大家可以有机会边学边用。

一起加油吧🤝

除了需要不断去探究底层原理，作为互联网技术从业者，我们还需要树立正确的计算机世界观：

这里分享浙大翁凯老师的一个原则：

学计算机一定要有一个非常强大的心理状态，计算机的所有东西都是人做出来的，别人能想的出来，我也一定能想得出来，在计算机的世界里没有任何的黑魔法，所有的东西只不过是我现在不知道而已，总有一天我会把所有的细节、所有的内部的东西全搞明白的。

好了，说了这么多，其实是想告诉大家，做一只咸鱼很简单，如果你一辈子想做一个码农，就不用学原理。

其实不仅仅是技术，测试，运营，产品，掌握了背后的底层原理，相信你就和别人逐渐拉开差距了，因为你们已经站在不一样的维度上去看待事情了。

搞清楚背后的底层原理，我们就更容易做到触类旁通，举一反三。

如果做一只有梦想的咸鱼，有同样想法的人，又一直下不定决心去学习的人，我们可以一起，互相监督，互相学习交流。

共勉。

我是小贺，我们下期再见。

ps：扫码加我好友，拉你进百人技术交流群。

·················END·················

你好，我是 herongwei，一个精神小伙&amp;五道口程序猿，热爱编程，热爱生活，热爱分享，在平凡的人生中追求一点不平凡，欢迎关注，一起加油，点击下方名片，了解更多。