如何学习一项新技术，以redis为例

本文只是从工程技术的角度来谈谈我的一些体会。

 
在软件领域学习一项新的技术无非是一些框架，工具，工程方法，甚至是软件。
 
以redis为例说一下我的学习过程：
 
1，先在网上大概了解一下redis是个什么东西，有了对redis的一个初步的了解；

2，登陆官网，下载安装一下，根据redis提供的client简单操作一下（已经有了很直观的认识了）；

3，看一下redis最突出的特点，比如丰富的数据结构，可持久化（其实我感觉持久化并不算是突出的特点，memcached借助插件也是可以的）。这个时候已经基本了解了redis的数据结构，知道可以用她存储一些更复杂的数据，简化编码，贴近业务。
 
4，找到编程语言的client，比如说java的jedis，用编程的方法操作redis。写几个基本的api，这时候其实使用redis没有问题了。不会再觉得redis算什么高大上的东西了。
 
5，全面详细的学习理解：那么作为一个新手，也没人指导的情况下该学习哪些东西呢，或者是redis都具体有哪些特点（在应用层面上）。其实我发现好多的开源项目都可以从她的配置文件上进行突破。例如redis查看配置文件redis.conf，里面的选项其实涵盖了大部分的应用特点（其他软件其实也是一样）

说几个比较重要的：持久化的配置（RDB和AOF），数据结构的压缩（ziplist和zipmap）。。。
 
6，理解这些配置的使用场景和背后的基本原理，如果能够结合着真实的或者是具体的业务场景来运行一段时间并在其中总结经验那将是非常好的（这或许就是所说的大并发，大集群。。。的经验吧）

1，先说实际使用吧，过程中遇到了一些问题比如说数据结构操作的理解不到位（尤其是感觉list是一个比较奇葩的数据结构），还有就是业务数据转换到redis数据不适合；不过遗憾的是没有接触到数据的大容量大并发的情况，只模拟了一些测试；

2，当然在做项目的过程中肯定也会去理解redis相关的一些基本原理，下面捡几个简要介绍一下：

redis的持久化：

RDB快照 

Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成RDB文件。 

通过Redis的save指令来配置RDB快照生成的时机，
1,可以配置当10分钟以内有100次写入就生成快照;
2,配置当1小时内有1000次写入就生成快照，
3,也可以多个规则一起实施。
这些规则定义在Redis的配置文件中，也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。 
RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。 
但是，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的.

AOF日志的全称是Append Only File
它是一个追加写入的日志文件。AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。
AOF重写 
每一条写命令都生成一条日志，那么AOF文件是不是会很大？答案是肯定的，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。 


Redis持久化性能的可靠性
在Redis中对AOF调用write写入后，何时再调用fsync将其写到磁盘上，通过appendfsync选项来控制，下面appendfsync的三个设置项，安全强度逐渐变强。 
1、appendfsync no 
当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。 
2、appendfsync everysec 
当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一 次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。 
所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。 这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。 
3、appednfsync always 
当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

redis基本数据类型简介： 

1、String
2、Hash
这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。
实现方式：
上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
3、List
比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现
实现方式：
Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4、Set
特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
实现方式：
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
5、Sorted set
Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
实现方式：
Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单

7，深入学习redis一些功能背后的实现，原理，当然是最好结合着源代码看

1，redis的epoll模型实现，这个我总结过很多资料了，c语言不是强项，所以只用nio结合着实现了一下，在nio的实现过程中写法其实是select轮询的方式，不过其在liunx上执行的时候是转换为epoll模型的。这里总结epoll的几个特点：（1）只管活跃的连接（这里说的活跃其实我感觉是不是在等待read的连接，其实这在局域网内影响不打）；（2）采用系统监听的方式来通过触发事件,这个监听的过程是由系统内核完成的；（3）读取数据的nmap机制（其实我感觉这就是内存映射文件的机制）。

2，研究redis数据结构的实现和思想。比如利用list类型利用跳跃表来实现；ziplist和zipmap的设计思想（这个只能结合着源码和讲解一点点的摸索了）。文章写的有点长了，以后再渐渐完善这最重要的一个阶段吧。

 
 
8，如果这些步骤全部完成后，虽然只是学习了一个软件，但是对一个程序员的提升还是很大的。

参考：

除了我的博文之外还有：
http://jandyu.diandian.com/post/2012-03-15/16145594

http://www.iteye.com/news/24675