本文目录：
- 1、腾讯云redis支持多库吗
- 2、阿里云腾讯云服务器官方性能及实际体验对比
- 3、Redis分布式缓存搭建
- 4、Redis简单集群
- 5、redisdb容量使用情况
- 6、redis 线上问题排查思路总结
腾讯云redis支持多库吗
不支持，redis有个多库的设计,默认从0号到16可以再扩展,我们用它做多租户应用数据隔离的缓存。但redis各种集群方案,似乎只能用0号库,不支持多库。
阿里云腾讯云服务器官方性能及实际体验对比
阿里云腾讯云服务器性能对比
阿里云我自己的服务器，2核8G的，1个物理CPU.1个物理核心，两线程
4核=核8g,1个物理CPU 2个物理核心，4线程
腾讯云sa24核8g 一个物理CPU，4个物理核心，,4线程
实际体验：腾讯云的redis会掉，阿里云的没有遇到过，扔开性能指数，还是阿里云的稳定些
腾讯云的不稳定点，性价比腾讯云还是可以吧，sa2做活动服务商那边拿真便宜！！
腾讯官方活动链接
阿里官方活动链接
以下是腾讯官网的一些数据
腾讯云标准型 S5
2.5GHz Intel® Xeon® Cascade Lake 处理器，2.5GHz,睿频3.1GHz，搭配最新一代六通道 DDR4，内存计算性能稳定
规格vCPU内存（GB）网络收发包（pps）队列数内网带宽能力（Gbps）主频备注
S5.SMALL11125万11.52.5GHz-
S5.SMALL21225万11.52.5GHz-
S5.SMALL41425万11.52.5GHz-
S5.MEDIUM42430万21.52.5GHz-
S5.MEDIUM82830万21.52.5GHz-
S5.LARGE84850万21.52.5GHz-
S5.LARGE1641650万21.52.5GHz-
S5.2XLARGE1681680万23.02.5GHz-
S5.2XLARGE3283280万23.02.5GHz-
S5.4XLARGE321632150万46.02.5GHz-
S5.4XLARGE641664150万46.02.5GHz-
S5.6XLARGE482448200万69.02.5GHz-
S5.6XLARGE962496200万69.02.5GHz-
S5.8XLARGE643264250万8122.5GHz-
S5.8XLARGE12832128250万8122.5GHz-
S5.12XLARGE964896400万1217.02.5GHz-
S5.12XLARGE19248192400万1217.02.5GHz-
S5.16XLARGE25664256500万1623.02.5GHz-
腾讯云s4
标准型 S4 实例采用至强®处理器 Skylake 全新处理器，内存采用最新最新一代六通道 DDR4 内存，，默认网络优化，内存带宽达2666MT/s最高内网收发能力达600万pps，最高内网带宽可支持25Gbps。
服务器 2.4GHz Intel® Xeon® Skylake 6148 最新一代六通道 DDR4 内存
规格vCPU内存（GB）网络收发包（pps）队列数内网带宽能力（Gbps）主频备注
S4.SMALL11125万11.52.4GHz-
S4.SMALL21225万11.52.4GHz-
S4.SMALL41425万11.52.4GHz-
S4.MEDIUM42430万21.52.4GHz-
S4.MEDIUM82830万21.52.4GHz-
S4.LARGE84850万21.52.4GHz-
S4.LARGE1641650万21.52.4GHz-
S4.2XLARGE1681680万23.02.4GHz-
S4.2XLARGE3283280万23.02.4GHz-
S4.4XLARGE321632150万46.02.4GHz-
S4.4XLARGE641664150万46.02.4GHz-
S4.6XLARGE482448200万68.02.4GHz-
S4.6XLARGE962496200万68.02.4GHz-
S4.8XLARGE643264250万811.02.4GHz-
S4.8XLARGE12832128250万811.02.4GHz-
S4.12XLARGE964896400万1216.02.4GHz-
S4.12XLARGE19248192400万1216.02.4GHz-
S4.16XLARGE12864128500万1622.02.4GHz-
S4.16XLARGE25664256500万1622.02.4GHz-
S4.18XLARGE28872288600万1624.02.4GHz-
腾讯云标准型SA2配置参数
CPU处理器：AMD EPYC ROME新一代处理器，主频2.6GHz，睿频3.3GHz。
内存：最新一代八通道 DDR4，内存计算性能稳定。
网络：超高网络收发包能力达750万pps，最大网络带宽25Gbps。
规格vCPU内存（GB）网络收发包（pps）队列数内网带宽能力（Gbps）主频备注
SA2.SMALL11125万11.52.6GHz-
SA2.SMALL21225万11.52.6GHz-
SA2.SMALL41425万11.52.6GHz-
SA2.MEDIUM42430万21.52.6GHz-
SA2.MEDIUM82830万21.52.6GHz-
SA2.LARGE84850万21.52.6GHz-
SA2.LARGE1641650万21.52.6GHz-
SA2.2XLARGE1681670万21.52.6GHz-
SA2.2XLARGE3283270万21.52.6GHz-
SA2.4XLARGE321632100万43.02.6GHz-
SA2.4XLARGE641664100万43.02.6GHz-
SA2.8XLARGE643264140万85.02.6GHz-
SA2.12XLARGE964896210万127.02.6GHz-
SA2.16XLARGE12864128280万169.02.6GHz-
SA2.20XLARGE16080160350万1612.02.6GHz-
SA2.22XLARGE22490224375万1613.02.6GHz-
SA2.24XLARGE19296192420万1614.02.6GHz-
SA2.32XLARGE256128256560万3218.02.6GHz-
SA2.40XLARGE320160320710万3223.02.6GHz-
SA2.45XLARGE464180464750万3225.02.6GHz-
Redis分布式缓存搭建
花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。
笔者安装中遇到的一些问题：
如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
这回编译通过了，提示让你最好make test一下/
执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升级tcl， yum install tcl
重新make test，如果还有error就删了目录，重新tar包解压重新make , make test
\o/ All tests passed without errors! ，表示编译成功。
然后make install即可。
直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf
redis.conf 配置文件里 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。
redis高可用方案有两种：
常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。
（1）sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf
sentinel2.conf配置：
坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth
当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：
原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf
中配置：
坑2：哨兵配置文件要暴露客户端可以访问到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。
附springboot2.1 redis哨兵配置：
坑3：要注意配置文件.conf会被哨兵修改
redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。
曾经遇到过这样一个问题，大致的信息如下
slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !
最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。
（2）集群
当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 – 中间件 – Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。
Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。
每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。
reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。
搭建Redis cluster
redis.conf文件关键的几个配置：
启动6个集群节点
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
这时候这6个节点还是独立的，要把他们配置成集群：
说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 –cluster-replicas 1 中的1表示每个master节点有1个从节点。
上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。
最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。
查看集群状态：
坑1：暴露给客户端的节点地址不对
使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。
我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 dump.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：
然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！
解决办法，修改每个节点的redis.conf配置文件，找到如下说明：
所以增加配置：
然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）
重新使用Lettuce测试，这次终于连上了！
坑2：Lettuce客户端在master节点故障时没有自动切换到从节点
name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：
重新启动7002进程，
7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。
解决办法，修改Lettuce的配置：
笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。
重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）
Redis不保证数据的强一致性
Redis并不保证数据的强一致性，也就是取CAP定理中的AP
关于一致性Hash算法，可以参考 一致性Hash算法 – (jianshu.com)
Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。
比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。
关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。
与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。
所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。
这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。
Redis高可用方案 – (jianshu.com)
面试题:Redis 集群模式的工作原理能说一下么 – 云+社区 – 腾讯云 (tencent.com)
深度图解Redis Cluster原理 – detectiveHLH – 博客园 (cnblogs.com)
Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)
云服务器Redis集群部署及客户端通过公网IP连接问题
Redis简单集群
1开放云服务器web控制台对应的端口和对应防火墙端口
22台阿里云服务器（公网IP：120.25.172.196，120.78.177.101）
一台腾讯云服务器（公网IP：111.231.106.5）
其中（120.25.172.196作为主，其他两台作为从）
主要修改3个配置如下：
bind 0.0.0.0 (原本是127.0.0.1，bind不是绑定意思而是允许哪个IP访问这个跑起来redis,0.0.0.0代表任意IP)
requirepass xu123456 (设置密码，客户端需要用，在小黑窗打命令如下redis-cli -a xu123456)
masterauth xu123456 (设置从节点追随主节点密码，设成和上面一样)
》》》带配置启动Redis服务：redis-server ~/redisfile/redis.conf
在120.78.177.101 进入redis-cli 客户端小黑窗后，执行replicaof 120.25.172.196 6379 追随master
在111.231.106.5 进入redis-cli 客户端小黑窗后，执行replicaof 120.25.172.196 6379 追随master
1，redis-server 26379.conf –sentinel
其中26379.conf 只有两行：
port 26379
sentinel monitor mymaster 120.25.172.196 6379 2
sentinel auth-pass mymaster xu123456
sentinel announce-ip “120.25.172.196” #这个是公布Redis 对外用这个公网IP
具体解释：mymaster任意给的名字，127.0.0.1 6379 代表监控的服务，2代表选举势力
假如集群中有5个sentinel，票数被设置为2，当2个sentinel认为一个master已经不可用了以后，将会触发failover，但是，进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。
如果票数被设置为5，要达到ODOWN状态，必须所有5个sentinel都主观认为master为不可用，要进行failover，那么得获得所有5个sentinel的授权。
redisdb容量使用情况
阿里云、腾讯云云数据库Redis版有256个DB，从DB0到DB255。
数据库是由一个整数索引标识，而不是由一个数据库名称。默认情况下，一个客户端连接到数据库0。
每个数据库都有属于自己的空间，不必担心之间的key冲突。
每个DB没有单独的内存占用量限制，DB可以使用的内存容量受Redis实例的总内存限制。
您可以使用SELECT命令在不同DB之间切换。
redis 线上问题排查思路总结
日常我们使用redis 缓存时，经常会遇到各种各样的问题，其中redis 偶发性连接超时，是经常遇到的一个问题，下面介绍一下我们之前是如何处理的这个问题。
1、redis 服务监控
通过监控工具，首先排查一下redis 服务端是否是超时，可以从服务器cpu ，内存使用情况，qps等判断server 端是否超时。如果server 侧没有问题，就需要排查客户端。如果server 侧存在问题，就需要排查服务器哪里出了问题，单机性能使用率太高是否可以升级成哨兵模式或者高可用集群模式。
2、redis 客户端排查
首先查看业务日志，查看一下redis 使用情况是否是存在连接数占满或者创建失败的异常，如果存在，在客户端服务器，使用top 指令，查看使用率高的线程，然后jstack pid,查看当前线程的使用情况。如果出现大量的线程状态显示time_waiting 或者waiting 。则表示连接数一直没有释放，可以通过调整客户端配置的redis 连接池参数，比如配置max连接数和min连接数，time_out超时时间等等。
3、redis 热key排查
排查redis 热key,腾讯云或者阿里云服务器可以使用监控热key的工具。redis 4.0 以后，提供了—hotkey 指令，可以通过热key 指令来监控热key。如果发现异常热key,比如spring-redis-session的热key,存储的是一段时间戳，并且访问率非常高，qps 几十万/s。这时候需要考虑热key是否对业务产生影响，可以通过配置spring.session.store-type=none，关闭存储redis.这时候热key访问量下降，业务key 可以正常访问。
通过以上方式，排查生产中遇到的redis 连接问题，可以排查线上遇到的问题，基本都可以解决掉。
【腾讯云redis】的内容来源于互联网，如引用不当，请联系我们修改。
