CSDN大数据会议：Redis深入浅出.doc

阿里云计算运维部高级工程师阮若夷 阮若夷主要介绍了Redis的特性和架构，以及Redis的容量规划、复制、持久化的原理。他同时介绍了Redis和关系型数据库表设计区别。 以下为文字实录 大家早上好，我是阿里云计算部的阮若夷，很高兴与大家一起分享这个PPT。今天的主题是Redis深入浅出。Redis这个东西已经在阿里云很多项目上都有使用到，比如说我们已经有800万用户阿里旺旺，今年年初推出云手机，还有我参与两个项目都使用到Redis。在今年年初的时候我们开始对系统进行选型，发现这个Redis代码非常优雅，代码量很短，创始人非常靠谱，我们就花了一些精力来进行研究Redis。 这是今天主题，先是介绍一下Redis的一些特性和它的一些架构，接下来是它的一些容量规划，还有它的一些复制，持久化的一些原理，最后是它和关系型数据库表设计区别。刚开始CSDN高松联系我的时候，因为是一个比较小的会议，没想到今天人这么多，不知道这个PPT适不适合在这里讲。 我们先介绍一下Redis的一些特性，甚至我们可以把我们数据结构直接定义在Redis本身，我们程序中数据结构，不需要定义，不需要使用C++或者Java，直接把这个结构定义在Redis里面。第二在Redis的现场模型，在2.4版本之前，Redis一直使用单线程处理所有的网络请求和连接工作，在2.4之后，会导致主线层延迟比较大，又加入两个新的后台进程来辅助做auxlliary。第三个是demultiplexer，并没有使用我们成熟的这类分解器，而是自己实现的。我没有记错在豆瓣里面也实现，实现代码比较少，功能还是不错的。在我参与的几个项目里，都有用到这个分离器，我认为还是比较优秀的一个模块。 接下来是replication持久化和复制功能，持久让我们可考虑更高，复制可以让我们做一定负载均衡，还能提高高可靠性。最后一点差异，Redis本身需要做一些设计的工作，不像我们只要把数据往里面存就管了，不用管，因为具有一个简单处理结构。Redis可能还要进行数据结构的选型，比如你这个适合做一个链表结构，还是做一个集合结构等。然后我们还需要对内存进行预估，因为Redis是一个全内存集合，不允许部分存在内存里，部分存在磁盘上，必须对内存进行预估，否则会导致数据丢失。 我们来看一个简单Set hello world，在Redis里面是如何进行存储的。首先这个Set hello world命令会在Redis内部产生一个安全结构，内部会包含一个key，就包括一个hell，然后会出现一个指令，都类似于这种结构，还有保存都必不可少。当我们Set hello world以这种形式存储，如果我们是一个Set hello1234567，其实是一个数字类型，是可以被转化成数字类型的。实际上，第二条命令，在Redis内部存储会去掉world，直接转成数字类型传到PDR这个数字结构里面，就可以节省空间。如果我们Redis数据小于Redis本身有一个内部这块会更节省空间，因为我们Redis在启动的时候，会启动从1到1万，如果你用户和他需要的数据是相同，他会进行复用，然后就可以通过引用技术来使用，这样我们可以更减少内存。 我们可以看到假设我们用户一个Set hello world，存储命令只是hello world10个件，这是一个12字节结构，由于2.4版本使用，在加上也是转化16字节，整个Set hello world 就需要64字节，本身内存就比较复杂，这就是一个缺陷。 这是Redis显示的一个链表结构，在List内部一个存储。这里可以看到指向一个双链表，里面有存储元素个数，能够比较快的使用Llan拿到链表长度，都是OE的一种操作，比较快速的。我们再看最常见的这个Zipmap这个数据结构，刚才刘江主编也提到有一个图片公司，前段时间有一个工程师也发了一个博文就讲到他们使用这个Zipmap节省大量内存。Zipmap需要辅助信息是非常少，不像我们刚才10字节需要54字节辅助内存，这个Zipmap整个只需要2个字节辅助，一个是开头Zipmap defect，会额外需要3个字节存储，有2个字节用于存储hello长度，一个是用于储存world长度，比如我修改成一个world单词，这样字节就少了一个字节。Zipmap数据结构是非常丑陋的，当你要多少空间的时候就会弄这么大一个空间，当你也数据修改，就直接把你数据修改掉，把后面空间往前推动，所以这是非常消耗CPU的。 在我们内存比较紧张的情况下，我们把内存作为一个CPU来进行使用。前段时间和新浪的一些同事聊天，说到他们用Zipmap以后，CPU使用率比较高，然后我在和Zipmap创始人交流一下，发现Zipmap有一个问题，本身只用一个字节来储存，一个字节只能有255个长度，是Zipmap这个数据结构本身要使