本文共 5982 字,大约阅读时间需要 19 分钟。
对于高并发架构,毫无疑问缓存是最重要的一环,对于大量的高并发,可以采用三层缓存架构来实现,nginx+redis+ehcache
对于中间件nginx常用来做流量的分发,同时nginx本身也有自己的缓存(容量有限),我们可以用来缓存热点数据,让用户的请求直接走缓存并返回,减少流向服务器的流量
模板引擎
通常我们可以配合使用freemaker/velocity等模板引擎来抗住大量的请求双层nginx来提升缓存命中率
对于部署多个nginx而言,如果不加入一些数据的路由策略,那么可能导致每个nginx的缓存命中率很低。因此可以部署双层nginx用户的请求,在nginx没有缓存相应的数据,那么会进入到redis缓存中,redis可以做到全量数据的缓存,通过水平扩展能够提升并发、高可用的能力
持久化机制:将redis内存中的数据持久化到磁盘中,然后可以定期将磁盘文件上传至S3(AWS)或者ODPS(阿里云)等一些云存储服务上去。
如果同时使用RDB和AOF两种持久化机制,那么在redis重启的时候,会使用AOF来重新构建数据,因为AOF中的数据更加完整,建议将两种持久化机制都开启,用AO F来保证数据不丢失,作为数据恢复的第一选择;用RDB来作不同程度的冷备,在AOF文件都丢失或损坏不可用的时候来快速进行数据的恢复。
实战踩坑:对于想从RDB恢复数据,同时AOF开关也是打开的,一直无法正常恢复,因为每次都会优先从AOF获取数据(如果临时关闭AOF,就可以正常恢复)。此时首先停止redis,然后关闭AOF,拷贝RDB到相应目录,启动redis之后热修改配置参数redis config set appendonly yes,此时会自动生成一个当前内存数据的AOF文件,然后再次停止redis,打开AOF配置,再次启动数据就正常启动
redis集群
tomcat jvm堆内存缓存,主要是抗redis出现大规模灾难。如果redis出现了大规模的宕机,导致nginx大量流量直接涌入数据生产服务,那么最后的tomcat堆内存缓存也可以处理部分请求,避免所有请求都直接流向DB
最初级的缓存不一致问题以及解决方案
问题:如果先修改数据库再删除缓存,那么当缓存删除失败来,那么会导致数据库中是最新数据,缓存中依旧是旧数据,造成数据不一致。解决方案:可以先删除缓存,再修改数据库,如果删除缓存成功但是数据库修改失败,那么数据库中是旧数据,缓存是空不会出现不一致
比较复杂的数据不一致问题分析
问题:对于数据发生来变更,先删除缓存,然后去修改数据库,此时数据库中的数据还没有修改成功,并发的读请求到来去读缓存发现是空,进而去数据库查询到此时的旧数据放到缓存中,然后之前对数据库数据的修改成功来,就会造成数据不一致解决方案:将数据库与缓存更新与读取操作进行异步串行化。当更新数据的时候,根据数据的唯一标识,将更新数据操作路由到一个jvm内部的队列中,一个队列对应一个工作线程,线程串行拿到队列中的操作一条一条地执行。当执行队列中的更新数据操作,删除缓存,然后去更新数据库,此时还没有完成更新的时候过来一个读请求,读到了空的缓存那么可以先将缓存更新的请求发送至路由之后的队列中,此时会在队列积压,然后同步等待缓存更新完成,一个队列中多个相同数据缓存更新请求串在一起是没有意义的,因此可以做过滤处理。等待前面的更新数据操作完成数据库操作之后,才会去执行下一个缓存更新的操作,此时会从数据库中读取最新的数据,然后写入缓存中,如果请求还在等待时间范围内,不断轮询发现可以取到缓存中值就可以直接返回(此时可能会有对这个缓存数据的多个请求正在这样处理);如果请求等待事件超过一定时长,那么这一次的请求直接读取数据库中的旧值
对于这种处理方式需要注意一些问题:
对于缓存生产服务,可能部署在多台机器,当redis和ehcache对应的缓存数据都过期不存在时,此时可能nginx过来的请求和kafka监听的请求同时到达,导致两者最终都去拉取数据并且存入redis中,因此可能产生并发冲突的问题,可以采用redis或者zookeeper类似的分布式锁来解决,让请求的被动缓存重建与监听主动的缓存重建操作避免并发的冲突,当存入缓存的时候通过对比时间字段废弃掉旧的数据,保存最新的数据到缓存
当系统第一次启动,大量请求涌入,此时的缓存为空,可能会导致DB崩溃,进而让系统不可用,同样当redis所有缓存数据异常丢失,也会导致该问题。因此,可以提前放入数据到redis避免上述冷启动的问题,当然也不可能是全量数据,可以根据类似于当天的具体访问情况,实时统计出访问频率较高的热数据,这里热数据也比较多,需要多个服务并行的分布式去读写到redis中(所以要基于zk分布式锁)
通过nginx+lua将访问流量上报至kafka中,storm从kafka中消费数据,实时统计处每个商品的访问次数,访问次数基于LRU(apache commons collections LRUMap)内存数据结构的存储方案,使用LRUMap去存放是因为内存中的性能高,没有外部依赖,每个storm task启动的时候基于zk分布式锁将自己的id写入zk同一个节点中,每个storm task负责完成自己这里的热数据的统计,每隔一段时间就遍历一下这个map,然后维护一个前1000的数据list,然后去更新这个list,最后开启一个后台线程,每隔一段时间比如一分钟都将排名的前1000的热数据list同步到zk中去,存储到这个storm task对应的一个znode中去
部署多个实例的服务,每次启动的时候就会去拿到上述维护的storm task id列表的节点数据,然后根据taskid,一个一个去尝试获取taskid对应的znode的zk分布式锁,如果能够获取到分布式锁,再去获取taskid status的锁进而查询预热状态,如果没有被预热过,那么就将这个taskid对应的热数据list取出来,从而从DB中查询出来写入缓存中,如果taskid分布式锁获取失败,快速抛错进行下一次循环获取下一个taskid的分布式锁即可,此时就是多个服务实例基于zk分布式锁做协调并行的进行缓存的预热
对于瞬间大量的相同数据的请求涌入,可能导致该数据经过hash策略之后对应的应用层nginx被压垮,如果请求继续就会影响至其他的nginx,最终导致所有nginx出现异常整个系统变得不可用。
基于nginx+lua+storm的热点缓存的流量分发策略自动降级来解决上述问题的出现,可以设定访问次数大于后95%平均值n倍的数据为热点,在storm中直接发送http请求到流量分发的nginx上去,使其存入本地缓存,然后storm还会将热点对应的完整缓存数据没发送到所有的应用nginx服务器上去,并直接存放到本地缓存。对于流量分发nginx,访问对应的数据,如果发现是热点标识就立即做流量分发策略的降级,对同一个数据的访问从hash到一台应用层nginx降级成为分发至所有的应用层nginx。storm需要保存上一次识别出来的热点List,并同当前计算出来的热点list做对比,如果已经不是热点数据,则发送对应的http请求至流量分发nginx中来取消对应数据的热点标识
redis集群彻底崩溃,缓存服务大量对redis的请求等待,占用资源,随后缓存服务大量的请求进入源头服务去查询DB,使DB压力过大崩溃,此时对源头服务的请求也大量等待占用资源,缓存服务大量的资源全部耗费在访问redis和源服务无果,最后使自身无法提供服务,最终会导致整个网站崩溃。
事前的解决方案,搭建一套高可用架构的redis cluster集群,主从架构、一主多从,一旦主节点宕机,从节点自动跟上,并且最好使用双机房部署集群。
事中的解决方案,部署一层ehcache缓存,在redis全部实现情况下能够抗住部分压力;对redis cluster的访问做资源隔离,避免所有资源都等待,对redis cluster的访问失败时的情况去部署对应的熔断策略,部署redis cluster的降级策略;对源服务访问的限流以及资源隔离 事后的解决方案:redis数据做了备份可以直接恢复,重启redis即可;redis数据彻底失败来或者数据过旧,可以快速缓存预热,然后让redis重新启动。然后由于资源隔离的half-open策略发现redis已经能够正常访问,那么所有的请求将自动恢复对于在多级缓存中都没有对应的数据,并且DB也没有查询到数据,此时大量的请求都会直接到达DB,导致DB承载高并发的问题。解决缓存穿透的问题可以对DB也没有的数据返回一个空标识的数据,进而保存到各级缓存中,因为有对数据修改的异步监听,所以当数据有更新,新的数据会被更新到缓存汇中。
可以在nginx本地,设置缓存数据的时候随机缓存的有效期,避免同一时刻缓存都失效而大量请求直接进入redis
转载地址:http://yergi.baihongyu.com/