大家学实战的时候可以把我的文章翻出来，就不用自己记笔记了。节省大家学习成本。

慢查询

pipeline

发布订阅

bitmap（位图）

• string类型，最大512mb
• 注意setbit偏移量，可能有较大耗时
• 位图要合理使用

set和Bitmap对比

• 使用set和Bitmap
• 1亿用户，5千万独立

只有10万独立用户呢

HyperLoglog

• 1.基于HyperLogLog算法：极小空间完成独立数量统计。
• 2.本质还是字符串。

127.0.0.1:6379>type hyperloglog_key
string

• pfadd key element [element…]:向hyperloglog添加元素
• pfcount key [key…]:计算hyperloglog的独立总数
• pfmerge destkey sourcekey [sourcekey……]:合并多个hyperloglog

GEO

• since 3.2+
• type geokey=zset
• 没有删除API:zrem key member

127.0.0.1:6379> info memory
# Memory
used_memory:815096
used_memory_human:795.99K
used_memory_rss:7626752
used_memory_peak:815096
used_memory_peak_human:795.99K
used_memory_lua:36864
mem_fragmentation_ratio:9.36
mem_allocator:jemalloc-3.6.0

Redis持久化

RDB

SAVE

• 当数据量大时，save会阻塞
• 文件策略 如存在老的RDB文件，新替换老
• 复杂度O（N）

• save(同步）
• bgsave（异步）
• 自动

bgsave

自动RDB

最佳配置
save 900 1 
save 300 10 
save 60 10000
dbfilename dump.rdb
dir ./
stop-writes-on-bgsave-error- yes 中断写入
rdbcompression yes 默认启用压缩 
rdbchecknum yes 默认启用计算和

自动触发机制

• 全量复制
• debug reload
• shutdown save

• RDB是Redis内存到硬盘的快照，用于持久化。
• save通常会阻塞Redis。
• bgsave不会阻塞Redis，但是会fork新进程。
• save自动配置满足任一就会被执行。
• 有些触发机制不容忽视

AOF

rdB缺点

数据不可控，容易丢失

AOF three tactics

always

everysec(默认值，故障，有可能丢失)

no

AOF rewrite two ways

• bgrewriteaof
• AOF重写配置

AOF重写流程

AOF配置

no-appendfsync-on-rewrite
重写时关闭正常的AOF append （性能和丢失率的选择）
aof-load-truncated yes 当aof有问题时，我们是否忽略错误

appendonly yes
appendfilename "appendonly-${port).aof"
appendfsync everysec
dir /bigdiskpath
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs AOF

最佳实践

• RDB
  • 主从，从‘开’，粒度不要太小
  • 集中管理
• AOF
  • 开：缓存和存储
  • AOF重写集中管理 分配服务器百分之五十到六十的内存
  • everysync
• 总
  • 小切片 设置最大内存4个G
  • 存储和缓存
  • 监控（硬盘，内存，负载，网络）
  • 内存足够