缓存数据库 #

知识点 #

Redis

会性能问题的场景

• 大key或者多个key删除。
• 从库落后太多，大key写入引起复制风暴。
• AOF同步写回。
• AOF重写引起AOF写回阻塞。
  • 将AOF日志配置到SSD。
  • 兜底手段为设置AOF重写时不进行AOF写回。
• 使用大内存。会导致RDB文件过大。
  • 控制在2G到4G。
• 在节点上执行了聚合操作。
  • 应用层聚合或在单独的从库上聚合。
• 操作系统swap。
  • 通常发生在内存不足时。如果出现100MB以上swap就需要加内存或加节点。可以通过redis-cli info | grep process_id命令查询swap大小。
• 使用了内存大页。
  • 内存大页会导致小修改也会产生大页拷贝，生产中应关闭。
• 开启了碎片清理。
  • 内存碎片清理由主线程操作。可以调小active-defrag-cycle-max ，控制内存碎片整理所用CPU时间。

最佳实践 #

通用

• 确保所有数据都能in-memory。
• 通过监控系统统计缓存命中率，随时调整缓存策略。
• 数据一致性优先采用先写数据库后删缓存。特殊情况可以考虑双写。比如新用户注册时删缓存没有意义，而且注册后的用户大概率需要用到刚保存的注册信息。
• 缓存适用场景：
  • 读多写少，更新不频繁。
  • 计算代价大的数据。
  • 不与具体用户绑定，千人一面的数据，如商品页、排行榜、公告栏等。
  • 对数据一致性要求不严格。

Redis

• 持久化
  • 注重性能时，Slave替代Master做任何持久化。
  • 如果数据不能丢，配置AOF+RDB。 redis会优先载入AOF文件来恢复原始的数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的数据集完整。
  • 如果允许分钟丢失，配置RDB。
  • 如果只用AOF，优先everysec，每秒持久化。
• 集群
  • Master和Slave优先配置在同一个局域网。
  • 哨兵至少3个，所有哨兵配置一样。
  • 为了减少主从同步时主库全量RDB的压力，主从复制不要使用图状结构，而是使用级联的单向链表结构方式分摊压力。例如：从1，从2同步自主库。从3，从4同步自从1。
• List只用于队列。
• 大量数据用scan进行范围操作。
• 布隆过滤器是大key，应放在单独的Redis实例中。
• 指定过期时间优先使用expire_at。expire为存活时间，在从库执行时表示为从库收到主库同步发送过来的命令的时间再加上存活时间，所以可能发生过期读。
• 通过unlink异步删除大key。
• 关闭Huge page，避免AOF重写时因为大页拷贝引起的阻塞。

Redis Server配置

# 缓冲
## 控制replication buffer大小，主库为每个从库准备一个复制缓冲。
client-output-buffer-limit=256mb

# 集群
## 用于防止脑裂
### 主库能进行数据同步的最少从库数量
min-slaves-to-write=从库数/2+1
### 主从同步时，从库给主库发送 ACK 消息的最大延迟时间（以秒为单位）
min-slaves-max-lag=10到20s
### 哨兵判断的客观下线时间。调大该值可以降低误判的概率，但也意味着主从切换的时间会变长。
down-after-milliseconds=10s

## Redis Cluster集群
### 控制分片节点心跳的超时时间。
#### 分片节点一般采用一主一从实现高可用，如果某个分片节点主从切换时超过了节点心跳超时时间。
#### 分片集群就会认为该分片节点异常，如果一半异常集群就会停止服务。
cluster-node-timeout=10到20s