tym8865的专栏

redis是一种内存数据库，也就是redis的数据在正常工作的情况下都是存储在内存中。但并不是说redis只能把数据存储在内存中，redis提供了两种数据持久化机制：rdb和aof。rdb持久化有三种方式被启动：用户向redis发送save或者bgsave命令。save和bgsave的不同就在于save会阻塞redis服务器，而bgsave不会。这样bgsave就在不影响redis服务器正常工作的

redis除了基本功能外，还提供了主从复制功能。一个redis服务可以有多个slave服务，而这个slave服务又可以有slave服务。

redis事务的原理介绍在redis设计与实现这本书中已经讲述的非常清楚，这里就不浪费更多的时间去讲述了。这篇博客的目的主要还是结合源码来讲述redis事务的实现。如果大家对redis有点熟悉，都知道redis客户端和服务器之间的通信都是通过命令+key+值来进行通信的（内部协议的格式在以后的博客中讲述）。redis的事务也是通过命令来实现的。MULTI 事务的开始EXEC

redis是一种nosql数据库，redis操作数据库都是通过相关命令来进行的。而且由于redis内存实现很多底层的数据结构，数据库存储的值也是这些数据结构。redis 每个命令都是对应相应的数据结构实现的。例如：LPUSH 和LLEN 只能用于列表键，而SADD 和SRANDMEMBER 只能用于集合键。从上面可以看出来，Redis 必须让每个键都带有类型信息，使得程序可以检查键的类型，并为它选

redis的整数集合实质上是动态的数组。reids的整数集合是可以根据整数的值，自动选择用什么长度来存储的。例如：如果插入的值可以用int16_t类型来保存，那所有的元素都可以用int16_t类型来保存。所以可以看出保存的类型应该有这几种：#define INTSET_ENC_INT16 (sizeof(int16_t))#define INTSET_ENC_INT32 (sizeof(

压缩列表用于存储长度受限的字符串和整数。废话不多说，直接上redis压缩列表的内存结构示意图：从图中可以看出，redis压缩列表由表示压缩列表占总内存的字节数的zlbytes，表示到达ziplist 表尾节点的偏移量的zltail，表示ziplist 中节点的数量的zllen，各个节点以及用于标记ziplist的末端的zlend。注意：zllen并不是一直表示节点的数量，只有zll

一直在redis的源码，但是很少形成笔记，理解感觉不是很深，所以决定把自己看过的源码形成文字，加深自己的理解。也希望能给想学习redis的童鞋一点帮组，如果在博文中有错误，希望大家能指出来，谢谢。

订阅和发布的介绍以及原理在redis设计与实现以及讲述清楚，这里就不啰嗦了。我们的任务主要还是根据原理来分析源码。先来看下订阅和发布会用到的结构体：struct redisServer {...... dict *pubsub_channels; /* Map channels to list of subscribed clients */ list *pubsub_pa

redis字符串相对比标准c的字串是二进制安全的，也就是说如果redis的字符串中包含'\0'字符的话，还是能计算出相应字符串的长度。下面来看下redis字符串的定义：typedef char *sds;struct sdshdr { // buf 已占长度 int len; // buf 剩余可用的长度 int free; // 实际存放字符

reids数据库是一种内存数据库，也提供了两种持久化的方式。作为内存数据库， 访问数据的速度肯定是杠杠的。但是随着数据的不断增加，消耗的内存也就越来越多直到内存消耗完。这种问题要么增加内存，要么就是将内存中的很少用到的数据替换到硬盘中。redis采用的就是第二种方法，也就是redis中的虚拟内存实现的功能。redis采用了阻塞式更替和非阻塞式更替，这个等会再讲。先来看下虚拟内存的初始化：voi