最近两天利用黑夜的时间参加了一个关于 Redis 的学习，时间不长，一共两天，一天两个多小时。这次的学习感觉颇有收获，也很符合我的胃口。

平时，在进行技术选型和故障排除时，对于原理的掌握其实是必不可少的。原理的东西本身就比较枯燥，而且涉及的知识范围也是比较多的，根据日常业务场景的使用情况，很多原理性的东西也未必会用到，因此愿意接触的人可能相对少吧。但是，知识这个东西也只有学了，并且理解了才会真正的去考虑去用它。否则，即使那个东西摆在那里，也不一定会去用，或者根本不知道怎么用。

这次的 Redis 学习，可以说是把它的部分原理学的比较细致了，至少从短暂的时间上来说，能学习这么多的信息量已经相当给力了。

我把我学到的东西大概总结一下，总结的可能并不是很到位，但是我觉得听了一次能总结出这些东西已经算是我尽力了。

整个的分享从存储的演进开始讲起，讲了文件、关系型数据库、非关系数据库分别是在什么场景下诞生的。其实有的书也会讲某种工具、语言的历史起源，但是这里却讲的比较形象，他并没有按照时间节点去讲怎么发展的，而是从实际的发展痛点中来讲述了技术发展的必然性。从中，也给出了一些简单的考量指标和改善的情况。

在介绍完存储的演进过程后，接着介绍了 Redis 的数据类型。也许用过 Redis 的都知道 Redis 的那几种基本数据类型，但是这里对 Redis 的数据类型只是提了一下，更多的是分析了 Redis 的数据类型和 MemCached 的数据类型的差别。从对比两个系统的数据类型，学到了两个重要的概念，而且是以前没有听说过的概念，即“数据向计算移动”和“计算向数据移动”，虽然理解起来不难，但是今后在面对新的产品时，衡量其优劣会多一个参考。而且在不同的场景，也会有更好的取舍。

数据类型并没有使用了多久的时间，更多的介绍了 Redis 的单线程。Redis 的单线程是指它的工作线程为单线程（注意是工作线程，到 6.x 的时候的多线程，是 I/O 多线程，和我们平时讨论的 Redis 是多线程的是两回事），这点通过对系统调用的跟踪进行了证实。从系统调用来跟踪 Redis 是单线程的，这种方式和以前接触的逆向分析很相似，在不去看源码的情况下，通过一些工具的辅助观察可以得到这样的结论，这点真的是很强大。除了证实它本身是单线程的外，还要讲为甚麽使用单线程而不使用多线程，在这里我 get 到了一个词，叫做“退化”。“退化”这个词以前就听说过，好像是在数据结构和算法中听说过，但是没有太多的注意这个词。其中因为多线程最终会“退化”为“串行”的原因，因此不如直接选择单线程（这里我的表述不一定准确，多线程退化为串行，指的是从 Redis 或 关系数据库 中取数据时，其实还是要排队的；当然，这只是使用单线程的一个因素）。但是，在使用单线程的时候就会遇到一个问题，就是“阻塞”的问题。为了把这个“阻塞”的问题讲明白，竟然从“系统调用”开始阐述，比如“内核态和用户态的切换”、“中断”、“DMA”等。然后通过类比的方式与思想借鉴的方式，展开了网络“阻塞”的多线程模型、NIO、多路复用等相关的内容。这部分内容，我个人觉得已经把网络编程的几种开发模型的重点讲完了，也基本上讲清楚了。当然了，这里还配合着把 Linux 下网络编程的 API 手册的几个函数过了一遍。

这些内容基本上是第一天的内容，听的真的很过瘾，毕竟对于我来说是干货，能够深入浅出的把大学的多门理论课程都串起来学，的确是提高不少。而第二天的内容是将 Redis 的五种类型的使用场景进行了介绍，就不在进行总结了。