Redis初步认识

官网：redis.io

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助

 

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。[1] 

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

redis的官网地址，非常好记，是redis.io。（特意查了一下，域名后缀io属于国家域名，是british Indian Ocean territory，即英属印度洋领地）

目前，Vmware在资助着redis项目的开发和维护。

 

Redis是一个key-value存储系统。和Memcached类似，但是解决了断电后数据完全丢失的情况，而且她支持更多无化的value类型，除了和string外，还支持lists（链表）、sets（集合）和zsets（有序集合）几种数据类型。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。

安装

获取源码、解压、进入源码目录

使用wget工具等下载：

wget （百度不让用链接）

tar xzf redis-1.2.6.tar.gz

cd redis-1.2.6。

编译生成可执行文件

由于makefile文件已经写好，我们只需要直接在源码目录执行make命令进行编译即可：

make

make-test

sudo make install

make命令执行完成后，会在当前目录下生成本个可执行文件，分别是redis-server、redis-cli、redis-benchmark、redis-stat，它们的作用如下：

redis-server：Redis服务器的daemon启动程序

redis-cli：Redis命令行操作工具。当然，你也可以用telnet根据其纯文本协议来操作

redis-benchmark：Redis性能测试工具，测试Redis在你的系统及你的配置下的读写性能

redis-stat：Redis状态检测工具，可以检测Redis当前状态参数及延迟状况。

建立Redis目录（非必须）

这个过程不是必须的，只是为了将Redis相关的资源统一管理而进行的操作。

执行以下命令建立相关目录并拷贝相关文件至目录中：

sudo -s

mkdir -p /usr/local/redis/bin

mkdir -p /usr/local/redis/etc

mkdir -p /usr/local/redis/var

cp redis-server redis-cli redis-benchmark redis-stat /usr/local/redis/bin/

cp redis.conf /usr/local/redis/etc/

 

配置参数

在我们成功安装Redis后，我们直接执行redis-server即可运行Redis，此时它是按照默认配置来运行的（默认配置甚至不是后台运行）。我们希望Redis按我们的要求运行，则我们需要修改配置文件，Redis的配置文件就是我们上面第二个cp操作的redis.conf文件，它被我们拷贝到了/usr/local/redis/etc/目录下。修改它就可以配置我们的server了。如何修改？下面是redis.conf的主要配置参数的意义：

daemonize：是否以后台daemon方式运行

pidfile：pid文件位置

port：监听的端口号

timeout：请求超时时间

loglevel：log信息级别

logfile：log文件位置

databases：开启数据库的数量

save * *：保存快照的频率，第一个*表示多长时间，第二个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。

rdbcompression：是否使用压缩

dbfilename：数据快照文件名（只是文件名，不包括目录）

dir：数据快照的保存目录（这个是目录）

appendonly：是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。

appendfsync：appendonlylog如何同步到磁盘（三个选项，分别是每次写都强制调用fsync、每秒启用一次fsync、不调用fsync等待系统自己同步）

下面是一个略做修改后的配置文件内容：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

daemonizeyes pidfile/usr/local/redis/var/redis.pid port6379 timeout300 logleveldebug logfile/usr/local/redis/var/redis.log databases16 save9001 save30010 save6010000 rdbcompressionyes dbfilenamedump.rdb dir/usr/local/redis/var/ appendonlyno appendfsyncalways glueoutputbufyes shareobjectsno shareobjectspoolsize1024

 

 

将上面内容写为redis.conf并保存到/usr/local/redis/etc/目录下

然后在命令行执行：

/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

即可在后台启动redis服务，这时你通过

telnet127.0.0.16379

即可连接到你的redis服务

Redis常用内存优化手段与参数

通过我们上面的一些实现上的分析可以看出redis实际上的内存管理成本非常高，即占用了过多的内存，作者对这点也非常清楚，所以提供了一系列的参数和手段来控制和节省内存，我们分别来讨论下。
　　首先最重要的一点是不要开启Redis的VM选项，即虚拟内存功能，这个本来是作为Redis存储超出物理内存数据的一种数据在内存与磁盘换入换出的一个持久化策略，但是其内存管理成本也非常的高，并且我们后续会分析此种持久化策略并不成熟，所以要关闭VM功能，请检查你的redis.conf文件中 vm-enabled 为 no。
　　其次最好设置下redis.conf中的maxmemory选项，该选项是告诉Redis当使用了多少物理内存后就开始拒绝后续的写入请求，该参数能很好的保护好你的Redis不会因为使用了过多的物理内存而导致swap,最终严重影响性能甚至崩溃。
　　另外Redis为不同数据类型分别提供了一组参数来控制内存使用，我们在前面详细分析过Redis Hash是value内部为一个HashMap，如果该Map的成员数比较少，则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销，这个参数控制对应在redis.conf配置文件中下面2项：

1. hash-max-zipmap-entries 64
2. hash-max-zipmap-value 512
3. hash-max-zipmap-entries

含义是当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储，默认是64,即value内部有64个以下的成员就是使用线性紧凑存储，超过该值自动转成真正的HashMap。
　　hash-max-zipmap-value 含义是当 value这个Map内部的每个成员值长度不超过多少字节就会采用线性紧凑存储来节省空间。
　　以上2个条件任意一个条件超过设置值都会转换成真正的HashMap，也就不会再节省内存了，那么这个值是不是设置的越大越好呢，答案当然是否定的，HashMap的优势就是查找和操作的时间复杂度都是O(1)的，而放弃Hash采用一维存储则是O(n)的时间复杂度，如果
　　成员数量很少，则影响不大，否则会严重影响性能，所以要权衡好这个值的设置，总体上还是最根本的时间成本和空间成本上的权衡。

同样类似的参数

list-max-ziplist-entries 512
　　说明：list数据类型多少节点以下会采用去指针的紧凑存储格式。
　　list-max-ziplist-value 64
　　说明：list数据类型节点值大小小于多少字节会采用紧凑存储格式。
　　set-max-intset-entries 512
　　说明：set数据类型内部数据如果全部是数值型，且包含多少节点以下会采用紧凑格式存储。
　　最后想说的是Redis内部实现没有对内存分配方面做过多的优化，在一定程度上会存在内存碎片，不过大多数情况下这个不会成为Redis的性能瓶颈，不过如果在Redis内部存储的大部分数据是数值型的话，Redis内部采用了一个shared integer的方式来省去分配内存的开销，即在系统启动时先分配一个从1~n 那么多个数值对象放在一个池子中，如果存储的数据恰好是这个数值范围内的数据，则直接从池子里取出该对象，并且通过引用计数的方式来共享，这样在系统存储了大量数值下，也能一定程度上节省内存并且提高性能，这个参数值n的设置需要修改源代码中的一行宏定义REDIS_SHARED_INTEGERS，该值默认是10000，可以根据自己的需要进行修改，修改后重新编译就可以了。
　　另外redis 的6种过期策略redis 中的默认的过期策略是volatile-lru 。设置方式
　　config set maxmemory-policy volatile-lru
　　maxmemory-policy 六种方式
　　volatile-lru：只对设置了过期时间的key进行LRU（默认值）
　　allkeys-lru ： 是从所有key里 删除 不经常使用的key
　　volatile-random：随机删除即将过期key
　　allkeys-random：随机删除
　　volatile-ttl ： 删除即将过期的
　　noeviction ： 永不过期，返回错误
　　maxmemory-samples 3 是说每次进行淘汰的时候 会随机抽取3个key 从里面淘汰最不经常使用的（默认选项）

版本发布

编辑

2012年08月02日，Redis 2.4.16 小更新版本 NoSQL。[3] 

2012年08月31日 ，Redis 2.4.17 小更新版本 NoSQL。[4] 

2012年11月7日 Redis 2.6.3 发布，高性能K/V服务器

2013年4月30日Redis 2.6.13 发布，高性能K/V服务器[5] 

2013年11月25日，Redis 2.8.1发布。[6] 

2015年2月，Redis3.0.0发布.[7] 

 

 

教程网址：http://tengine.taobao.org/book/chapter_02.html

 

nginx是以多进程的方式来工作, 也是nginx的默认方式

nginx在启动后，会有一个master进程和多个worker进程

master进程主要用来管理worker进程

包含：接收来自外界的信号       ，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的。nginx的进程模型，可以由下图来表示：

 

 

kill -HUP pid  #重启nginx

 

#nginx在0.8版本之后,有了以下命令，方便管理

./nginx -s reload #重启nginx

./nginx -s stop #停止nginx的运行

 

nginx采用了异步非阻塞的方式来处理请求，nginx是可以同时处理成千上万个请求的。想想apache的常用工作方式（apache也有异步非阻塞版本，但因其与自带某些模块冲突，所以不常用）

 

请求的完整过程：

首先，请求过来，要建立连接，然后再接收数据，接收数据后，再发送数据。具体到系统底层，就是读写事件，而当读写事件没有准备好时，必然不可操作，如果不用非阻塞的方式来调用，那就得阻塞调用了，事件没有准备好，那就只能等了，等事件准备好了，你再继续吧。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。

 

并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。 我之前有对连接数进行过测试，在24G内存的机器上，处理的并发请求数达到过200万。

 

当我们写nginx代码时，在处理网络事件的回调函数时，通常做的第一个事情就是判断超时，然后再去处理网络事件。

 

nginx是如何处理一个连接的??

首先，nginx在启动时，会解析配置文件，得到需要监听的端口与ip地址，然后在nginx的master进程里面，先初始化好这个监控的socket(创建socket，设置addrreuse等选项，绑定到指定的ip地址端口，再listen)，然后再fork出多个子进程出来，然后子进程会竞争accept新的连接。此时，客户端就可以向nginx发起连接了。当客户端与服务端通过三次握手建立好一个连接后，nginx的某一个子进程会accept成功，得到这个建立好的连接的socket，然后创建nginx对连接的封装，即ngx_connection_t结构体。接着，设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后，nginx或客户端来主动关掉连接，到此，一个连接就寿终正寝了。

 

 

通过ulimit -n，我们可以得到一个进程所能够打开的fd的最大数，即nofile，

每个socket连接会占用掉一个fd

 

学习网址（参考）：http://www.runoob.com/redis/redis-intro.html