一文让你读懂redis,瞬间解决业务诸多问题!

转载自:http://baijiahao.baidu.com/s?id=1595171891425116073


在百花齐放的NoSQL年代,我们究竟需要什么样的NoSQL呢?大概在几年之前,大多数系统都会用的Memcached+MySQL的架构,使用Memcached来作为热点数据缓存,可以说大致统治了这个时代的数据库热点缓存。但是随着互联网业务的速度发展,越来越多的Memcached系统出现这样那样的问题。集中体现为:

1.MySQL需要不断拆库拆表扩容,Memcached也需不断跟着扩容,集群的管理和维护越来越重,问题也日益明显。

2.Memcached与MySQL数据库数据一致性问题,cache同步问题。

3.Memcached如果宕机,大量访问直接穿透到DB,MySQL被拖垮。

但是总结NoSQL的典型应用场景,主要是能够少量数据存储,高速读写访问。最好提供数据落地的功能,保证宕机有新的能够马上阻挡热点流量,而这正是Redis最主要的适用场景。

那么很多开发人员就会有疑问,似乎Redis像一个加强版的Memcached,那么应该使用Memcached,还是Redis呢?

redis与memcached区别

(1)性能方面:他们的性能都已经足够高。无论你使用哪一个,每秒处理请求的次数都不会成为瓶颈。memcached使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,然后压缩处理,使用率也非常高。

(2)数据持久化:如果你对数据持久化和数据同步有所要求,那么选择Redis,因为这两个特性Memcached都不具备。所以升级或者重启系统后缓存数据不会丢失。

(3)数据类型: Redis相比Memcached来说,拥有更多的数据结构(string,hash,set,list,sorted set)和并支持更丰富的数据操作。通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果你需要缓存能够支持更复杂的结构和操作,redis是最合适的。

(4)网络IO模型方面:Memcached是多线程,分为监听线程、worker线程,引入全局锁,也带来了性能损耗。Redis使用单线程的IO复用模型,将速度优势发挥到最大,各有千秋。

(5)内存管理方面:Memcached使用预分配的内存池的方式,带来一定程度的空间浪费 并且在内存仍然有很大空间时,新的数据也可能会被剔除,而Redis使用现场申请内存的方式来存储数据,不会剔除任何非临时数据。

(6)数据的一致性方面:Memcached提供了cas命令来保证。而Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断。

以上不仅是与memcached的区别,也是redis的特性。

之所以我们生产环境中,大量使用。除了拥有以上优于memcached的特性以外,更多的是有丰富的数据类型,帮助我们解决实际问题,也有集群方案解决单点宕机,击穿DB的风险。也有持久化解决启动之后需要初始化缓存的尴尬。

redis数据类型

下面介绍redis的数据类型,了解数据类型,你就明白,什么业务用,怎么用。一目了然,再不为业务高并发,慢SQL,变态需求而烦恼了。你想要的redis都有。

(1)String:数据结构是简单的key-value类型。

常用命令: set,get,decr,incr,mget 等。

应用场景:String是最常用的一种数据类型,普通的key/ value 存储都可以归为此类。即可以完全实现目前 Memcached 的功能,并且也非常高效。还可以享受Redis的定时持久化,操作日志及 Replication等功能。

(2)Hash

常用命令:hget,hset,hgetall 等。

应用场景:在Memcached中,我们经常将一些结构化的信息打包成HashMap,在客户端序列化后存储为一个字符串,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以像在数据库中Update一个字段的值一样。只修改到值,而不必取出全部数据内容。

Memcached在Hash的应用场景下,我们要存储一个用户信息对象数据,包含用户ID,姓名,年龄,生日等信息,主要有以下2种存储方式:

No.1将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。

No.2这个用户信息对象有多少成员就存成多少个key-value对,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是大量重复用户ID这样的数据,内存浪费还是非常严重的。

然而Redis提供的Hash很好的解决了这个问题,Redis的Hash内部存储的value为一个HashMap,并且可以直接操作这个Map成员方法。

也就是说,Key仍然是用户ID, value是一个Map,这个Map的key是成员的属性名,类似字段,value是属性值,这样对数据的修改和存取都可以直接通过其内部Map的field, 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题,很好的解决了问题。

(3)List

常用命令:lpush,rpush,lpop,rpop,lrange等。

应用场景:

Redis 中list的数据结构实现是双向链表,所以可以非常便捷的应用于消息队列(生产者 / 消费者模型)。消息的生产者只需要通过lpush将消息放入 list,消费者便可以通过rpop取出该消息,并且可以保证消息的有序性。由于 Redis 拥有持久化功能,也不需要担心由于服务器故障导致消息丢失。

(4)Set

常用命令:sadd,spop,smembers,sunion 等。

应用场景:

Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,set还可以判断某个成员是否在一个set集合内的重要方法。还有一个微博用的关注关系,例如:用户 A,将它的关注和粉丝的用户 id 都存放在两个 set 中:

A:follow:存放 A 所有关注的用户 id

A:followed:存放 A 所有粉丝的用户 id

根据A:follow和A:followed的交集得到与 A 互相关注的用户。

(5)Sorted Set

常用命令:zadd,zrange,zrem,zcard等

使用场景:

Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员自动排序。当你需要一个有序的并且不重复的集合列表,那么可以选择sorted set数据结构。常见sorted set和一个计算热度的算法便可以轻松打造一个热度排行榜,zrevrangebyscore可以得到以分数倒序排列的序列,zrank可以得到一个成员在该排行榜的位置(是分数正序排列时的位置,如果要获取倒序排列时的位置需要用zcard-zrank)。

两大特性用途

(1)Pub/Sub

发布(Publish)与订阅(Subscribe),在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如:群聊功能。

(2)Transactions

提供了基本的命令打包执行的功能,比如微博关注之后,除了添加一个关注ID(1315402)之后,还需要让被关注(19028474)的粉丝数量+1.这就可以进行打包进行:

> MULTI

OK

> sadd(19028474, 1315402)

QUEUED

> INCR 19028474

QUEUED

> EXEC

1) (integer) 1

2) (integer) 1

命令是顺序在一起执行的,中间不会有其实命令插进来执行。

其他常见的redis应用

(1)计数器

数据统计的需求非常普遍,通过redis原子操作计数。例如,点赞数、收藏数、分享数等。

(2)排行榜

排行榜按照得分进行排序,例如,展示最近、最热、点击率最高、活跃度最高等各种类型的top list。

(3)好友列表

例如,用户点赞列表、用户收藏列表、用户关注列表等。

(4)缓存

缓存热点数据,这也是redis最典型的应用之一,根据实际情况,缓存用户信息,缓存session等。

(5)存储时间戳

当用户发完微博后,都通过lpush将它存放在一个 key 为LATEST_WEIBO的list中,之后便可以通过lrange取出当前最新的微博,随着时间的变化,新的内容也在不断变化,保证每次用户刷新出来的都是最新最热的。

(6)判断行为

判断用户行为也是非常普遍,可以知道一个用户是否进行了某个操作。例如,用户是否点赞、用户是否收藏、用户是否分享等,来决定下次打开后,相关按钮是否置灰。

亲爱的程序员,了然于心了吗? 是不是瞬间解决了你业务中的诸多问题?

点赞+关注,更多专业内容与你分享