趁着年轻

Redis stream支持多个消费者在同一个group里面消费，并且一条消息只会发送给一个消费者，不会被同组内的多个consumer获取。但有些特殊情况也不得不注意。

阅读全文...

上面的文章整体介绍了stream 实现方式，以及xadd生产端的流程，接下来继续写一下后面消费端的过程。
redis stream的消费方法有几种， XREAD、XREADGROUP， 还有xrange/xrevrange， 后者比较简单，主要就是准备参数然后调用streamReplyWithRange 来根据范围读取消息内容。
阅读全文...

kafka在日志处理领域由于其一系列的工具，其他相关服务，基本上算得上是王者，但是缺点也很明显： 难以维护，性能低，需要大量机器，部署复杂，参数众多。
前阵子Redis 5.0 Beta版本发布 ， 随之而来的重大特性“Introduction to Redis Streams”， 似乎跟kafka在功能上有很多类似的地方，但也有不少不一样的点。
阅读全文...

前段时间了解Go语言，开始了解Go的优秀开源服务，所以找出NSQ学习一下，下载了一份nsq源码开始学习，顺便记录一下阅读的笔记。

对协程实现原理感兴趣的话推荐看一看libtask，几年前在看源码的时候写过2篇笔记，里面有代码和注释：libtask协程库实现源码学习

NSQ是一个实时分布式消息处理服务，支持分布式，其源码包括：
1. nsqd 作为一个主要的消息接受，发送， 跟客户端沟通的后台进程，负责监听客户端连接，处理客户端的发送接收请求；
2. nsqlookupd 是一个管理进程，其他所有nsqd启动会尝试不断连接他，上报topic信息等；
3. nsqadmin 管理进程；
4. 其他便利工具；

阅读全文...

还记得，深夜，你在Redis 命令行里敲入"keys *" 后，线上开始报警，然后只能举起双手焦急的等待几千万key被慢慢扫描几十分钟还没结果，束手无策的时候，你跟所有redis用户拥有同样的心声：“就不能温柔点让我遍历一遍所有的数据吗？”
要知道，遍历一下数据库里面的所有数据，是多么理所应当的要求，这在mysql等关系型数据库眼里是多么的不可理解的。

阅读全文...

续上一篇文章 Redis Scan迭代器遍历操作原理（一）--基础 ，这里着重讲一下dictScan函数的原理，其实也就是redis SCAN操作最有价值（也是最难懂的部分）。

关于这个算法的源头，来自于githup这里：Add SCAN command #579，长篇的讨论，确实难懂····建议看看这帖子，antirez 跟pietern 关于这个奇怪算法的讨论···

这个算法的作者是：Pieter Noordhuis，作者称其为：reverse binary iteration ，不知道我一对一翻译为“反向二进制迭代器”可不可以，不过any way ··作者自己也没有明确的证明其真假： 阅读全文...

Redis在2.8.0版本新增了众望所归的scan操作，从此再也不用担心敲入了keys*, 然后举起双手看着键盘等待漫长的系统卡死了···

命令的官方介绍在这里， 中文版由huangz同学细心翻译了，作者Antirez的介绍在这里：Finally Redis collections are iterable （我又邪恶的想到了之前他那次机器down机的事故了···）。

具体的使用参考上面的链接即可，这里大概介绍一下Scan操作的实现原理。 阅读全文...

先说一下影响：在主从模式下的从redis如果开启了定期BGSAVE，并且在做SYNC的时候，可能存在数据错乱的问题，目前2.8.8最新稳定版也存在这个bug。

redis的BGSAVE和slaveof触发的同步操作是互不相关的（对于从库），所以就完全有可能同时在进行备份和同步。看一下下面的代码： 阅读全文...

前几天突然线上的redis slave 把64G的内存给占用满了，本来机器上的数据正常只会占用55.5%左右35G的内存的。
查看进程情况，当时redis正好在做BGSAVE操作，所以有2个Redis进程存在，初步怀疑是因为这个原因，但是理论上redis的BGSAVE是fork出来的进程，他们刚开始是共用物理内存的（Redis源码学习-AOF数据持久化原理分析(0)），除非主进程有数据修改，其实就是利用了操作系统的COW机制，巧妙的对redis做了一个数据快照。但明显线上系统不可能短时间内触发大部分数据的修改，所以排除这个的原因。 阅读全文...

前几天碰到碰到一个线上redis CPU跑满的情况，基本无法处理正常请求了，刚开始以为是其他地方的问题，后来grep "Max open files" /proc/`pidof redis-server`/ -r  排查原来是启动redis的时候。ulimit -n 只有1024，从而无法接受新连接。

晚高峰时段段时间突发的大量请求导致某个时候redis连接数超过1024，从而listen sock 持续可读并且accept失败，从而CPU跑满，进而导致更严重的雪崩。 阅读全文...

前面的2篇文章分别介绍了Redis主从同步源码浅析-Master端 以及 Redis主从同步源码浅析-Slave端 相关的代码实现，从中我们可以看出redis主从同步的一个最大的缺点，也是阻碍大数据应用的地方便是其每次连接端开都需要重连master进行全量数据的重新同步，这个代价是可想而知的。

长连接断开在线上环境中出现得很频繁，如果需要重新同步所有RDB文件，几十G的文件，从建立RDB快照，发送文件内容到slave，然后slave执行命令一一加载进内存中，这个时间开销估计也得好几个小时，更别说树形结构的master->slave->slave， 对网卡的压力，对服务器的压力都是很恐怖的。从这方面来说，动辄几个小时甚至一天的修复时间，没人敢用Redis主从同步在生产环境中使用。

但是福音来了：即将（2013年第三季度）发布的2.8版本会解决这个问题，通过：Replication partial resynchronization 的方式，也就是部分重新同步，这里就说部分同步吧，注意不是常规情况下的新写入指令同步。 阅读全文...

前一篇文章写了下redis主从同步的server端代码，这里补一下slave端的。

简单来讲，看了master端就知道slave端的代码大概流程了：

1. 中断跟本slave的下一级slave的连接，强迫其重连SYNC；
2. 给master发送PING确认其状态是否OK；
3. 发送SYNC要求master做RDB快照（2.8版本以上会有PSYNC的指令，也就是部分同步，下回介绍。）；
4. 接收RDB文件大小；
5. 接收RDB文件；
6. emptyDb()清空当前数据库，rdbLoad()重新加载新的RDB文件；
7. 按需startAppendOnly，然后接收master过来的累积和实时更新数据；

下面分别介绍这些步骤。 阅读全文...

关于Redis的主从同步的基本介绍这里有:Replication, 不多介绍了。本文只涉及到主库的代码，从库的相关代码改天补上。

这里主要介绍redis 2.6.13版本代码，目前2.8新增了一些功能，比如增量同步功能等，不过到目前2013-10-05还没有正式上线。总结一下几点跟下面相关的：

1. 同步采用类似mysql的操作日志重放方式，将写操作分发到从库重放。
2. 每次从库启动必须从主库重新同步一份全量RDB数据文件，因此不能随便停止从库；
3. 数据同步采用异步将写操作指令发送给从库的方式进行。

总体来说，redis的同步原理是：slave启动时下载所有数据快照，下载快照过程中产生的新写操作日志会不断累积记录起来，发送完快照后就发送这部分增量日志，日志在slave端进行重放。下面分步讲。 阅读全文...

回顾一下之前看的redis代码，脑子内存比较小，一会就忘了，所以备忘一下。
redis主体流程比较简单，init,listen, accept, read, write,基本就是这几步。下面简单介绍一下，当做备忘。 阅读全文...

字典和hash表的实现都大同小异，所以简单说一下不同点。

0.概要

redis的字典是使用hash表实现的，相同hash值的key保存在list中，也就是index= hash(key)， index代表了key所在的数组下标，也就是槽位。查找操作找到槽位后，需要遍历下面的链表的元素去查找对应的key。插入操作将新key插入到链表的头部。 阅读全文...

继上面一篇文章“Redis源码学习-AOF数据持久化原理分析(0)”，介绍了Redis是如何将不断从客户端发送过来的数据持久化到AOF文件中的。这里介绍一下AOF rewrite是如何工作的，也就是redis是如何将AOF文件初始化，并后台自动AOF rewrite的。 阅读全文...

Redis作为一个使用广泛的KV内存存储，其也支持一定的数据持久化，这里试着介绍一下Redis在源码层面对持久化的实现机制。

总的来说，Redis支持的将其数据库里面的KV数据存储到磁盘，但可能会有短时间的丢失。官网关于持久化的介绍可以参考这里“Redis Persistence”,这篇文章介绍一下其在代码层面的实现。

其支持2中不同的持久化机制：

1. 第一种RDB数据快照持久化。RDB持久化实际上就是对数据库内容做快照，然后将快照存储到磁盘上面，这样就要去我们进行周期性的做快照，但是这种方式无法做到实时的存储，出现故障时只能恢复上一次做快照时的状态，因此比较有限。不过redis的主从同步也是利用RDB实现的，这个我们后续文章分析；
2. 第二种AOF日志实时持久化。AOF=Append Only File，也就是不断追加写的文件。在这种情况下，Redis首先将数据库做个快照，将数据还原为跟客户端的协议格式的文本数据，然后将其存储到一个临时文件中，然后将其覆盖成正常的aof文件，并把这个过程中新增的命令追加到aof文件后面，从此之后，后续的从客户端过来的命令都会不断根据不同的安全级别写到磁盘里面去。这样就支持了实时的持久化，只是可能会有短时间内的数据丢失，对一般系统还是可以容忍的。

下面一步步介绍其实现的原理。 阅读全文...

今天开始学习redis代码，首先内存分配。
本以为它的内存分配会很复杂的，不过看样子比较简单，基本就是在malloc上面包了一层，不过也可选的可以使用tcmalloc进行内存分配了，据说google这个tcmalloc性能不错。
不多说了，show me the code.详见代码注释。
阅读全文...