Redis Request Routing

• 在Redis Server丛集中所有的操作透过Request Routing到正确的Master节点进行．

./redis-cli -h 127.0.0.1 -p 6310

# set key value 成功
127.0.0.1:6310> set book 123
OK

# set key value 失败，因为hash_slot = 5787，应该在127.0.0.1:6320操作
127.0.0.1:6310> set book1 abc
(error) MOVED 5787 127.0.0.1:6320

# set key value 失败，因为hash_slot = 9976，应该在127.0.0.1:6320操作
127.0.0.1:6310> set book2 def
(error) MOVED 9976 127.0.0.1:6320

# set key value 失败，因为hash_slot = 14041，应该在127.0.0.1:6330操作
127.0.0.1:6310> set book3 ghi
(error) MOVED 14041 127.0.0.1:6330

# 透过 -c 来做Request Routing到正确的Master节点进行
./redis-cli -h 127.0.0.1 -p 6310 -c

# set key value 成功
127.0.0.1:6310> set book 456
OK

# set key value 成功，自动导向正确的Master节点操作
127.0.0.1:6310> set book1 abc
-> Redirected to slot [5787] located at 127.0.0.1:6320
OK

# set key value 成功，自动导向正确的Master节点操作
127.0.0.1:6320> set book2 def
OK

# set key value 成功，自动导向正确的Master节点操作
127.0.0.1:6320> set book3 ghi
-> Redirected to slot [14041] located at 127.0.0.1:6330
OK


# 透过 -c 来做Request Routing没有办法自动读写分离
# 设定唯读模式，保持与replica连线
127.0.0.1:6330> readonly
OK

# 设定读写模式
127.0.0.1:6330> readwrite
OK

Redis效能监控与调教

Redis最差与最佳实践

• 7种Redis的最差实践
  • 没有设定密码
  • 任意执行keys * 操作
  • 太多资料库
  • 执行HGETALL、LRANGE、SMEMBERS、ZRANGE时，没有设定回传限制
  • 一次连线只执行一个请求
  • Hot Keys
  • 没有对Redis Server设定高可用性

7-redis-worst-practices

• Redis的最佳实践
  • 避免储存bigkey
  • 启用lazyfree-*
  • 尽量不要使用时间复杂度 (Big O)高的操作
  • 如果需要执行时间复杂度为O(n)的指令时，请注意n的大小
  • 请注意DEL操作的时间复杂度
  • 使用批次操作取代多次单一操作
  • 不要在同一时间过期大量的key
  • 良好的连线管理
  • 建议只使用一个资料库(db)
  • 建置Redis主从架构设定读写分离
  • 建置Redis 丛集
  • 关闭AOF或开启AOF搭配everysec写入
  • 使用实体主机安装Redis
  • 建议关闭作业系统Hugepage机制

Redis效能测试与监控

• 取得基准效能
  • 建议抓取基准效能的2倍延迟当作监控

# --latency
# --latency-history
# --latency-dist
./redis-cli -h 127.0.0.1 -p 6310 --intrinsic-latency 60

• 效能测试(Benchmark)

# 在127.0.0.1:6310 启用20个client测试10000个指令
./redis-benchmark -h 127.0.0.1 -p 6310 -n 10000 -q -c 20

# 参阅help
./redis-benchmark --help

benchmarks

• 透过慢日志(Slowlog)取得需要被关注的记录

  • 设定慢日志
    • CONFIG SET slowlog-log-slower-than 1
      • 设定执行时间阀值为1毫秒
      • 预设为10毫秒，建议为1毫秒
    • CONFIG SET slowlog-max-len 500
      • 设定保留最近500笔记录
      • 不要太小，建议1000
  • 显示目前慢日志笔数
    • SLOWLOG LEN
  • 清除慢日志
    • SLOWLOG RESET

• 关注Memory实际使用状况

  • 理论上used_memory_rss应该稍微大於used_memory而已

ps aux | grep redis-server
free
vmstat

• Redis的驱逐政策

  • volatile-lru
    • 根据LRU演算法删除具有过期时间的Key
  • allkeys-lru
    • 根据LRU演算法删除任何key
  • volatile-random
    • 随机删除具有过期时间的key
  • allkeys-random
    • 随机删除任何key
  • volatile-ttl
    • 根据最近过期时间及TTL删除具有过期时间的Key
  • noevication

• 选择合适的LRU

  • 如果有一部分使用频率高，其余部分使用频率较少，或者无法预测资料的使用率．
    • allkeys-lru
  • 如果所有资料有大致相同的使用频率
    • allkeys-random
  • 使用者自行通过不同的TTl来设定资料过期的顺序
    • volatile-ttl
  • 如果某些资料希望可以长期保留
    • volatile-lru or volatile-random
  • 由於设定Expire会增加记忆体消耗，为避免浪费记忆体
    • allkeys-lru

• Redis Server的记忆体使用最佳化

  • 控制key的长度
  • 避免储存bigkey
    • String建议在10kb以下
    • List/Hash/Set/Zset的元素个数建议在10000个以下
  • 使用适当的资料型态
    • String/Set资料型态在储存int资料时，会使用整数编码储存
    • List/Hash/Zset资料型态在元素个数较少时，将使用ziplist型态储存．资料较多时，才会使用Hashtable与skiptable
  • 将Redis Server当作快取使用而不是资料库
  • 设定maxmemory与maxmemory-policy
  • 先压缩再写入Redis

• BGSAVE异常错误讯息

  • 因为进行bgsave时，会fork()一个子Process负责进行RDB操作．子Process使用copy-on-write机制共用父Process的记忆体内容，但如果父Process变更一块记忆体内容，此时其变更前内容将复制到子Process的记忆体用以维持一致性．
  • 如果此时作业系统的overcommit_memory设定为0，而Redis Server已使用超过3G记忆体．所以执行bgsave时，Redis Server需要确定有超过3G可用记忆体．
  • 如果目前作业系统仅有2G可用记忆体，此时将无法fork()一个子Process进行bgsave，从而出现错误讯息

总结

Redis 在使用前需要先好好的思考应用的情境场景规划适合自己应用的架构，搭配其特性进行操作可以提升应用程序的效率与提供良好的可靠度，这30篇只是一个分享的开始，还有很多的细节与应用情境的最佳实践，个人目前还在努力的学习中，待我後续再与各位分享。谢谢各位的陪伴，祝福各位在学习路上一且顺利．感谢！