redis
2020-09-03 13:50:47 0 举报
登录查看完整内容
为你推荐
查看更多
redis的详细操作
作者其他创作
大纲/内容
1 mutli
Redis的订阅
spop取出一个
2 exec
弱一致性丢失数据
redis sort set
rediszset
根据业务拆分（根据业务将不同的业务需求的值存储在不同的主机中）
redis同时开启了AOF和RDB的操作的话，默认是按照AOF恢复数据
set
类似于java中的缓存流，后面一起刷到硬盘中。对文件的操作，内核对磁盘会有个buffer
redis从
通过AKF 一变多数据一致性所有的节点都是全部一致的，阻塞的，等到同步完成之后再提供服务。强一致性！破坏可用性！反问自己：为什么一变多？使用强一致性的意义？解决可用性：1、异步2、容忍数据可能丢失
piepine
手动命令：bgrewriteaof自动执行：auto-aof-rewrite-min-size（数据文件达到一定程度大小）
rdb数据
代理层逻辑实现
其实只看命令的话就是比set多出一个z还多了一些对权重的排序
这个半区 的数据
redis 37、8、9、0
3
不能做数据库使用预分区
proxy请求转发nginx
sentinel
redis 3
sub
1
从redis
同步阻塞
对数据的敏感性：配置：no-Appendsync-on-write-no子进程rdb到磁盘的时候，主进程的buffer不会刷新到磁盘(容易丢数据)
数组
redis-server
redis
新增：是个过程先将9、0的卡槽位传输过去，然后在本地维护队列。直至所有的数据完全传输，去除卡槽位，转移 9、0
redis -cli
写入数据库
pub
抵消命令，因为会有很多的无效命令，直接抵消。
如果redis 开启了10年，挂了。恢复数据可不可能有10T？ --可能，AOF只会追加指令恢复会不会内存溢出？ --不会，和以前一样恢复5年 ？ --可能
redis 24、5、6
redis-cli
这里的话，1 2 都开启了事务，但是不同时间的到达对于redis来说先提交的那个整体先执行，也就是2执行完了才会去执行1
可以直接的增加，高峰时期可以减少对数据库的操作
思考
db
node2
a:5
重写
1 get
mapping4、5、6
内存是有限的，所以需要设置对冷数据回收策略
子进程
哨兵模式
a:3
redis-cliprop
提高速度，将数据写到buffer
redis -cli取 相邻的2个节点的数据
非阻塞：一遍继续提供服务一边持久化
队列：反向命令
kafka
思考：缺点
kaeepalived
强一致性破坏可用性
最终：AOF是一个混合体，既有RDB的二进制，还有AOF的指令追加
hash值
字符串
hash环
需要人工的维护主redis故障
redis 11、2、3
使用linux的时候：父子进程父进程的数据子进程是否能看的到？常规思想：linux的进程是隔离的进阶思想：父进程的数据子进程是可以看到的子进程修改数据不会影响到父进程的数据父进程数据的修改也不会影响到子进程子进程会和父进程绑定关系，父进程结束，子进程也是
元素，数值，权重还可以根据数字计算权重
异步
思考：如果是还未同步的话，cli去取数据，读取出来的很有可能就是脏数据解决：可以使用强一致型
RDB快照的形式进行全量的存储
redis-server(1)
redis的集群
将老的数据以RDB的形式存储，然后将指令以AOF的形式追加
代表着单节点实例解决问题：单点故障
set k1 a
数据分类，交集不多
写的过程
发布订阅
map
2 watch
解决方案
写入缓存降低压力
可以自己手动修改aof文件。注意不能触发重写机制
默认是无过期时间没有延长时间的概念的
为了解决新增节点带来的问题
hash 10%
ooxxlist
按照物理内存的大小从左向右排序不随命令发生变化。都是自己设置自己的权重，可以根据权重来取值
最终：是一个纯指令的文件
redismaster
rdb
因为丢失数据的问题，引发的另个持久化
client
数据无法拆分
新增
redis的过期时间
node1
8：00 ----8：30持久化但是持久化的数据就是8：00的数据
byte
AOF
2 mutli
磁盘IO
如果是想回退历史版本的话怎么办？
单机、单节点、单实例带来的问题：1、单点故障2、容量有限3、压力
redis-server(2)
SRANDMEMBER KEY COUNT正数：取出一个去重的结果集（不会超过原有的数）负数：取出的是带重复的结果集（设置多少取出多少)0：不返回
redis 24、 5 、6
mapping9、0
key的写操作
redis 2
linux的一种机制
clientproxy代理算法按照模去取值 （10）1、2、3、4、5、6、7、8、9、0
多节点的解决方案
排序是如何实现快速的增删？
AKF坐标系：A：镜像、多个实例可以做读写分离K：多个节点根据业务拆分请求，可以降低服务器的压力F：融合一起，达到完美的应用
不用的话，就是单个命令的单个执行，这个队列的话，就是多个命令可以一起去执行
RDBAOF
这个半区的数据
Redis的队列
redis4.0之前和4.0之后
Redis的事务
list
有save（阻塞）bsave（非阻塞）
更老的数据
但是我们通过一个方案解决一个问题的时候，通常会带来另个问题
map中的value 也是可以数字，有独立的进行增加的方法
2 delete
offset
redis cluster的做法
集合的交集、并集
增加节点
AKF机制：A：全量、镜像K：业务、功能F：优先级、逻辑的再拆分
直接通过网络发送数据
具体的代理的实现
sort set
redis的连接成本很高
优点：增加节点可以降低压力，并不会引起数据的重新洗牌缺点：新增节点的话，就会导致一些数据不能够命中问题：1、数据击穿到数据库2、 只能用作缓存，不能用做数据库
管道：前一个命令的【结果】就是下一个线程的【输入】管道的话就会触发创建【子进程】
栈：同向命令
mapping7、8、9、0
fork（）【系统调用】速度快空间小
对于redis来说，如果全量数据比较大的话，存储的时间会比较长，中间又有修改的话，redis是怎么准确的存储数据的？
集合操作相当的多
hash算法
mapping1、2、3
丢失数据少
弊端取模的值必须固定：10%20%影响分布式的扩展性
lvs
redis的持久化
算法hash取模modula
配置：appendAsyc : NOappendasyc : awayappendasyc : everysec
每一个服务端都会记录其他的服务端的信息：当请求来的时候，会去计算在哪一个redis中。如果不在这边就返回那一台机。直接切换到那台主机的实例连接
最终一致性
重新指向
b：4
新增节点
主从复制
redis的数据回收
node3
2
取数据
a:4
3天之内
将redsi的写操作写到文件中
历史
回收策略
单进程
数字
逻辑：kemata数据一致性算法一致性hash没有取模date node
代表着节点解决问题：1、容量2、压力（每个请求分配到不同的服务器中）
无序随机性去重放入多少的不同取出的顺序不同
1 exec
c：5
随机事件
lvs客户端不用关心后面的实现
redis：单机单进程缓存数据库
String/byte
skip跳跃链表
举例解决：项目中的日志，分成多个文件
无主模型
阻塞队列FIFO
能具体对bit进行操作，但后统计，这里是可以用来记录登录的情况
优弊端：体量大，无线增长恢复数据慢
AOF的数据丢失的大小
维护小的队列
内存
网络IO
逻辑randomlpush
service
创建子进程的速度要达到什么的程度？速度内存
规则一个hash环
redis
主进程
对filed进行计算场景：点赞，收藏，详情页
copyOnWrite机制写时复制创建子进程的时候不发生复制节省空间本身也是不可能把所有的数据都复制
歌曲的排行榜
当在hash环上新增节点的时候，本来这部分的数据是在 node2 上面的，但是现在的位置是在新增的 node3上面，所以可能会导致在查询的时候在node2 上面查不到
redis 1
通用的解决方案
弊端：不支持拉链，只有一个文件 dump.rdb数据丢失的可能性大类似java序列化二进制的形式存储，恢复比较快
消息队列ooxx：topic/kafka
代理：twpredixyclustercodis(修改原代码）
同步阻塞（快）
redis过期判断逻辑1、被动的访问判定2、周期轮询判定（增量）目的就是牺牲少量的内存，但是可以保证redis的速度
A：带来的问题
实时的
watch的概念，就是监控某个key值，如果被修改了，那么这个不执行
kafka（类型）要求：1、可靠2、集群3、响应速度快
写操作后
主redis
0 条评论
回复 删除
下一页
