redis3 集群监控介绍

一 redis请求处理介绍

1. redis Server是单线程

1. 优点：因为CPU不是Redis的瓶颈。Redis的瓶颈最有可能是机器内存或者网络带宽，采用队列模式将并发访问变为串行执行。
2. redis快速原因是绝大部分请求是纯粹的内存操作（非常快速),采用单线程,避免了不必要的上下文切换和竞争条件，非阻塞IO
3. 缺点：要求每个请求执行必须时间非常的快。如果请求都是耗时的，采用单线程吞吐量及性能可想而知了。应该说redis为特殊的场景选择了合适的技术方案。

1. redis cluster集群

1. 没有集群功能的Redis，每个master-slave主从复制都独立于其他结点，sharding需要在客户端如Jedis中控制。可以使用官方提供的Sentinel监控主从的状态，实现自动的Fail-over切换。公司目前采用阿里云redis 2.8，master-slave，HA功能有阿里云自己研发。
2. redis集群的三个目标：性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
   水平扩展：集群的最重要能力当然是扩展，文档中称可以线性扩展到1000结点。可用性：在Cluster推出之前，可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。
3. 更多集群参考：http://blog.csdn.net/dc_726/article/details/48552531

二 redis desktop管理工具

1. Redis Desktop Manager

1. 请下载https://github.com/uglide/RedisDesktopManager ，公司采用阿里云redis服务是2.8版本，请下载RedisDesktopManager 0.8.8

2. 常用command

1. redis-cli连接node
   redis-cli -h host -p part

[root@iZbp11ti9rpeoo64gv0dz9Z src]# redis-cli -c  -h 172.16.30.37 -p 7001
172.16.30.37:7001>

172.16.30.37:7001> cluster nodes
NOAUTH Authentication required.

# 如果执行命令报 NOAUTH Authentication required. 再请用auth+password 登录。
127.0.0.1:6379> auth "yourpassword" 

- 如下命令可以在redisDesktop tools下的Console窗口下执行。

1. 切换不同的db

# select 切换到指定的数据库，数据库索引号 index 用数字值指定
redis-37-7007:14>select 15
OK

redis-37-7007:15>

1. 开发需要了解监控redis cluster信息，命令INFO将返回关于Redis服务器的各种信息和统计数值。帮助开发规划设计监控自己cache。

server : 一般 Redis 服务器信息，包含以下域：

    redis_version : Redis 服务器版本
    redis_git_sha1 : Git SHA1
    redis_git_dirty : Git dirty flag
    os : Redis 服务器的宿主操作系统
    arch_bits : 架构（32 或 64 位）
    multiplexing_api : Redis 所使用的事件处理机制
    gcc_version : 编译 Redis 时所使用的 GCC 版本
    process_id : 服务器进程的 PID
    run_id : Redis 服务器的随机标识符（用于 Sentinel 和集群）
    tcp_port : TCP/IP 监听端口
    uptime_in_seconds : 自 Redis 服务器启动以来，经过的秒数
    uptime_in_days : 自 Redis 服务器启动以来，经过的天数
    lru_clock : 以分钟为单位进行自增的时钟，用于 LRU 管理

clients : 已连接客户端信息，包含以下域：

    connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）
    client_longest_output_list : 当前连接的客户端当中，最长的输出列表
    client_longest_input_buf : 当前连接的客户端当中，最大输入缓存
    blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量

memory : 内存信息，包含以下域：

    used_memory : 由 Redis 分配器分配的内存总量，以字节（byte）为单位
    used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
    used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
    used_memory_peak : Redis 的内存消耗峰值（以字节为单位）
    used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
    used_memory_lua : Lua 引擎所使用的内存大小（以字节为单位）
    mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
    mem_allocator : 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
    在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
    当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。
    内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
    当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。
    Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.

    当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。
    如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
    查看 used_memory_peak 的值可以验证这种情况是否发生。
persistence : RDB 和 AOF 的相关信息

stats : 一般统计信息

replication : 主/从复制信息

cpu : CPU 计算量统计信息

commandstats : Redis 命令统计信息

cluster : Redis 集群信息

keyspace : 数据库相关的统计信息

http://blog.csdn.net/qq_27623337/article/details/53206685 –搭架

1. redisCluster集群node信息

172.16.30.37:7001> cluster nodes
ae72a76f3dfd252ffea9dd4f99eed73956985e8d 172.16.30.37:7003 master - 0 1519891351817 8 connected 10923-16383
2d515d01d5c340c056e45f532f87e2e9a710ad2e 172.16.30.37:7002 master - 0 1519891353827 2 connected 5461-10922
a55520dc10558d288315617a540b16ea753fae90 172.16.30.37:7004 master - 0 1519891349813 9 connected 0-5460
f61d2cce02eba73886449f7be22ae66c6909644f 172.16.30.37:7006 slave ae72a76f3dfd252ffea9dd4f99eed73956985e8d 0 1519891352821 8 connected
0f34e5062e6ab8b203288adb27b76b6499f81097 172.16.30.37:7005 slave 2d515d01d5c340c056e45f532f87e2e9a710ad2e 0 1519891350814 5 connected
960a22035faacce41dc10ea185b962fe706c4adf 172.16.30.37:7001 myself,slave a55520dc10558d288315617a540b16ea753fae90 0 0 1 connected
172.16.30.37:7001>

更多关于添加集群，删除集群node的命令请关注了解如下：

• 集群
• cluster info：打印集群的信息
• cluster nodes：列出集群当前已知的所有节点（node），以及这些节点的相关信息。
• 节点
• cluster meet ：将ip和port所指定的节点添加到集群当中，让它成为集群的一份子。
• cluster forget：从集群中移除 node_id 指定的节点。
• clusterreplicate ：将当前节点设置为node_id指定的节点的从节点。
• clustersaveconfig：将节点的配置文件保存到硬盘里面。
• 槽(slot)

 cluster addslots [slot ...]：将一个或多个槽（slot）指派（assign）给当前节点。
clusterdelslots  [slot ...]：移除一个或多个槽对当前节点的指派。
clusterflushslots：移除指派给当前节点的所有槽，让当前节点变成一个没有指派任何槽的节点。
cluster setslot node ：将槽 slot 指派给 node_id 指定的节点，如果槽已经指派给另一个节点，那么先让另一个节点删除该槽>，然后再进行指派。
cluster setslot migrating ：将本节点的槽 slot 迁移到node_id 指定的节点中。
cluster setslot importing ：从 node_id 指定的节点中导入槽slot 到本节点。
cluster setslot stable：取消对槽 slot 的导入（import）或者迁移（migrate）。

• 键

cluster keyslot<key>：计算键 key 应该被放置在哪个槽上。
clustercountkeysinslot <slot>：返回槽 slot 目前包含的键值对数量。
clustergetkeysinslot <slot> <count>：返回 count 个 slot 槽中的键。

1. 更多常用操作维护key类型command，请参考http://doc.redisfans.com/index.html

三 redisCluster 介绍

1. redis 3.0已自带cluster，支持master slave failover功能。
2. redis 3.0也支持key自动sharding功能。
3. 集群参考
   http://blog.csdn.net/fengshizty/article/details/51368004 –搭架
   https://www.cnblogs.com/hk315523748/p/6122263.html –维护

pipeline批量commod优化前后

1. 我们公司真实生产，用来cache kafka offset变化的

# Stats
total_connections_received:6268502
total_commands_processed:27403503791
instantaneous_ops_per_sec:23432
total_net_input_bytes:947346345264
total_net_output_bytes:316704548663
instantaneous_input_kbps:1209.41
instantaneous_output_kbps:1224.92
input_limit_tokens:31456683
output_limit_tokens:31457240

1. 才pipeline 批量命令后的结果：

# Stats
total_connections_received:6270546
total_commands_processed:27477368164
instantaneous_ops_per_sec:2678
total_net_input_bytes:951300825607
total_net_output_bytes:320813929044
instantaneous_input_kbps:91.40
instantaneous_output_kbps:21.98
input_limit_tokens:31457266
output_limit_tokens:31457273
input_strict_limit:0
output_strict_limit:0
rejected_connections:0
rejected_connections_status:0
sync_full:1
sync_partial_ok:2