分布式-分布式缓存Redis

一、Redis常用五大数据类型

1.1 String(字符串)

  • string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
  • string类型是Redis最基本的数据类型,一个redis中字符串value最多可以是512M

1.2 Hash(哈希)

  • Redis hash 是一个键值对集合。

  • Redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象,例如用户的信息对象,用户id作为key,具体信息作为value

  • 类似Java里面的Map

1.33 List(列表)

  • list类型是双向链表结构
    如在微博中的我关注的列表或者论坛中所有回帖用户的id等等数据,同时list也能实现简单的消息队列,具体可以先用rpush把消息放入到队列尾部,再用lpop把消息从队列头部取出

1.4 Set(集合)

  • set类型是一种无序类型,在redis内部是通过 HashTable实现,查找和删除元素十分快速
    可以用于记录一些不能重复的数据,例如每次注册的时候将用户名存起来,每次新的用户注册的时候,都可以先set查询该用户名是否被注册,效率极高,还有一种比较广泛的应用就是投票系统,比如一天用户只能投票一次,我们就可以使用今天的日期作为set的key,存取用户的投票行为,查询的时候也用日期查询

1.5 zset(sorted set:有序集合)

  • Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
  • 不同的是每个元素都会关联一个double类型的分数。
    redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。

二、redis应用场景

2.1 缓存——热数据

热点数据(经常会被查询,但是不经常被修改或者删除的数据),首选是使用redis缓存,毕竟强大到冒泡的QPS和极强的稳定性不是所有类似工具都有的,而且相比于memcached还提供了丰富的数据类型可以使用,另外,内存中的数据也提供了AOF和RDB等持久化机制可以选择,要冷、热的还是忽冷忽热的都可选。

结合具体应用需要注意一下:很多人用spring的AOP来构建redis缓存的自动生产和清除,过程可能如下:

  • Select 数据库前查询redis,有的话使用redis数据,放弃select 数据库,没有的话,select 数据库,然后将数据插入redis
  • update或者delete数据库钱,查询redis是否存在该数据,存在的话先删除redis中数据,然后再update或者delete数据库中的数据

上面这种操作,如果并发量很小的情况下基本没问题,但是高并发的情况请注意下面场景:

为了update先删掉了redis中的该数据,这时候另一个线程执行查询,发现redis中没有,瞬间执行了查询SQL,并且插入到redis中一条数据,回到刚才那个update语句,这个悲催的线程压根不知道刚才那个该死的select线程犯了一个弥天大错!于是这个redis中的错误数据就永远的存在了下去,直到下一个update或者delete。

2.2 计数器

诸如统计点击数等应用。由于单线程,可以避免并发问题,保证不会出错,而且100%毫秒级性能!爽。

命令:INCRBY

当然爽完了,别忘记持久化,毕竟是redis只是存了内存!

2.3 队列

相当于消息系统,ActiveMQ,RocketMQ等工具类似,但是个人觉得简单用一下还行,如果对于数据一致性要求高的话还是用RocketMQ等专业系统。

由于redis把数据添加到队列是返回添加元素在队列的第几位,所以可以做判断用户是第几个访问这种业务

队列不仅可以把并发请求变成串行,并且还可以做队列或者栈使用

2.4 位操作(大数据处理)

用于数据量上亿的场景下,例如几亿用户系统的签到,去重登录次数统计,某用户是否在线状态等等。

想想一下腾讯10亿用户,要几个毫秒内查询到某个用户是否在线,你能怎么做?千万别说给每个用户建立一个key,然后挨个记(你可以算一下需要的内存会很恐怖,而且这种类似的需求很多,腾讯光这个得多花多少钱。。)好吧。这里要用到位操作——使用setbit、getbit、bitcount命令。

原理是:

redis内构建一个足够长的数组,每个数组元素只能是0和1两个值,然后这个数组的下标index用来表示我们上面例子里面的用户id(必须是数字哈),那么很显然,这个几亿长的大数组就能通过下标和元素值(0和1)来构建一个记忆系统,上面我说的几个场景也就能够实现。用到的命令是:setbit、getbit、bitcount

2.5 分布式锁与单线程机制

redis单线程

redis单线程指的是网络请求模块使用了一个线程(所以不需考虑并发安全性),即一个线程处理所有网络请求,其他模块仍用了多个线程。

为什么说redis能够快速执行

  • (1) 绝大部分请求是纯粹的内存操作(非常快速)

  • (2) 采用单线程,避免了不必要的上下文切换和竞争条件

  • (3) 非阻塞IO - IO多路复用

redis的内部实现

内部实现采用epoll,采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件,然后利用epoll的多路复用特性,绝不在io上浪费一点时间 这3个条件不是相互独立的,特别是第一条,如果请求都是耗时的,采用单线程吞吐量及性能可想而知了。应该说redis为特殊的场景选择了合适的技术方案。

Redis关于线程安全问题
redis实际上是采用了线程封闭的观念,把任务封闭在一个线程,自然避免了线程安全问题,不过对于需要依赖多个redis操作的复合操作来说,依然需要锁,而且有可能是分布式锁。

验证前端的重复请求(可以自由扩展类似情况),可以通过redis进行过滤:每次请求将request Ip、参数、接口等hash作为key存储redis(幂等性请求),设置多长时间有效期,然后下次请求过来的时候先在redis中检索有没有这个key,进而验证是不是一定时间内过来的重复提交

秒杀系统,基于redis是单线程特征,防止出现数据库“爆破”

单线程指的是网络请求模块使用了一个线程(所以不需考虑并发安全性),即一个线程处理所有网络请求,其他模块仍用了多个线程。
https://blog.csdn.net/bird73/article/details/79792548

全局增量ID生成,类似“秒杀”

redis分布锁缺陷

现有的实现在集群上表现不好

原因
官方推荐的实现有三个特性
一,互斥,任何时候只能有一个客户端获得锁
二,可用,无死锁,只要等待下去最终都能获得锁
三,容错

2.6 最新列表

例如新闻列表页面最新的新闻列表,如果总数量很大的情况下,尽量不要使用select a from A limit 10这种low货,尝试redis的 LPUSH命令构建List,一个个顺序都塞进去就可以啦。不过万一内存清掉了咋办?也简单,查询不到存储key的话,用mysql查询并且初始化一个List到redis中就好了。

2.7 排行榜

谁得分高谁排名往上。命令:ZADD(有续集,sorted set)

最近在研究股票,发现量化交易是个非常好的办法,通过臆想出来规律,用程序对历史数据进行验证,来判断这个臆想出来的规律是否有效,这玩意真牛!有没有哪位玩这个的给我留个言,交流一下呗。

三、redis使用规范

3.1 键值规范设计

阿里云Redis开发规范

3.1.1 key名设计

(1)【建议】: 可读性和可管理性
以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:idugc:video:1

**(2)【建议】:简洁性
保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视
例如:user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}。

(3)【强制】:不要包含特殊字符
反例:包含空格、换行、单双引号以及其他转义字符

3.1.2 value设计

【强制】:拒绝bigkey(防止网卡流量、慢查询)
string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。

反例:一个包含200万个元素的list。

非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞,而且该操作不会不出现在慢查询中(latency可查)),查找方法和删除方法

【推荐】:选择适合的数据类型。

反例:

set user:1:name tom
set user:1:age 19
set user:1:favor football

正例:

hmset user:1 name tom age 19 favor football

3.2 设置超时时间[最重要]

控制key的生命周期,redis不是垃圾桶。
建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期),不过期的数据重点关注idletime。

  • 目前有许多key没有设置超时时间,导致一直占用内存。
  • 需要增加操作步骤,设置超时时间。时间尽量短。
  • 某些业务要求key长期有效。

可以在每次写入时,都设置超时时间,让超时时间顺延。(比如token/session机制 授权通过每调用一次口,授权时间增加30m)

  • 短的超时时间,如 5分钟,10分钟,30分钟,1小时,3小时,1天等
  • 长的超时时间,如 7天,15天,1个月,3个月,6个月等
  • 示例代码如下:
    • 设置有效期初始设置有效期
    • 如果存在key,设置有效期

3.3 高频和低频分离

  • 高频数据存入Redis缓存,低频数据不要存入Redis缓存。
    高频数据是经常访问的数据,在这里做好压力缓冲就行了。对于大量数据和列表数据尤其适用。如,某商店的所有评价数据,总共有5000条之多,最近的30条(高频)可能是最常访问的,可以存入Redis缓存,其他的数据(低频)都不需要存缓存。

3.4 合理使用数据类型

  • 结合具体业务,设置合理的数据结构,找出更好的选择。
  • 集合结构还可以减少key的个数。

例如:实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist,但也要注意节省内存和性能之间的平衡)

3.5 尽量使用字符串格式

  • 可视化,便于查看和管理。
  • 特别是在大批量数据的时候,效果明显。

3.5 合理设置key的格式

  • 多系统在共用缓存,需要key唯一。
  • 合适的key,便于查看,统计,排错。
  • key的格式,如:系统名+业务名+业务数据+其他

3.7 减少key的个数

  • 为了过期管理,合理减少key。
    比如,把key-value数据聚合,放到map、list里面。一个集合结构里面就可以包含很多个小数据。

3.8 精细化运营

之前的使用方法一直是粗放式。业务量小时,没问题;业务量大了,就各种问题。为了未来系统稳定,为了每个人的职业成长,需要学会精细化运营。深入分析业务流程,合理安排数据结构,合理使用公共资源,优化读写效率,提高系统抗风险能力。

四、redis和memcached的区别

使用Redis有哪些好处

  • (1) 速度快,因为数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1)

  • (2) 支持丰富数据类型,支持string,list,set,sorted set,hash

  • (3) 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行

  • (4) 丰富的特性:可用于缓存,消息,按key设置过期时间,过期后将会自动删除

观点一

  • 1、Redis和Memcache都是将数据存放在内存中,都是内存数据库。不过memcache还可用于缓存其他东西,例如图片、视频等等;
  • 2、Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,hash等数据结构的存储;
  • 3、虚拟内存–Redis当物理内存用完时,可以将一些很久没用到的value 交换到磁盘;
  • 4、过期策略–memcache在set时就指定,例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定,例如expire name 10;
  • 5、分布式–设定memcache集群,利用magent做一主多从;redis可以做一主多从。都可以一主一从;
  • 6、存储数据安全–memcache挂掉后,数据没了;redis可以定期保存到磁盘(持久化);
  • 7、灾难恢复–memcache挂掉后,数据不可恢复; redis数据丢失后可以通过aof恢复;
  • 8、Redis支持数据的备份,即master-slave模式的数据备份;

猜你喜欢

转载自blog.csdn.net/hardworking0323/article/details/81503906