官网公布数据:读的速度是 110000 次 / s, 写的速度是 81000 次 / s
redis 是一个 key-value 存储系统。和 Memcached 类似,它支持存储的 value 类型相对更多,包括 string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合) 和 hash(哈希类型)。这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis 支持各种不同方式的排序。与 memcached 一样,为了保证效率,数据都是缓存在内存中。区别的是 redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了 master-slave(主从) 同步。(来自百度百科)
- 性能方面:没有必要过多的关心性能,因为二者的性能都已经足够高了。由于 Redis 只使用单核,而 Memcached 可以使用多核,所以在比较上,平均每一个核上 Redis 在存储小数据时比 Memcached 性能更高。而在 100k 以上的数据中,Memcached 性能要高于 Redis,虽然 Redis 最近也在存储大数据的性能上进行优化,但是比起 Memcached,还是稍有逊色。说了这么多,结论是,无论你使用哪一个,每秒处理请求的次数都不会成为瓶颈。(比如瓶颈可能会在网卡)
- 内存使用效率:使用简单的 key-value 存储的话,Memcached 的内存利用率更高,而如果 Redis 采用 hash 结构来做 key-value 存储,由于其组合式的压缩,其内存利用率会高于 Memcached。当然,这和你的应用场景和数据特性有关。
- 数据持久化:如果你对数据持久化和数据同步有所要求,那么推荐你选择 Redis,因为这两个特性 Memcached 都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失,选择 Redis 也是明智的。
- 数据结构: 当然,最后还得说到你的具体应用需求。Redis 相比 Memcached 来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在 Memcached 里,你需要将数据拿到客户端来进行类似的修改再 set 回去。这大大增加了网络 IO 的次数和数据体积。在 Redis 中,这些复杂的操作通常和一般的 GET/SET 一样高效。所以,如果你需要缓存能够支持更复杂的结构和操作,那么 Redis 会是不错的选择。
- 网络 IO 模型方面:Memcached 是多线程,分为监听线程、worker 线程,引入锁,带来了性能损耗。Redis 使用单线程的 IO 复用模型,将速度优势发挥到最大,也提供了较简单的计算功能
- 内存管理方面:Memcached 使用预分配的内存池的方式,带来一定程度的空间浪费, 并且在内存仍然有很大空间时,新的数据也可能会被剔除,而 Redis 使用现场申请内存的方式来存储数据,不会剔除任何非临时数据 Redis 更适合作为存储而不是 cache
- 数据的一致性方面:Memcached 提供了 cas 命令来保证. 而 Redis 提供了事务的功能,可以保证一串命令的原子性,中间不会被任何操作打断
redis 有 5 种数据类型:string(字符串)、hash(哈希表)、list(链表)、set(集合)、zset(有序集合)
redis 编码方式:raw(简单动态字符串)、int(long 整数)、ht(字典)、linkedlist(双端链表)、ziplist(压缩链表)、skiplist(跳跃表)、intset(整数集合)
默认使用的持久化方式
命令 SAVE BGSAVE
SAVE 会阻塞服务器进程,直到 rdb 文件创建完成
BGSAVE 不会阻塞,会派出一个线程实现
启动服务器自动导入 rdb 文件,若有 aof 文件优先导入 aof 文件redis 默认使用 BGSAVE 方式,配置文件指定执行间隔
save 900 1 #900 秒内有一次变更
save 300 10 #300 秒内有 10 次变更
save 60 10000 #60 秒内有 10000 次变更
创建一个不带网络链接的虚拟客户端,执行 aof 文件中命令
注:redis 命令只能在客户端上下文执行aof 命令追加会导致 aof 文件越来越大,影响性能
触发 AOF 后台重写的条件
2、服务器在 AOF 功能开启的情况下,会维持以下三个变量:
每次当 serverCron(服务器常规操作)函数执行时,它会检查以下条件是否全部满足,如果全部满足的话,就触发自动的 AOF 重写操作:
1)、没有 BGSAVE 命令(RDB 持久化)/AOF 持久化在执行;
2)、没有 BGREWRITEAOF 在进行;
3)、当前 AOF 文件大小要大于 server.aof_rewrite_min_size(默认为 1MB),或者在 redis.conf 配置了 auto-aof-rewrite-min-size 大小;
4)、当前 AOF 文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比(在配置文件设置了 auto-aof-rewrite-percentage 参数,不设置默认为 100%)
如果前面三个条件都满足,并且当前 AOF 文件大小比最后一次 AOF 重写时的大小要大于指定的百分比,那么触发自动 AOF 重写。
主从服务器达到一致以后,主服务器执行写命令后,会将命令发送给从服务器,确保状态一致
注:老版的 SYNC 复制,不能解决断线重连问题(断线重连后会整个复制一次,性能很低),新版复制使用 PSYNC 增加部分复制功能,通过偏移量实现(详情见:redis 设计与实现第二版)是 redis 高可用性的一种解决方案
由一个或多个 sentinel 实例组成 sentinel 系统,监视任意多个主服务器及主服务器的从服务器,当主服务器下线时将其从服务器升级为新的主服务器,继续处理命令(详情见:redis 设计与实现第二版)
redis 使用集群后,就没有那个数据库的概念了,集群将整个数据库分为 16384 个槽(slot),每个节点管理 0-16384 个槽,当所有槽都有节点处理的时候集群处于上线状态,否则集群是下线状态
计算 key 属于那一个槽算法
CRC16(key) & 16383 CRC16(key) 计算 CRC-16 校验和, & 16383 计算出一个介于 0-16383 的整数做为 key 的槽号
没有使用过(详情见:redis 设计与实现第二版)
keys key*
ttl key
type key
del key
exists key
info 打印 redis 服务器信息
flushdb 删除当前 db 的所有 key
flushall 删除所有 db 的所有 key
命令可以参考 https://www.cnblogs.com/luoxn28/p/5790313.html
假定有一个实时的竞技场评分,在玩家结束操作后打分,并动态显示玩家的排行榜
zadd rank 100 biki 87 zhibin 72 ming 64 fen 98 cat
(integer) 5
显示得分最高的前三名玩家
ZREVRANGE rank 0 2 WITHSCORES
1) "biki"
2) 100.0
3) "cat"
4) 98.0
5) "zhibin"
6) 87.0
通过 setnx 命令实现
成功设置值返回 1,否则返回 0注意:使用 redis 实现分布式锁,需要设置过期时间,防止产生死锁
- 127.0.0.1:6379> setnx test value
- (integer) 1
- 127.0.0.1:6379> setnx test value
- (integer) 0
- 127.0.0.1:6379>
参考资料
redis 设计与实现(第二版)
http://blog.csdn.net/hguisu/article/details/8836819 https://baike.baidu.com/item/Redis/6549233?fr=aladdin来源: http://blog.csdn.net/eos2009/article/details/78780651