辽宁千山科技做网站怎么样,品牌logo设计图片,wordpress 折叠,服务器不能访问网站介绍一下redis数据库
Redis 是一种基于内存的数据库#xff0c;对数据的读写操作都是在内存中完成#xff0c;因此读写速度非常快#xff0c;常用于缓存#xff0c;消息队列、分布式锁等场景。
Redis 提供了多种数据类型来支持不同的业务场景#xff0c;比如 String(字符…介绍一下redis数据库
Redis 是一种基于内存的数据库对数据的读写操作都是在内存中完成因此读写速度非常快常用于缓存消息队列、分布式锁等场景。
Redis 提供了多种数据类型来支持不同的业务场景比如 String(字符串)、Hash(哈希)、 List (列表)、Set(集合)、Zset(有序集合)、Bitmaps位图、HyperLogLog基数统计、GEO地理信息、Stream流并且对数据类型的操作都是原子性的因为执行命令由单线程负责的不存在并发竞争的问题。
除此之外Redis 还支持事务 、持久化、Lua 脚本、多种集群方案主从复制模式、哨兵模式、切片机群模式、发布/订阅模式内存淘汰机制、过期删除机制等等。
介绍redis的单线程模型 Redis是一个基于内存的高性能键值数据库它的单线程模型是其最大特点之一。单线程模型意味着Redis在一个单独的线程中处理所有的读写请求而其他线程则负责其他的任务比如网络I/O和事件处理。 Redis的单线程模型是通过使用一个单线程的IO线程和多个后台线程来实现的。IO线程负责接收客户端的请求并将请求转发给后台线程。后台线程负责处理所有的命令请求并将结果返回给IO线程。IO线程再将结果返回给客户端。 虽然Redis的单线程模型可以提高性能但也存在一些缺点。例如由于只有一个线程因此在高并发的情况下可能会导致请求处理速度变慢。此外由于Redis是基于内存的因此也可能会存在内存泄漏的问题。 总之Redis使用单线程的IO线程而不是多线程的IO线程这样可以避免线程切换的开销提高性能。此外Redis还使用了阻塞I/O这样可以避免在高并发情况下因没有可用的线程而导致的性能下降。最后Redis还使用了事务机制可以将多个命令请求作为一个原子操作来执行这样可以确保数据的一致性。
为什么redis更快/
因为redis使用单线程网络I/O和 执行命令有几个原因 ·redis基于内存的数据库采用了高效数据结构瓶颈是内存CPU不是瓶颈所以用单线程就能解决。 ·单线程模型避免多线程之间的竞争省去了多线程切换带来的时间和性能上的开销不会有死锁。 ·redis采用I/O多路复用机制处理大量客户端socket请求IO多路复用机制是一个线程处理多个 IO 流就是常听到** select/epoll 机制**。在redis只允许单线程情况下该机制允许内核中同时存在多个监听socket和已连接socket。 内核会监听。一旦有请求就交给redis线程处理这就实现了一个redis处理多个IO流效果。
redis怎么实现持久化
redis读写都在内存中所以redis性能才会高当redis重启后内存中数据会丢失所以需要持久化。存数据文件到磁盘中这样redis重启就能从磁盘中恢复原有数据。 两种数据持久化方式 AOF【Append Only File(追加文件)】日志每执行一条写都会追加到文件中。 RDB【Redis Database Backup file(Redis数据备份文件)】快照某一时刻的内存数据以二进制方式写入磁盘。
redis单线程会不会浪费资源
redis6.0后也采用了多个I/O线程来处理网络模块因为随着网络硬件性能提升Redis的性能瓶颈可能出现在网络I/O处理上。 但只是redis6.0对于网络I/O采用多线程来处理但是对于命令的执行仍用单线程来处理。
redis执行命令是单线程如何利用多核心来提升性能
部署多个 redis docker 容器来处理达到充分利用 cpu 多核心的效果
redis缓存穿透、缓存击穿、缓存雪崩是什么怎么解决
缓存雪崩 当大量缓存数据在同一时间过期或者 Redis 故障宕机时大量用户请求全部访问数据库。同时也会做大量给内存中缓存的操作压力剧增一系列连锁反应导致整个系统崩溃。
· 解决办法
大量数据同时过期时 均匀设置过期时间互斥锁避免大量访问数据库的结果大量去做存内存操作加锁同一时间只有一个请求能写缓存。双key策略使用两个key主key和副key。过期时间备用key不过期。业务主线访问不到主key的缓存数据时直接返回备key的缓存。内存中同时写两份一份过期还有一份后台更新缓存策略后台线程定时更新缓存。 redis故障宕机时 启动服务熔断防止整个系统雪崩暂停业务对缓存服务的访问直接返回错误。或者请求限流只有少量请求发送到数据库中。构建高可靠集群通过主从节点方式构建redis缓存可靠集群。 缓存击穿 缓存中的某个热点数据过期了此时大量的请求访问了该热点数据就无法从缓存中读取直接访问数据库数据库很容易就被高并发的请求冲垮。因为不只是访问都普通数据库而是还会都去写内存。
· 解决办法 互斥锁方案保证同一时间只有一个业务线程更新缓存未能获取互斥锁的请求要么等待锁释放后重新读取缓存要么就返回空值或者默认值。热点数据不设置过期时间临近过期的热点数据重写设置过期时间。 缓存穿透 频繁去请求一个不在内存和数据库中的数据。使得数据库压力剧增。 · 解决办法 非法请求的限制在API入口处判断请求参数是否合理是否是带一些特殊字符或者超区间的访问缓存存空值或默认值不存在的就先存空值或默认值。可以使得不必都去查询数据库。布隆过滤器 布隆过滤器100%确定不存在。 怎么用redis分布式锁
加锁包括了读取锁变量、检查锁变量值和设置锁变量值。 setnx锁变量需要设置过期时间。 setnx的ex/px选项设置过期时间。ex和px区别是粒度不一样。锁变量的值需要能区分是哪个客户端的加锁操作所以最好设置为能唯一标识某个客户端的值这样防止失误地释放。
讲讲redis持久化
redis在内存中如果意外关机或下次重启如何恢复内存中的数据。有两种方式RDB、AOF。
RDB方式 1 概念rdb是快照策略在配置文件中 2底层机制每次存快照会fork一个子进程父进程继续处理请求而子进程去把当前的所有数据 2.1 做保存生成临时rdb文件替换掉之前的rdb文件就成了正是的rdb文件。 2.2 save规则满足的情况下会触发rdb规则。 2.3 执行flushall触发清除整个redis数据缓存命令也会触发rdb规则。 2.4退出redis也会产生rdb文件。 在dump.rdb文件中里面设定了 save 900 1 save 1000 2 意思是每900秒内改1个值就做一次快照。会触发RDB快照。 当配置好后启动后激活rdb操作后在bin下会生成rdb文件。 · RDB的优点 1 适合大规模数据恢复。 2 对数据的完整性要求不高 · RDB的缺点 1 需要一定的时间间隔进行操作。如果redis意外宕机了最后一次修改数据就没有了 2 fork进程时会占用一定内存空间
AOF方式
append only file 默认不开启的需要手动配。操作发现 appendonly.aof中就有了操作记录。 · 机制 父进程fork子进程记录全部写操作。 · AOF文件出错后会导致redis不能重启 redis提供了工具redis -check-aof–fix。
· 缺点 aof远大于rdb修复速度比rdb慢 aof运行效率要比rdb慢redis默认配置是rdb持久化 如果AOF文件大于64m太大了fork新进程来将文件重写。 AOF无限追加必然会越来越大。 rewrite参数在配置中可以看到。
· 建议 RDB只在从机上15分钟备份一次即可。 微博每次启动看哪个从机RDB更新更大就用哪个RDB。
讲讲redis的订阅发布
信息通信模式发送者push订阅者订阅接收。 消息发布者发送消息到队列中而消息订阅者去抢队列中的内容。 关注订阅频道、订阅已经订阅频道的信息、退订、发送到指定频道 操作 先订阅一个频道频道名称。 一个redis端去订阅a频道 subscribe a 而redis-server 服务端维护了一个字典字典的键就是个频道而字典的值是一个链表链表中保存了所有订阅这个频道的客户端。subscribe命令的关键是将客户端添加到给定的channel的订阅链表中。 本质是将客户端添加到管道的链表中。 另外一个去给频道中发布publish a “mess_test” 则在第一个redis端收到了推送过来的。 场景 适合实时消息系统实时聊天系统。
讲讲redis主从复制
· 机制 一台redis服务的数据复制到其它redis服务器前者是主节点后者从节点。 复制的是从机原始是主节点且主机写为主从机读为主。 80%的情况都是在做读操作。减缓服务器压力在架构中经常使用。 · 主从复制的主要作用 数据冗余 故障恢复 负载均衡 高可用基石:一般至少一主二从。
配置方式 把redis.conf配置几份不同端口配置到不同conf文件中。 改端口pid名字日志名字备份文件dump.rdb名依次修改后分别启动使用。
一主二从 默认情况下每一台都是主节点而配置完后才有主从节点。 只需要在从机中配置即可。 在从机中执行slaveof 127.0.0.1 6379 让从机寻找某个端口做主机 主机中可以查看从机信息info replication 配置好后从节点不能写。 全量复制 从机第一次连接到主机时就会全部复制一遍。 增量复制 后面增加的内容
宕机后配置 当主节点宕机后如何从节点做替补设置 slaveof no one使自己成为主节点 之后主机恢复也没有用了只能重新配置。 如果把这些写到配置文件中每次改得比较麻烦。 而当不写配置文件反而执行命令就能达到想要的效果。
哨兵模式自动选取主机节点的模式
自动版的自动选举主机的模式 哨兵也需要多个哨兵之间也互相监督且哨兵也监督各个节点 故障转移操作 投票的结果由一个哨兵发布然后通过发布订阅模式让哨兵把自己监控的从服务器实现切换主机这个过程称为客观下线。
操作 各个主机上配置vim sentinel.conf 一串配置最后的1是说主机挂掉做投票让某个节点去做主机
启动哨兵模式 redis-sentinel sentinel.conf 当主机没了就发生故障转移。 如果master节点断开此时就会从从机中随机选择服务器。这里有投票算法。 哨兵日志 当主机恢复后也只能是从机。 ·哨兵模式的优点 基于主从模式自动化 主从可以切换故障转移系统可用性更好 · 哨兵模式的缺点 redis不好做在线扩容数量一旦上限在线扩容就很麻烦。 实现哨兵模式配置很麻烦里面有很多选择。 还有哨兵集群。
