redis和memcached 对比

概述

本文包含了memcached和redis的简单对比。
以及Redis一些技术特点的介绍。

对比

二者结构基本一致，都是服务器-客户端的架构。
二者基础结构都是key-value的形式，但是redis支持的Value形式自己进行了包装。
基本命令，memcached基本是增删查改，redis比memcached支持的更多了，对于独有的Value类型对应了特殊的操作。
memcached不支持持久化，redis支持两种形式的持久化。
redis支持服务端的lua脚本执行，而且脚本执行一次，就会存储到服务器端，其他客户端就可以调用了。
redis还支持Subscribe/Publish（订阅/发布）。
memcached的集群通过客户端的算法进行选择，redis集群支持多种形式，包括了服务器和客户端。
memecached无法保证数据的有效性，因为内部采用了LRU的淘汰规则，redis保证了数据的有效性，除非你对当前数据设置了失效规则。

Redis支持的数据类型

String

支持的操作主要有：set,get,decr,incr
set,get很容易理解，设置某个key为指定的值，或者获取某个key对应的值。
decr和incr会自动转换为int。
以上的操作和memcached基本一致。

Hash

Hash很容易理解。为一个key指定一个hash存储结构，这个结构也是key-value的形式。
主要的操作：hget,hset,hgetall等

操作格式：

命令 说明 hget key hashKey 获取名称为key的hash中hashKey对应的值 hset key hashkey hashValue 向名称key的hash设置hashkey-hashValue

List

list也很容易理解。为一个key指定一个List的存储结构，这个list是顺序存储的。
主要的操作：lpush,rpush,lpop,rpop,lrange等。
l开头的是对头进行操作，r开头的是对尾进行操作。

操作格式：

命令 说明 lpush key listvalue 为名称为key的list的头添加listvalue. lpop key 返回并删除名称为key的list中的头元素

Set

set的这个结构和list非常想，只不过set不会保存相同的值。
常用的操作：sadd,spop,smembers,sunion 等。

操作说明

命令 说明 sadd key value 向名称为key的set中添加元素value srem key value 删除名称为key的set中的元素value

Sorted set

Sorted Set 和Set非常的像，可以认为是set的加强版。
set是不能排序的，但是SortedSet通过添加权值的方式进行排序。
常用的操作：zadd,zrange,zrem,zcard等

操作说明

命令 说明 zadd key score value 向名称为key的set中添加元素value zrem key value 删除名称为key的set中的元素value zcard key 获取有序集合的成员数

---

注：以上的操作举例都是最简单的，redis提供了丰富的操作指令方便对redis进行各种的操作。
操作函数可以去官网查看.也可以去国内的一些网站查看。 http://redis.io
http://www.runoob.com/redis/redis-tutorial.html

redis持久化

redis的持久化有RDB和AOF两种。

RDB

默认情况redis是会以快照的形式将数据持久化到磁盘的。生成一个二进制文件，dump.rdb，这个文件名字可以指定。
在配置文件中的格式是：save N M
表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。
当然我们也可以手动执行save或者bgsave（异步）做快照。
简单来说就是： RDB是记录一段时间内的操作，触发记录的规则是一段时间内操作超过多少次就持久化。

AOF

RDB的形式当redis挂掉的时候，会发生数据丢失的情况。解决这个问题必须使用另一种持久化形式AOF。
AOF可以实现每次操作都持久化。
在redis配置文件中修改appendonly 的属性。
默认是appendonly no，改成appendonly yes。
再找到appendfsync 。

属性 说明 always 每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用 everysec 每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐 no 依靠OS进行刷新，性能最好,持久化没保证

---

注：
AOF文件随着时间的推移会越来越大，如何解决这个问题呢？
Redis建议：AOF持久化形式一般和BgRewriteAOF操作配合使用。
每次执行bgrewriteaof都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存多余的变化情况，这样就使AOF文件的尺寸最小。

redis支持脚本

建立脚本ratelimiting.lua

//keys[1]对应的数字加1local times = redis.call('incr',KEYS[1])//如果是1 表示第一次调用，设置KEYS[1]的超时时间为ARGV[1]，超过这个时间这个KEYS[1]就失效了if times == 1 then    redis.call('expire',KEYS[1], ARGV[1])end//如果被调用的次数大于指定的次数则返回0if times > tonumber(ARGV[2]) then    return 0end//否则返回1return 1

执行脚本

redis-cli --eval ratelimiting.lua rate.limitingl:127.0.0.1 , 10 3

脚本说明

值 说明 redis-cli –eval 客户端调用脚本的格式 ratelimiting.lua 脚本的名称，当前路径 rate.limitingl:127.0.0.1 对应的key 10 ARGV[1] 3 ARGV[2]

其中”,”前的rate.limiting:127.0.0.1是要操作的键，可以再脚本中用KEYS[1]获取;
“,”后面的10和3是参数，在脚本中能够使用ARGV[1]和ARGV[2]获得。
注：”,”两边的空格不能省略，否则会出错

执行看看效果

[root@rhel6 redis-learning]# redis-cli --eval ratelimiting.lua rate.limitingl:127.0.0.1 , 10 3(integer) 1[root@rhel6 redis-learning]# redis-cli --eval ratelimiting.lua rate.limitingl:127.0.0.1 , 10 3(integer) 1[root@rhel6 redis-learning]# redis-cli --eval ratelimiting.lua rate.limitingl:127.0.0.1 , 10 3(integer) 1[root@rhel6 redis-learning]# redis-cli --eval ratelimiting.lua rate.limitingl:127.0.0.1 , 10 3(integer) 0[root@rhel6 redis-learning]# redis-cli --eval ratelimiting.lua rate.limitingl:127.0.0.1 , 10 3(integer) 0

客户端发送的脚本会永久存储在Redis中，意味着其他客户端可以复用这一脚本而不需要使用代码完成同样的逻辑。

redis集群

redis支持主从。
redis自身支持Sharding（分片式的集群）。
redis集群第三方工具Codis（工具比较完整）。

可以参考：
http://mt.sohu.com/20160601/n452401108.shtml
http://blog.csdn.net/myrainblues/article/details/25881535/

有时间会专门写一篇关于redis集群的文章。

redis的Subscribe/Publish

这个功能，在打算写这篇文章之前是从来没有用到过，因此特意看了一下相关的文章，整理如下：
1：基本实现了订阅和发布的功能。
2：如果订阅方断线了，那么订阅方断线时间内的所有发布的消息，不会缓存，将会丢失（这个我还没有确认）。
3：性能不错，3~4w/s。

具体可以看下面引用的文章。

文章引用：
http://www.cnblogs.com/yanghuahui/p/3697996.html
https://www.zhihu.com/question/19829601
http://blog.csdn.net/colorant/article/details/21089057
http://blog.csdn.net/tonysz126/article/details/8280696/
http://www.runoob.com/redis/redis-tutorial.html
http://huangzixun.iteye.com/blog/1871495
http://blog.csdn.net/u011499747/article/details/51232981
http://kingxss.iteye.com/blog/1420264
http://blog.sina.com.cn/s/blog_62b832910100xok2.html