首页  思维导图  详情



 



Redis开发与运维

2018-05-04 00:29:35   152  举报





AI智能生成

《Redis 开发与运维》读书笔记

Redis

模板推荐

作者其他创作

大纲/内容

键的管理

单个键管理

键重命名

rename key newKey

随机返回键

randomkey

键过期

exipre key seconds

取消键过期

persist key

键迁移

move key db

实例内部db间迁移

migrate

实例间迁移

遍历键

keys pattern

性能损耗较大，阻塞请求。

渐进式遍历

scan，类似与分页扫描

数据库操作

切换数据库 select dbindex

不建议一个实例中多个db，由于实例中是单线程的，db间是互相影响的

清空数据库

flushdb/flushall

客户端使用

主要讲解redis通信协议以及客户端的使用（链接池）和客户端问题定位的案例

总结：Redis的协议RESP协议比较简单，因此对我们实现一个简单代理是可行的（本地调试需要）。

参考文章

https://blog.csdn.net/mawming/article/details/52171116

Resis 噩梦：阻塞

如何定位

slowlog get 发现满查询

bigkeys 发现大对象

内在原因

API或数据结构使用不合理

CPU饱和

-- stat 看redis 统计，如果6w+ OPS 说明确实到极限

info commandstats看命令的耗时，如果吞吐量不大，CPU高，则分析是否是数据结构的问题。

持久化阻塞

fork 会阻塞足线程，info stats查看 lastest_fock_usec

AOF刷盘会阻塞线程，内存缓存到磁盘的同步策略要对

HugePage linux 配置优化问题

外在因素

CPU竞争

排除其他进程占用CPU的可能

CPU 绑定，开启了持久化的Redis不要绑定CPU，因为子进程会和父进程竞争一个CPU

SWAP

保证内存够大、合理设置maxmemory

网络问题

网络延迟，通过 latency 查看延迟统计

尽量使用链接池方式

链接溢出，考虑文件句柄限制、backlog队列溢出

数据类型

字符串

最大值512M

内部编码：int，embstr，raw

8个字节的长整形为int、小于等于39个字节的字符串为embstr、大于39的字符串为raw

应用场景

缓存

计数

共享session

哈希

内部编码

ziplist

节省内存

元素个数小于hash-max-ziplist-entries（512个）

所有值小于hash-max-ziplist-value （64字节）

hashtable

读写O（1）

使用场景

以缓存用户信息为例

原生字符串类型，每个属性一个键

优点

简单直观，每个属性都支持独立更新

缺点

占用过多的键，内存占用大，用户信息内聚性差，通常不推荐使用

序列化字符串型

优点

简化编程，提高内存使用率

缺点

序列化与发序列化会有性能开销，同时每次更新属性都必须全部数据的读取。

哈希类型

优点

简单直观，合理使用情况下可以减少内存空间的使用

缺点

要注意控制ziplist与hashtable的类型转换，hashtable会消耗更多的内存

列表

最大元素个数2的23次方-1

反向关系链可存储

内部编码

ziplist

当元素个数小于 list-max-ziplist-entries 默认512

当每一个元素值都小于 list-max-ziplist-value 默认64字节

linkedlist

https://blog.csdn.net/fengfengdiandia/article/details/52097146

quicklist

redis3.2 优化

使用场景

消息队列

列表存储

例如报名关系，用户最近观看记录等，但是hgetall、lrange性能都要考虑

栈、队列的数据结构

集合

最大元素个数2的23次方-1

lrange、hgetall、smembers都是比较重的操作，考虑使用sscan命令

内部编码

intset

元素都是整数且元素个数小于set-max-intset-entries 默认512

hashtable

使用场景

用户关注类目

类目交集、找相关度

生成随机数，抽奖--srandmember

有序集合

内部编码

ziplist 

元素个数小于zset-max-ziplist-rentires 默认128个

每个元素值都小于zset-max-ziplist-value 默认64字节

skiplist

原理解析：https://blog.csdn.net/fengfengdiandia/article/details/52097146

使用场景

排行榜

上课时常、积分排行

常用技巧

慢查询分析

showlog-log-slower-than、showlog-max-len

showlog get [n]

Redis Shell 工具

redis-cli

--latency 测试客户端到目标redsi的网络延迟

--stat 查看redis统计信息，例如db的存储信息

--bigkeys 找出内存中占用比较大的键值

redis-server

--test-memory size，检查当前机器能否稳定的分配制定的容量

redis-benchmark

redis 压测工具

Pipeline

与批量命令区别

原生批量命令为原子的，pipeline则不是

原生批量命令一个命令对应多个key，pipeline则对应多个命令

原生批量命令是Redis服务端支持实现，Pipleline则两端都需要

事务

mutli-exec

编译时错误

执行失败

运行时错误

部分会成功

没有回滚操作

总结：弱事务，通常需要与watch配合使用，但是redis的成功率一半比较高，实际应用分场景。

乐观锁

watch

Bitmaps

实际类型为字符串，提供位操作。无压缩

应用场景：记录用户是否有访问过

HyperLogLog

利用极小的空间完成独立总数的统计

应用场景：例如，应用（UUID）的安装量

发布订阅

channel 简易的消息队列，由于消息不会持久化，简单场景可用

GEO

支持存储地理位置信息，使用zset存储

功能

两个位置的距离

一个位置一定范围内其他位置的信息

持久化

RDB 内存快照

优点

占用空间小，适合全量复制

Redis加载速度快

缺点

无法实时持久化，Fork子进程操作比较重。因此不宜频繁执行

RDB格式复杂，会有和Reids版本不兼容的问题

AOF 类bin-log

优点

性能影响小、文件格式简单（兼容性好）、用于实时备份

缺点

文件占用空间大，磁盘写入对性能有一定影响。因此引入了重写机制来优化文件大小，以及利用缓冲区来减少磁盘写。

常见问题以及定位

fork 耗时

单个redis实例OPS可达到5W/s，因此阻塞会导致大量的命令失败。

每个实例的内存控制大小，太大持久化时常大。虽然父子进程共用物理内存空间，但是子进程会复制父进程的内存页表。10G大概20M

多实例部署，要注意不要同时进行AOF重写操作。可以使用外部程序控制

数据复制

拓扑

一主一从

当主节点写并发高时，可以把持久化工作交给从节点，但是重启时需要注意。

一主多从

可以读写分离，但是也个主节点带来负担

树状主从结构

可以有效降低主节点负载。redis-cluster模式下不可用。

复制

redis采用异步复制的机制，主节点运行 info replication可以看到从节点的复制状态偏移量

 Collect

Get Started

系统远程运维架构图

 Collect

Get Started

流程图-项目运维流程与管控机制流程

 Collect

Get Started

运维监控中台

 Collect

Get Started

运维中心





0 条评论

下一页