Redis架构第五天：Redis其他问题及Redis架构总结

刘伟

　　--------------------------------------------------其他问题---------------------------------------------------------------------
　　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设置为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
　　-----------------------------------------------------理论小结------------------------------------------------------------
　　1、讲解redis是为了什么？
　　topic：高并发、亿级流量、高性能、海量数据的场景，电商网站的商品详情页系统的缓存架构
　　商品详情页系统，大型电商网站，会有很多部分组成，但是支撑高并发、亿级流量的，主要就是其中的大型的缓存架构
　　在这个大型的缓存架构中，redis是最最基础的一层
　　高并发，缓存架构中除了redis，还有其他的组成部分，但是redis至关重要
　　大量的离散请求，随机请求，各种你未知的用户过来的请求，上千万用户过来访问，每个用户访问10次; 集中式的请求，1个用户过来，一天访问1亿次
　　支撑商品展示的最重要的，就是redis cluster，去抗住每天上亿的请求流量，支撑高并发的访问
　　redis cluster在整个缓存架构中，如何跟其他几个部分搭配起来组成一个大型的缓存系统，后面再讲
　　2、讲解的redis可以实现什么效果？
　　我之前一直在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，实现能够任意水平扩容，支撑海量数据（1T+，几十T，10G * 600 redis = 6T），支撑很高的读写QPS（redis单机在几万QPS，10台，几十万QPS），高可用性（给我们每个redis实例都做好AOF+RDB的备份策略+容灾策略，slave -> master主备切换）
　　1T+海量数据、10万+读写QPS、99.99%高可用性
　　3、redis的第一套企业级的架构
　　如果你的数据量不大，单master就可以容纳，一般来说你的缓存的总量在10G以内就可以，那么建议按照以下架构去部署redis
　　redis持久化+备份方案+容灾方案+replication（主从+读写分离）+sentinal（哨兵集群，3个节点，高可用性）
　　可以支撑的数据量在10G以内，可以支撑的写QPS在几万左右，可以支撑的读QPS可以上10万以上（随你的需求，水平扩容slave节点就可以），可用性在99.99%
　　4、redis的第二套企业级架构
　　如果你的数据量很大，比如我们课程的topic，大型电商网站的商品详情页的架构（对标那些国内排名前三的大电商网站，宝，东，*宁易购），数据量是很大的
　　海量数据
　　redis cluster
　　多master分布式存储数据，水平扩容
　　支撑更多的数据量，1T+以上没问题，只要扩容master即可
　　读写QPS分别都达到几十万都没问题，只要扩容master即可，redis cluster，读写分离，支持不太好，readonly才能去slave上读
　　支撑99.99%可用性，也没问题，slave -> master的主备切换，冗余slave去进一步提升可用性的方案（每个master挂一个slave，但是整个集群再加个3个slave冗余一下）
　　我们课程里，两套架构都讲解了，后续的业务系统的开发，主要是基于redis cluster去做
　　5、我们现在课程讲解的项目进展到哪里了？
　　我们要做后续的业务系统的开发，redis的架构部署好，是第一件事情，也是非常重要的，也是你作为一个架构师而言，在对系统进行设计的时候，你必须要考虑到底层的redis的并发、性能、能支撑的数据量、可用性
　　redis：水平扩容，海量数据，上10万的读写QPS，99.99%高可用性
　　从架构的角度，我们的redis是可以做到的，水平扩容，只要机器足够，到1T数据量，50万读写QPS，99.99%
　　正式开始做大型电商网站的商品详情页系统，大规模的缓存架构设计