一. 常见问题
1、fork耗时导致高并发请求延时
RDB和AOF的时候,其实会有生成RDB快照,AOF rewrite,耗费磁盘IO的过程,主进程fork子进程
fork的时候,子进程是需要拷贝父进程的空间内存页表的,也是会耗费一定的时间的
一般来说,如果父进程内存有1个G的数据,那么fork可能会耗费在20ms左右,如果是10G~30G,那么就会耗费20 * 10,甚至20 * 30,也就是几百毫秒的时间
info stats中的latest_fork_usec,可以看到最近一次form的时长
redis单机QPS一般在几万,fork可能一下子就会拖慢几万条操作的请求时长,从几毫秒变成1秒
优化思路
fork耗时跟redis主进程的内存有关系,一般控制redis的内存在10GB以内,slave -> master,全量复制
2、AOF的阻塞问题
redis将数据写入AOF缓冲区,单独开一个现场做fsync操作,每秒一次
但是redis主线程会检查两次fsync的时间,如果距离上次fsync时间超过了2秒,那么写请求就会阻塞
everysec,最多丢失2秒的数据
一旦fsync超过2秒的延时,整个redis就被拖慢
优化思路
优化硬盘写入速度,建议采用SSD,不要用普通的机械硬盘,SSD,大幅度提升磁盘读写的速度
3、主从复制延迟问题
主从复制可能会超时严重,这个时候需要良好的监控和报警机制
在info replication中,可以看到master和slave复制的offset,做一个差值就可以看到对应的延迟量
如果延迟过多,那么就进行报警
4、主从复制风暴问题
如果一下子让多个slave从master去执行全量复制,一份大的rdb同时发送到多个slave,会导致网络带宽被严重占用
如果一个master真的要挂载多个slave,那尽量用树状结构,不要用星型结构
5、vm.overcommit_memory
0: 检查有没有足够内存,没有的话申请内存失败
1: 允许使用内存直到用完为止
2: 内存地址空间不能超过swap + 50%
如果是0的话,可能导致类似fork等操作执行失败,申请不到足够的内存空间
cat /proc/sys/vm/overcommit_memory
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1
6、swapiness
cat /proc/version,查看linux内核版本
如果linux内核版本<3.5,那么swapiness设置为0,这样系统宁愿swap也不会oom killer(杀掉进程)
如果linux内核版本>=3.5,那么swapiness设置为1,这样系统宁愿swap也不会oom killer
保证redis不会被杀掉
echo 0 > /proc/sys/vm/swappiness
echo vm.swapiness=0 >> /etc/sysctl.conf
7、最大打开文件句柄
ulimit -n 10032 10032
自己去上网搜一下,不同的操作系统,版本,设置的方式都不太一样
8、tcp backlog
cat /proc/sys/net/core/somaxconn
echo 511 > /proc/sys/net/core/somaxconn
二. redis总结:
redis:持久化、复制(主从架构)、哨兵(高可用,主备切换)、redis cluster(海量数据+横向扩容+高可用/主备切换)
持久化:高可用的一部分,在发生redis集群灾难的情况下(比如说部分master+slave全部死掉了),如何快速进行数据恢复,快速实现服务可用,才能实现整个系统的高可用
复制:主从架构,master -> slave 复制,读写分离的架构,写master,读slave,横向扩容slave支撑更高的读吞吐,读高并发,10万,20万,30万,上百万,QPS,横向扩容
哨兵:高可用,主从架构,在master故障的时候,快速将slave切换成master,实现快速的灾难恢复,实现高可用性
redis cluster:多master读写,数据分布式的存储,横向扩容,水平扩容,快速支撑高达的数据量+更高的读写QPS,自动进行master -> slave的主备切换,高可用
为什么要学redis理论知识:
让底层的缓存系统,redis,实现能够任意水平扩容,支撑海量数据(1T+,几十T,10G * 600 redis = 6T),支撑很高的读写QPS(redis单机在几万QPS,10台,几十万QPS),高可用性(给我们每个redis实例都做好AOF+RDB的备份策略+容灾策略,slave -> master主备切换)
实现1T+海量数据、10万+读写QPS、99.99%高可用性
三. redis的第一套企业级的架构
如果你的数据量不大,单master就可以容纳,一般来说你的缓存的总量在10G以内就可以,那么建议按照以下架构去部署redis
redis持久化+备份方案+容灾方案+replication(主从+读写分离)+sentinal(哨兵集群,3个节点,高可用性)
可以支撑的数据量在10G以内,可以支撑的写QPS在几万左右,可以支撑的读QPS可以上10万以上(随你的需求,水平扩容slave节点就可以),可用性在99.99%
四. redis的第二套企业级架构
如果你的数据量很大,比如我们课程的topic,大型电商网站的商品详情页的架构(对标那些国内排名前三的大电商网站,*宝,*东,*宁易购),数据量是很大的
海量数据
redis cluster
多master分布式存储数据,水平扩容
支撑更多的数据量,1T+以上没问题,只要扩容master即可
读写QPS分别都达到几十万都没问题,只要扩容master即可,redis cluster,读写分离,支持不太好,readonly才能去slave上读
支撑99.99%可用性,也没问题,slave -> master的主备切换,冗余slave去进一步提升可用性的方案(每个master挂一个slave,但是整个集群再加个3个slave冗余一下)