北京朝阳区建设工作办公网站,东莞网站建设曼哈顿信科,网站营销推广有哪些,手表到哪个网站买简单来说 redis 就是一个数据库#xff0c;不过与传统数据库不同的是 redis 的数据是存在内存中的#xff0c;所以读写速度非常快#xff0c;因此 redis 被广泛应用于缓存方向。另外#xff0c;redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。…简单来说 redis 就是一个数据库不过与传统数据库不同的是 redis 的数据是存在内存中的所以读写速度非常快因此 redis 被广泛应用于缓存方向。另外redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
一、为什么要用 redis/为什么要用缓存
主要从“高性能”和“高并发”这两点来看待这个问题。
高性能
假如用户第一次访问数据库中的某些数据。这个过程会比较慢因为是从硬盘上读取的。将该用户访问的数据存在数缓存中这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存所以速度相当快。如果数据库中的对应数据改变的之后同步改变缓存中相应的数据即可 高并发
直接操作缓存能够承受的请求是远远大于直接访问数据库的所以我们可以考虑把数据库中的部分数据转移到缓存中去这样用户的一部分请求会直接到缓存这里而不用经过数据库。 二、为什么要用 redis 而不用 map/guava 做缓存? 下面的内容来自 segmentfault 一位网友的提问地址为什么要用redis而不用map做缓存? - SegmentFault 思否 缓存分为本地缓存和分布式缓存。以 Java 为例使用自带的 map 或者 guava 实现的是本地缓存最主要的特点是轻量以及快速生命周期随着 jvm 的销毁而结束并且在多实例的情况下每个实例都需要各自保存一份缓存缓存不具有一致性。
使用 redis 或 memcached 之类的称为分布式缓存在多实例的情况下各实例共用一份缓存数据缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用整个程序架构上较为复杂。
三、redis 和 memcached 的区别
对于 redis 和 memcached 我总结了下面四点。现在公司一般都是用 redis 来实现缓存而且 redis 自身也越来越强大了 redis支持更丰富的数据类型支持更复杂的应用场景Redis不仅仅支持简单的k/v类型的数据同时还提供listsetzsethash等数据结构的存储。memcache支持简单的数据类型String。 Redis支持数据的持久化可以将内存中的数据保持在磁盘中重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。 集群模式memcached没有原生的集群模式需要依靠客户端来实现往集群中分片写入数据但是 redis 目前是原生支持 cluster 模式的. Memcached是多线程非阻塞IO复用的网络模型Redis使用单线程的多路 IO 复用模型。 来自网络上的一张图这里分享给大家 四、redis 常见数据结构以及使用场景分析
1.String 常用命令: set,get,decr,incr,mget 等。 String数据结构是简单的key-value类型value其实不仅可以是String也可以是数字。 常规key-value缓存应用 常规计数微博数粉丝数等。
2.Hash 常用命令 hget,hset,hgetall 等。 hash 是一个 string 类型的 field 和 value 的映射表hash 特别适合用于存储对象后续操作的时候你可以直接仅仅修改这个对象中的某个字段的值。 比如我们可以 hash 数据结构来存储用户信息商品信息等等。比如下面我就用 hash 类型存放了我本人的一些信息
keyJavaUser293847
value{
“id”: 1,
“name”: “SnailClimb”,
“age”: 22,
“location”: “Wuhan, Hubei”
}
3.List 常用命令: lpush,rpush,lpop,rpop,lrange等 list 就是链表Redis list 的应用场景非常多也是Redis最重要的数据结构之一比如微博的关注列表粉丝列表消息列表等功能都可以用Redis的 list 结构来实现。
Redis list 的实现为一个双向链表即可以支持反向查找和遍历更方便操作不过带来了部分额外的内存开销。
另外可以通过 lrange 命令就是从某个元素开始读取多少个元素可以基于 list 实现分页查询这个很棒的一个功能基于 redis 实现简单的高性能分页可以做类似微博那种下拉不断分页的东西一页一页的往下走性能高。
4.Set 常用命令 sadd,spop,smembers,sunion 等 set 对外提供的功能与list类似是一个列表的功能特殊之处在于 set 是可以自动排重的。
当你需要存储一个列表数据又不希望出现重复数据时set是一个很好的选择并且set提供了判断某个成员是否在一个set集合内的重要接口这个也是list所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。
比如在微博应用中可以将一个用户所有的关注人存在一个集合中将其所有粉丝存在一个集合。Redis可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程具体命令如下
sinterstore key1 key2 key3 将交集存在key1内
5.Sorted Set 常用命令 zadd,zrange,zrem,zcard等 和set相比sorted set增加了一个权重参数score使得集合中的元素能够按score进行有序排列。
举例 在直播系统中实时排行信息包含直播间在线用户列表各种礼物排行榜弹幕消息可以理解为按消息维度的消息排行榜等信息适合使用 Redis 中的 Sorted Set 结构进行存储。
五、redis 设置过期时间
Redis中有个设置时间过期的功能即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库这是非常实用的。如我们一般项目中的 token 或者一些登录信息尤其是短信验证码都是有时间限制的按照传统的数据库处理方式一般都是自己判断过期这样无疑会严重影响项目性能。
我们 set key 的时候都可以给一个 expire time就是过期时间通过过期时间我们可以指定这个 key 可以存活的时间。
如果假设你设置了一批 key 只能存活1个小时那么接下来1小时后redis是怎么对这批key进行删除的
定期删除惰性删除。
通过名字大概就能猜出这两个删除方式的意思了。 定期删除redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key检查其是否过期如果过期就删除。注意这里是随机抽取的。为什么要随机呢你想一想假如 redis 存了几十万个 key 每隔100ms就遍历所有的设置过期时间的 key 的话就会给 CPU 带来很大的负载 惰性删除 定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key靠定期删除没有被删除掉还停留在内存里除非你的系统去查一下那个 key才会被redis给删除掉。这就是所谓的惰性删除也是够懒的哈
但是仅仅通过设置过期时间还是有问题的。我们想一下如果定期删除漏掉了很多过期 key然后你也没及时去查也就没走惰性删除此时会怎么样如果大量过期key堆积在内存里导致redis内存块耗尽了。怎么解决这个问题呢 redis 内存淘汰机制。
六、redis 内存淘汰机制(MySQL里有2000w数据Redis中只存20w的数据如何保证Redis中的数据都是热点数据?)
redis 配置文件 redis.conf 中有相关注释我这里就不贴了大家可以自行查阅或者通过这个网址查看 http://download.redis.io/redis-stable/redis.conf
redis 提供 6种数据淘汰策略 volatile-lru从已设置过期时间的数据集server.db[i].expires中挑选最近最少使用的数据淘汰 volatile-ttl从已设置过期时间的数据集server.db[i].expires中挑选将要过期的数据淘汰 volatile-random从已设置过期时间的数据集server.db[i].expires中任意选择数据淘汰 allkeys-lru当内存不足以容纳新写入数据时在键空间中移除最近最少使用的key这个是最常用的 allkeys-random从数据集server.db[i].dict中任意选择数据淘汰 no-eviction禁止驱逐数据也就是说当内存不足以容纳新写入数据时新写入操作会报错。这个应该没人使用吧
备注 关于 redis 设置过期时间以及内存淘汰机制我这里只是简单的总结一下后面会专门写一篇文章来总结
七、redis 持久化机制(怎么保证 redis 挂掉之后再重启数据可以进行恢复)
很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面大部分原因是为了之后重用数据比如重启机器、机器故障之后恢复数据或者是为了防止系统故障而将数据备份到一个远程位置。
Redis不同于Memcached的很重一点就是Redis支持持久化而且支持两种不同的持久化操作。
Redis的一种持久化方式叫快照snapshottingRDB另一种方式是只追加文件append-only file,AOF。这两种方法各有千秋下面我会详细这两种持久化方法是什么怎么用如何选择适合自己的持久化方法。
快照snapshotting持久化RDB
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后可以对快照进行备份可以将快照复制到其他服务器从而创建具有相同数据的服务器副本Redis主从结构主要用来提高Redis性能还可以将快照留在原地以便重启服务器的时候使用。
快照持久化是Redis默认采用的持久化方式在redis.conf配置文件中默认有此下配置 save 900 1 #在900秒(15分钟)之后如果至少有1个key发生变化Redis就会自动触发BGSAVE命令创建快照。 save 300 10 #在300秒(5分钟)之后如果至少有10个key发生变化Redis就会自动触发BGSAVE命令创建快照。 save 60 10000 #在60秒(1分钟)之后如果至少有10000个key发生变化Redis就会自动触发BGSAVE命令创建快照。
AOFappend-only file持久化
与快照持久化相比AOF持久化 的实时性更好因此已成为主流的持久化方案。默认情况下Redis没有开启AOFappend only file方式的持久化可以通过appendonly参数开启
appendonly yes
开启AOF持久化后每执行一条会更改Redis中的数据的命令Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同都是通过dir参数设置的默认的文件名是appendonly.aof。
在Redis的配置文件中存在三种不同的 AOF 持久化方式它们分别是
appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec #每秒钟同步一次显示地将多个写命令同步到硬盘
appendfsync no #让操作系统决定何时进行同步
为了兼顾数据和写入性能用户可以考虑 appendfsync everysec选项 让Redis每秒同步一次AOF文件Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
Redis 4.0 对于持久化机制的优化
Redis 4.0 开始支持 RDB 和 AOF 的混合持久化默认关闭可以通过配置项 aof-use-rdb-preamble 开启。
如果把混合持久化打开AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的 AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式可读性较差。
补充内容AOF 重写
AOF重写可以产生一个新的AOF文件这个新的AOF文件和原有的AOF文件所保存的数据库状态一样但体积更小。
AOF重写是一个有歧义的名字该功能是通过读取数据库中的键值对来实现的程序无须对现有AOF文件进行任何读入、分析或者写入操作。
在执行 BGREWRITEAOF 命令时Redis 服务器会维护一个 AOF 重写缓冲区该缓冲区会在子进程创建新AOF文件期间记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾使得新旧两个AOF文件所保存的数据库状态一致。最后服务器用新的AOF文件替换旧的AOF文件以此来完成AOF文件重写操作
更多内容可以查看我的这篇文章 Redis持久化
八、redis 事务
Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包然后一次性、按顺序地执行多个命令的机制并且在事务执行期间服务器不会中断事务而改去执行其他客户端的命令请求它会将事务中的所有命令都执行完毕然后才去处理其他客户端的命令请求。
在传统的关系式数据库中常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中事务总是具有原子性Atomicity、一致性Consistency和隔离性Isolation并且当 Redis 运行在某种特定的持久化模式下时事务也具有持久性Durability。
九、缓存雪崩和缓存穿透问题解决方案
缓存雪崩
简介缓存同一时间大面积的失效所以后面的请求都会落到数据库上造成数据库短时间内承受大量请求而崩掉。
解决办法 事前尽量保证整个 redis 集群的高可用性发现机器宕机尽快补上。选择合适的内存淘汰策略。 事中本地ehcache缓存 hystrix限流降级避免MySQL崩掉 事后利用 redis 持久化机制保存的数据尽快恢复缓存 缓存穿透
简介一般是黑客故意去请求缓存中不存在的数据导致所有的请求都落到数据库上造成数据库短时间内承受大量请求而崩掉。
解决办法 有很多种方法可以有效地解决缓存穿透问题最常见的则是采用布隆过滤器将所有可能存在的数据哈希到一个足够大的bitmap中一个一定不存在的数据会被 这个bitmap拦截掉从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法我们采用的就是这种如果一个查询返回的数据为空不管是数 据不存在还是系统故障我们仍然把这个空结果进行缓存但它的过期时间会很短最长不超过五分钟。
参考 缓存穿透缓存击穿缓存雪崩解决方案分析_缓存血崩_zeb_perfect的博客-CSDN博客
十、如何解决 Redis 的并发竞争 Key 问题
所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作但是最后执行的顺序和我们期望的顺序不同这样也就导致了结果的不同
推荐一种方案分布式锁zookeeper 和 redis 都可以实现分布式锁。如果不存在 Redis 的并发竞争 Key 问题不要使用分布式锁这样会影响性能
基于zookeeper临时有序节点可以实现的分布式锁。大致思想为每个客户端对某个方法加锁时在zookeeper上的与该方法对应的指定节点的目录下生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单只需要判断有序节点中序号最小的一个。 当释放锁的时候只需将这个瞬时节点删除即可。同时其可以避免服务宕机导致的锁无法释放而产生的死锁问题。完成业务流程后删除对应的子节点释放锁。
在实践中当然是从以可靠性为主。所以首推Zookeeper。
参考 https://www.jianshu.com/p/8bddd381de06
十一、如何保证缓存与数据库双写时的数据一致性?
你只要用缓存就可能会涉及到缓存与数据库双存储双写你只要是双写就一定会有数据一致性的问题那么你如何解决一致性问题
一般来说就是如果你的系统不是严格要求缓存数据库必须一致性的话缓存可以稍微的跟数据库偶尔有不一致的情况最好不要做这个方案读请求和写请求串行化串到一个内存队列里去这样就可以保证一定不会出现不一致的情况
串行化之后就会导致系统的吞吐量会大幅度的降低用比正常情况下多几倍的机器去支撑线上的一个请求。
参考 redis设计与实现(第二版)
