您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

时间:2019-08-19 17:31:42  来源:  作者:

概述

对于高并发架构,毫无疑问缓存是最重要的一环,对于大量的高并发,可以采用三层缓存架构来实现,Nginx+redis+ehcache,下面对这每个环节做一下介绍。


nginx

对于中间件nginx常用来做流量的分发,同时nginx本身也有自己的缓存(容量有限),我们可以用来缓存热点数据,让用户的请求直接走缓存并返回,减少流向服务器的流量

1、模板引擎

通常我们可以配合使用freemaker/velocity等模板引擎来抗住大量的请求

  1. 小型系统可能直接在服务器端渲染出所有的页面并放入缓存,之后的相同页面请求就可以直接返回,不用去查询数据源或者做数据逻辑处理
  2. 对于页面非常之多的系统,当模板有改变,上述方法就需要重新渲染所有的页面模板,毫无疑问是不可取的。因此配合nginx+lua(OpenResty),将模板单独保存在nginx缓存中,同时对于用来渲染的数据也存在nginx缓存中,但是需要设置一个缓存过期的时间,以尽可能保证模板的实时性

2、双层nginx来提升缓存命中率

对于部署多个nginx而言,如果不加入一些数据的路由策略,那么可能导致每个nginx的缓存命中率很低。因此可以部署双层nginx

  1. 分发层nginx负责流量分发的逻辑和策略,根据自己定义的一些规则,比如根据productId进行hash,然后对后端nginx数量取模将某一个商品的访问请求固定路由到一个nginx后端服务器上去
  2. 后端nginx用来缓存一些热点数据到自己的缓存区

3、推荐架构

nginx作为最前端的web cache系统,通常的架构如下

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

 

这个结构的优点:

  1. 可以使用nginx前端进行诸多复杂的配置,这些配置从前在squid是没法做或者做起来比较麻烦的,比如针对目录的防盗链。
  2. nginx前端可以直接转发部分不需要缓存的请求。
  3. 因为nginx效率高于squid,所以某些情况下可以利用nginx的缓存来减轻squid压力。
  4. 可以实现url hash等分配策略
  5. 可以在最前端开启gzip压缩,这样后面的squid缓存的纯粹是无压缩文档,可以避免很多无谓的穿透。
  6. 因为nginx稳定性比较高,所以lvs不需要经常调整,通过nginx调整就可以。
  7. squid的文件打开数按默认的1024就绰绰有余,不过处理的请求可一个都不会少。
  8. 可以启用nginx的日志功能取代squid,这样做实时点击量统计时可以精确定位到url,不必要再用低效率的grep来过滤。
  9. 因为nginx的负载能力高于squid,所以在用lvs分流时可以不必分得特别均衡,出现单点故障的几率比较低。

nginx和squid配合搭建的web服务器前端系统架构:

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

 

前端的lvs和squid,按照安装方法,把epoll打开,配置文件照搬,基本上问题不多。

这个架构和App_squid架构的区别,也是关键点就是:加入了一级中层代理,中层代理的好处实在太多了:

  1. gzip压缩:压缩可以通过nginx做,这样,后台应用服务器不管是Apache、resin、lighttpd甚至iis或其他古怪服务器,都不用考虑压缩的功能问题。
  2. 负载均衡和故障屏蔽:nginx可以作为负载均衡代理使用,并有故障屏蔽功能,这样,根据目录甚至一个正则表达式来制定负载均衡策略变成了小case。
  3. 方便的运维管理,在各种情况下可以灵活制订方案。
  4. 权限清晰:这台机器就是不写程序的维护人员负责,程序员一般不需要管理这台机器,这样假如出现故障,很容易能找到正确的人。对于应用服务器和数据库服务器,最好是从维护人员的视线中消失,我的目标是,这些服务只要能跑得起来就可以了,其它的事情全部可以在外部处理掉。

redis(看架构也可以考虑memcache)

用户的请求,在nginx没有缓存相应的数据,那么会进入到redis缓存中,redis可以做到全量数据的缓存,通过水平扩展能够提升并发、高可用的能力

1、持久化机制:将redis内存中的数据持久化到磁盘中,然后可以定期将磁盘文件上传至S3(AWS)或者ODPS(阿里云)等一些云存储服务上去。

1)RDB

对redis中的数据执行周期性的持久化,每一刻持久化的都是全量数据的一个快照。对redis性能影响较小,基于RDB能够快速异常恢复

2)AOF

以append-only的模式写入一个日志文件中,在redis重启的时候可以通过回放AOF日志中的写入指令来重新构建整个数据集。(实际上每次写的日志数据会先到linux os cache,然后redis每隔一秒调用操作系统fsync将os cache中的数据写入磁盘)。对redis有一定的性能影响,能够尽量保证数据的完整性。redis通过rewrite机制来保障AOF文件不会太庞大,基于当前内存数据并可以做适当的指令重构。

如果同时使用RDB和AOF两种持久化机制,那么在redis重启的时候,会使用AOF来重新构建数据,因为AOF中的数据更加完整,建议将两种持久化机制都开启,用AO F来保证数据不丢失,作为数据恢复的第一选择;用RDB来作不同程度的冷备,在AOF文件都丢失或损坏不可用的时候来快速进行数据的恢复。

2、redis集群

1)replication

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

 

一主多从架构,主节点负责写,并且将数据同步到其他salve节点(异步执行),从节点负责读,主要就是用来做读写分离的横向扩容架构。这种架构的master节点数据一定要做持久化,否则,当master宕机重启之后内存数据清空,那么就会将空数据复制到slave,导致所有数据消失

2)sentinal哨兵

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

 

哨兵是redis集群架构中很重要的一个组件,负责监控redis master和slave进程是否正常工作,当某个redis实例故障时,能够发送消息报警通知给管理员,当master node宕机能够自动转移到slave node上,如果故障转移发生来,会通知client客户端新的master地址。sentinal至少需要3个实例来保证自己的健壮性,并且能够更好地进行quorum投票以达到majority来执行故障转移。

前两种架构方式最大的特点是,每个节点的数据是相同的,无法存取海量的数据。因此哨兵集群的方式使用与数据量不大的情况

3)redis cluster

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

 

redis cluster支撑多master node,每个master node可以挂载多个slave node,如果mastre挂掉会自动将对应的某个slave切换成master。需要注意的是redis cluster架构下slave节点主要是用来做高可用、故障主备切换的,如果一定需要slave能够提供读的能力,修改配置也可以实现(同时也需要修改jedis源码来支持该情况下的读写分离操作)。

redis cluster架构下,master就是可以任意扩展的,直接横向扩展master即可提高读写吞吐量。slave节点能够自动迁移(让master节点尽量平均拥有slave节点),对整个架构过载冗余的slave就可以保障系统更高的可用性。


ehcache

推荐一款nginx+redis+ehcache高并发与高可用缓存架构

 

Tomcat jvm堆内存缓存,主要是抗redis出现大规模灾难。如果redis出现了大规模的宕机,导致nginx大量流量直接涌入数据生产服务,那么最后的tomcat堆内存缓存也可以处理部分请求,避免所有请求都直接流向DB。

具有以下特性:

1、快速轻量

  • 过去几年,诸多测试表明Ehcache是最快的JAVA缓存之一。
  • Ehcache的线程机制是为大型高并发系统设计的。
  • 大量性能测试用例保证Ehcache在不同版本间性能表现得一致性。
  • 很多用户都不知道他们正在用Ehcache,因为不需要什么特别的配置。
  • API易于使用,这就很容易部署上线和运行。
  • 很小的jar包,Ehcache 2.2.3才668kb。
  • 最小的依赖:唯一的依赖就是SLF4J了。

2、伸缩性

  • 缓存在内存和磁盘存储可以伸缩到数G,Ehcache为大数据存储做过优化。
  • 大内存的情况下,所有进程可以支持数百G的吞吐。
  • 为高并发和大型多CPU服务器做优化。
  • 线程安全和性能总是一对矛盾,Ehcache的线程机制设计采用了Doug Lea的想法来获得较高的性能。
  • 单台虚拟机上支持多缓存管理器。
  • 通过Terracotta服务器矩阵,可以伸缩到数百个节点。

3、灵活性

  • Ehcache 1.2具备对象API接口和可序列化API接口。
  • 不能序列化的对象可以使用除磁盘存储外Ehcache的所有功能。
  • 除了元素的返回方法以外,API都是统一的。只有这两个方法不一致:getObjectValue和getKeyValue。这就使得缓存对象、序列化对象来获取新的特性这个过程很简单。
  • 支持基于Cache和基于Element的过期策略,每个Cache的存活时间都是可以设置和控制的。
  • 提供了LRU、LFU和FIFO缓存淘汰算法,Ehcache 1.2引入了最少使用和先进先出缓存淘汰算法,构成了完整的缓存淘汰算法。
  • 提供内存和磁盘存储,Ehcache和大多数缓存解决方案一样,提供高性能的内存和磁盘存储。
  • 动态、运行时缓存配置,存活时间、空闲时间、内存和磁盘存放缓存的最大数目都是可以在运行时修改的。

4、标准支持

  • Ehcache提供了对JSR107 JCACHE API最完整的实现。因为JCACHE在发布以前,Ehcache的实现(如net.sf.jsr107cache)已经发布了。
  • 实现JCACHE API有利于到未来其他缓存解决方案的可移植性。
  • Ehcache的维护者Greg Luck,正是JSR107的专家委员会委员。

5、可扩展性

  • 监听器可以插件化。Ehcache 1.2提供了CacheManagerEventListener和CacheEventListener接口,实现可以插件化,并且可以在ehcache.xml里配置。
  • 节点发现,冗余器和监听器都可以插件化。
  • 分布式缓存,从Ehcache 1.2开始引入,包含了一些权衡的选项。Ehcache的团队相信没有什么是万能的配置。
  • 实现者可以使用内建的机制或者完全自己实现,因为有完整的插件开发指南。
  • 缓存的可扩展性可以插件化。创建你自己的缓存扩展,它可以持有一个缓存的引用,并且绑定在缓存的生命周期内。
  • 缓存加载器可以插件化。创建你自己的缓存加载器,可以使用一些异步方法来加载数据到缓存里面。
  • 缓存异常处理器可以插件化。创建一个异常处理器,在异常发生的时候,可以执行某些特定操作。

6、应用持久化

在VM重启后,持久化到磁盘的存储可以复原数据。

Ehcache是第一个引入缓存数据持久化存储的开源Java缓存框架。缓存的数据可以在机器重启后从磁盘上重新获得。

根据需要将缓存刷到磁盘。将缓存条目刷到磁盘的操作可以通过cache.flush()方法来执行,这大大方便了Ehcache的使用。

7、分布式缓存

从Ehcache 1.2开始,支持高性能的分布式缓存,兼具灵活性和扩展性。

分布式缓存的选项包括:

  • 通过Terracotta的缓存集群:设定和使用Terracotta模式的Ehcache缓存。缓存发现是自动完成的,并且有很多选项可以用来调试缓存行为和性能。
  • 使用RMI、JGroups或者JMS来冗余缓存数据:节点可以通过多播或发现者手动配置。状态更新可以通过RMI连接来异步或者同步完成。
  • Custom:一个综合的插件机制,支持发现和复制的能力。
  • 可用的缓存复制选项。支持的通过RMI、JGroups或JMS进行的异步或同步的缓存复制。
  • 可靠的分发:使用TCP的内建分发机制。
  • 节点发现:节点可以手动配置或者使用多播自动发现,并且可以自动添加和移除节点。对于多播阻塞的情况下,手动配置可以很好地控制。
  • 分布式缓存可以任意时间加入或者离开集群。缓存可以配置在初始化的时候执行引导程序员。
  • BootstrapCacheLoaderFactory抽象工厂,实现了BootstrapCacheLoader接口(RMI实现)。
  • 缓存服务端。Ehcache提供了一个Cache Server,一个war包,为绝大多数web容器或者是独立的服务器提供支持。
  • 缓存服务端有两组API:面向资源的RESTful,还有就是SOAP。客户端没有实现语言的限制。
  • RESTful缓存服务器:Ehcached的实现严格遵循RESTful面向资源的架构风格。
  • SOAP缓存服务端:Ehcache RESTFul Web Services API暴露了单例的CacheManager,他能在ehcache.xml或者IoC容器里面配置。
  • 标准服务端包含了内嵌的Glassfish web容器。它被打成了war包,可以任意部署到支持Servlet 2.5的web容器内。Glassfish V2/3、Tomcat 6和Jetty 6都已经经过了测试。

8、Java EE和应用缓存

为普通缓存场景和模式提供高质量的实现。

阻塞缓存:它的机制避免了复制进程并发操作的问题。

SelfPopulatingCache在缓存一些开销昂贵操作时显得特别有用,它是一种针对读优化的缓存。它不需要调用者知道缓存元素怎样被返回,也支持在不阻塞读的情况下刷新缓存条目。

CachingFilter:一个抽象、可扩展的cache filter。

SimplePageCachingFilter:用于缓存基于request URI和Query String的页面。它可以根据HTTP request header的值来选择采用或者不采用gzip压缩方式将页面发到浏览器端。你可以用它来缓存整个Servlet页面,无论你采用的是JSP、velocity,或者其他的页面渲染技术。

SimplePageFragmentCachingFilter:缓存页面片段,基于request URI和Query String。在JSP中使用jsp:include标签包含。

已经使用Orion和Tomcat测试过,兼容Servlet 2.3、Servlet 2.4规范。

Cacheable命令:这是一种老的命令行模式,支持异步行为、容错。

兼容Hibernate,兼容google App Engine。

基于JTA的事务支持,支持事务资源管理,二阶段提交和回滚,以及本地事务。


经典的缓存+数据库读写的模式

1、读的时候,先读缓存,缓存没有的话,那么就读数据库,然后取出数据后放入缓存,同时返回响应

2、更新的时候,先删除缓存,然后再更新数据库

之所以更新的时候只是删除缓存,因为对于一些复杂有逻辑的缓存数据,每次数据变更都更新一次缓存会造成额外的负担,只是删除缓存,让该数据下一次被使用的时候再去执行读的操作来重新缓存,这里采用的是懒加载的策略。

举个例子,一个缓存涉及的表的字段,在1分钟内就修改了20次,或者是100次,那么缓存跟新20次,100次;但是这个缓存在1分钟内就被读取了1次,因此每次更新缓存就会有大量的冷数据,对于缓存符合28黄金法则,20%的数据,占用了80%的访问量


数据库和redis缓存双写不一致的问题

1、最初级的缓存不一致问题以及解决方案

问题:如果先修改数据库再删除缓存,那么当缓存删除失败来,那么会导致数据库中是最新数据,缓存中依旧是旧数据,造成数据不一致。

解决方案:可以先删除缓存,再修改数据库,如果删除缓存成功但是数据库修改失败,那么数据库中是旧数据,缓存是空不会出现不一致

2、比较复杂的数据不一致问题分析

问题:对于数据发生来变更,先删除缓存,然后去修改数据库,此时数据库中的数据还没有修改成功,并发的读请求到来去读缓存发现是空,进而去数据库查询到此时的旧数据放到缓存中,然后之前对数据库数据的修改成功来,就会造成数据不一致

解决方案:将数据库与缓存更新与读取操作进行异步串行化。当更新数据的时候,根据数据的唯一标识,将更新数据操作路由到一个jvm内部的队列中,一个队列对应一个工作线程,线程串行拿到队列中的操作一条一条地执行。当执行队列中的更新数据操作,删除缓存,然后去更新数据库,此时还没有完成更新的时候过来一个读请求,读到了空的缓存那么可以先将缓存更新的请求发送至路由之后的队列中,此时会在队列积压,然后同步等待缓存更新完成,一个队列中多个相同数据缓存更新请求串在一起是没有意义的,因此可以做过滤处理。等待前面的更新数据操作完成数据库操作之后,才会去执行下一个缓存更新的操作,此时会从数据库中读取最新的数据,然后写入缓存中,如果请求还在等待时间范围内,不断轮询发现可以取到缓存中值就可以直接返回(此时可能会有对这个缓存数据的多个请求正在这样处理);如果请求等待事件超过一定时长,那么这一次的请求直接读取数据库中的旧值

对于这种处理方式需要注意一些问题:

  1. 读请求长时阻塞:由于读请求进行来非常轻度的异步化,所以对超时的问题需要格外注意,超过超时时间会直接查询DB,处理不好会对DB造成压力,因此需要测试系统高峰期QPS来调整机器数以及对应机器上的队列数最终决定合理的请求等待超时时间
  2. 多实例部署的请求路由:可能这个服务会部署多个实例,那么必须保证对应的请求都通过nginx服务器路由到相同的服务实例上
  3. 热点数据的路由导师请求的倾斜:因为只有在商品数据更新的时候才会清空缓存,然后才会导致读写并发,所以更新频率不是太高的话,这个问题的影响并不是特别大,但是的确可能某些机器的负载会高一些


Tags:缓存架构   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
一谈缓存,内心顿时豁然开朗。迫于key-value的形式,总感觉轻风拂面,杨柳依依,一切都尽在我掌握之中。犹如那一眼相中佳人的冲动,脑子里尽是佳人的容颜。 那缓存如果站在网站架构的...【详细内容】
2020-09-29  Tags: 缓存架构  点击:(97)  评论:(0)  加入收藏
三个重要的标准:---大型缓存架构中需要首先说一下:海量数据:支持海量数据缓存,支持大规模数据;高并发:在亿级QPS的场景下,可以做到满足业务需求;高可用:表示redis可以做到并且尽可能...【详细内容】
2020-07-24  Tags: 缓存架构  点击:(68)  评论:(0)  加入收藏
概述对于高并发架构,毫无疑问缓存是最重要的一环,对于大量的高并发,可以采用三层缓存架构来实现,nginx+redis+ehcache,下面对这每个环节做一下介绍。nginx对于中间件nginx常用来...【详细内容】
2019-08-19  Tags: 缓存架构  点击:(392)  评论:(0)  加入收藏
微博日活跃用户1.6亿+,每日访问量达百亿级,面对庞大用户群的海量访问,良好的架构且不断改进的缓存体系具有非常重要的支撑作用。本文大纲1、 微博在运行过程中的数据挑战2、 Fe...【详细内容】
2019-08-02  Tags: 缓存架构  点击:(273)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条