Java生鲜电商平台-缓存架构实战

Java生鲜电商平台-缓存架构实战

说明:在Java生鲜电商中,缓存起到了非常重要的作用,目前整个项目中才用的是redis做分布式缓存.

缓存集群

缓存集群存在的问题

1.热key
缓存集群中的某个key瞬间被数万甚至十万的并发请求打爆。

2.大value
某个key对应的value可能有GB级的大小,导致查询value的时候导致网络相关的故障问题。

缓存集群作用

在缓存里放一些平时不怎么变动的数据,然后用户在查询大量的平时不怎么变动的数据的时候,可以直接从缓存里走了。缓存集群的并发能力是很强的,而且读缓存的性能是很高的。

缓存实践案例

  • 假设系统每秒有2万请求,但是其中90%都是读请求,假如每秒1.8万请求都是在读一些不太变化的数据。那此时你把这些数据都放在数据库里,然后每秒发送2万请求到数据库上读写数据,感受一下这样合适?
  • 如果要用数据库承载每秒2万请求的话,那很可能就得搞分库分表 + 读写分离。
  • 那得分3个主库,承载每秒2000的写入请求,然后每个主库挂3个从库,一共9个从库承载每秒1.8万的读请求。
  • 这样的话,就需要一共是12台高配置的数据库服务器,这是很耗费钱的,成本非常高,很不合适。
  • 因此,可以把平时不太变化的数据放在缓存集群里,缓存集群可以采用2主2从,主节点用来写入缓存,从节点用来读缓存。
  • 以缓存集群的性能,2个从节点完全可以用来承载每秒1.8万的大量读请求,然后3个数据库主库就是承载每秒2000的写请求和少量其他读请求就OK了(数据一致性问题)。
  • 这样一来,耗费的机器瞬间变成了4台缓存机器 + 3台数据库机器 = 7台机器,是不是比之前的12台机器减少了很大的资源开销?
  • 缓存其实在系统架构里是非常重要的组成部分。很多时候,对于那些很少变化但是大量高并发读的数据,通过缓存集群来抗高并发读,是非常合适的。

热点缓存

  • 所谓热点缓存问题就是突然因为莫名的原因,出现大量的用户访问同一条缓存数据。碰巧这些key都存在于一台缓存机器上。
  • 假设每秒突然奔过来20万请求到这台机器上,那台被20万请求指向的缓存机器就会过度操劳而宕机的。
  • 读请求发现读不到数据,会从数据库里提取原始数据,然后放入剩余的其他缓存机器里去。但是接踵而来的每秒20万请求,会再次压垮其他的缓存机器。
  • 以此类推,最终导致缓存集群全盘崩溃,引发系统整体宕机。

基于流式计算技术的缓存热点自动发现

  • 其实这里关键的一点,就是对于这种热点缓存,你的系统需要能够在热点缓存突然发生的时候,直接发现他,然后瞬间立马实现毫秒级的自动负载均衡。
  • 一般出现缓存热点的时候,每秒并发肯定是很高的,可能每秒都几十万甚至上百万的请求量过来,这都是有可能的。
  • 所以,此时完全可以基于大数据领域的流式计算技术来进行实时数据访问次数的统计,比如storm、spark streaming、flink。
  • 一旦在实时数据访问次数统计的过程中,比如发现一秒之内,某条数据突然访问次数超过了1000,就直接立马把这条数据判定为是热点数据,可以将这个发现出来的热点数据写入比如zookeeper中(监听事件)。
  • 流式计算系统在进行数据访问次数统计的时候,会不会也存在说单台机器被请求每秒几十万次的问题呢?否!!!
  • 流式计算技术,尤其是storm这种系统,他可以做到同一条数据的请求过来,先分散在很多机器里进行本地计算,最后再汇总局部计算结果到一台机器进行全局汇总。
  • 所以几十万请求可以先分散在比如100台机器上,每台机器统计了这条数据的几千次请求。
  • 然后100条局部计算好的结果汇总到一台机器做全局计算即可,所以基于流式计算技术来进行统计是不会有热点问题的。

热点缓存自动加载为JVM本地缓存

  • 我们自己的系统可以对zookeeper指定的热点缓存对应的znode进行监听,如果有变化立马就可以感知到了。
  • 此时系统层就可以立马把相关的缓存数据从数据库加载出来,然后直接放在自己系统内部的本地缓存里即可。
  • 这个本地缓存,用ehcache、hashmap,其实都可以,一切看自己的业务需求。我们这里主要说的就是将缓存集群里的集中式缓存,直接变成每个系统自己本地实现缓存即可,每个系统本地是无法缓存过多数据的。
  • 因为一般这种普通系统单实例部署机器可能就一个4核8G的机器,留给本地缓存的空间是很少的,所以用来放这种热点数据的本地缓存是最合适的,刚刚好。
  • 假设系统层集群部署了100台机器,此时你100台机器瞬间在本地都会有一份热点缓存的副本。
  • 然后接下来对热点缓存的读操作,直接系统本地缓存读出来就给返回了,不用再走缓存集群了。
  • 这样的话,变成100台机器每台机器承载数千请求,那么那数千请求就直接从机器本地缓存返回数据了,这是没有问题的。

限流熔断保护

  • 在每个系统内部,还应该专门加一个对热点数据访问的限流熔断保护措施。
  • 每个系统实例内部,都可以加一个熔断保护机制,假设缓存集群最多每秒承载4万读请求,那么你一共有100个系统实例。
  • 应该提前限制好,每个系统实例每秒最多请求缓存集群读操作不超过400次,一超过就可以熔断掉,不让请求缓存集群,直接返回一个空白信息,然后用户稍后会自行再次重新刷新页面之类的。
  • 通过系统层自己直接加限流熔断保护措施,可以很好的保护后面的缓存集群、数据库集群之类的不要被打死。

原文地址:https://www.cnblogs.com/jurendage/p/11269241.html

时间: 2024-09-29 10:24:36

Java生鲜电商平台-缓存架构实战的相关文章

Java生鲜电商平台-电商中海量搜索ElasticSearch架构设计实战与源码解析

Java生鲜电商平台-电商中海量搜索ElasticSearch架构设计实战与源码解析 生鲜电商搜索引擎的特点 众所周知,标准的搜索引擎主要分成三个大的部分,第一步是爬虫系统,第二步是数据分析,第三步才是检索结果.首先,电商的搜索引擎并没有爬虫系统,因为所有的数据都是结构化的,一般都是微软的数据库或者 Oracle 的数据库,所以不用像百度一样用「爬虫」去不断去别的网站找内容,当然,电商其实也有自己的「爬虫」系统,一般都是抓取友商的价格,再对自己进行调整. 第二点,就是电商搜索引擎的过滤功能其实比

Java生鲜电商平台-电商支付流程架构实战

Java生鲜电商平台-电商支付流程架构实战 说明:我一直秉承的就是接地气的业务架构实战.我的文章都有一个这样的核心. 1. 业务场景 2. 解决问题. 3.代码实现. 4.代码重构. 5.总结与复盘. 6.缺点与防范 一.场景描述 想必大家都曾遇到过这个问题,在电商购物的过程中,已经走到了最后一步:去支付.这个时候突然意识到商品数量不对,或者收货信息选错. 除此之外,用户还存在之下返回的原因: 误点击,也就是说用户还是想买的: 犹豫中点了返回,想买的欲望不是十分坚决: 坚决不买了. 二.可选方案

Java开源生鲜电商平台-系统架构与技术选型(源码可下载)

Java开源生鲜电商平台-系统架构与技术选型(源码可下载) 1.  硬件环境 公司服务器 2.   软件环境 2.1  操作系统 Linux CentOS 6.8系列 2.2 反向代理/web服务器 Nginx 2.3 应用服务器 Jdk7+ Tomcat 7 2.4 数据库 Mysql 5.6.x 2.5 消息队列(可选) Rabbitmq/rocketmq 2.6 缓存(可选) Redis 3.x 3.工程构建和管理工具 1.Maven 开发人员已经很熟悉了.此处略 2.Jenkins Je

Java生鲜电商平台-高并发核心技术订单与库存实战

Java生鲜电商平台-高并发核心技术订单与库存实战 一. 问题 一件商品只有100个库存,现在有1000或者更多的用户来购买,每个用户计划同时购买1个到几个不等商品. 如何保证库存在高并发的场景下是安全的? (1)不多发 (2)不少发 二. 下单的步骤 (1)下单 (2)下单同时预占库存 (3)支付 (4)支付成功真正减扣库存 (5)取消订单 (6)回退预占库存 三. 什么时候进行预占库存? (1)方案一:加入购物车的时候去预占库存 (2)方案二:下单的时候去预占库存 (3)方案三:支付的时候去

Java生鲜电商平台-电商中"再来一单"功能架构与详细设计(APP/小程序)

Java生鲜电商平台-电商中"再来一单"功能架构与详细设计(APP/小程序) 说明:在实际的业务场景中(无论是TO B还是TO C)不管是休闲食品.餐饮.水果.日用百货.母婴等高频购买行业,还是其他行业,“再来一单”都能够大大缩短买家再次下单的流程,促进转化. 于是就有了针对生鲜电商平台的“再来一单”功能,买家只要在订单列表.订单详情或者支付成功中点击“再来一单”,就可以把订单中的商品再次加入购物车,方便快捷,高效. 上面的话可以总结出来"再来一单“以下几个信息.      

Java生鲜电商平台-微服务架构概述

Java生鲜电商平台-微服务架构概述 单体架构存在的问题 在传统的软件技术架构系统中,基本上将业务功能集中在单一应用内,或者是单一进程中.尽管现代化的软件架构理论以及设计原则已推广多年,但实际技术衍化的速度迟缓并且变革动力不足. 其中的原因存在着复杂性以及多样性,我想主要的原因是没有一套整体的解决方案能够让工程师在面临稳定性风险下,毅然决然地实施系统重构.当系统应用规模随着业务的迅速发展时,系统的重要性愈发突出,开发人员将对系统的改造尤为敏感,从之前的徘徊犹豫,随之变得更加保守,只能延续过去的技

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析

Java生鲜电商平台-SpringCloud微服务架构中网络请求性能优化与源码解析 说明:Java生鲜电商平台中,由于服务进行了拆分,很多的业务服务导致了请求的网络延迟与性能消耗,对应的这些问题,我们应该如何进行网络请求的优化与处理呢? 到底有没有一些好的建议与方案呢? 下面这个文章将揭晓上面的问题,让你对SpringCloud微服务网络请求性能有一个全新的认识. 目录简介 01.网络请求异常分类 02.开发中注意问题 03.原始的处理方式 04.如何减少代码耦合性 05.异常统一处理步骤 06

Java生鲜电商平台-生鲜售后系统的退款架构设计与代码分享

说明:任何一个电商行业都涉及到退货与退款的问题,但是生鲜电商行业还设有一个显著的特点,那就是换货.在人性面前,各种各样的退货,退款,换货的售后问题,层出不穷,那么应该如何架构与设计呢?请看下文. 由于涉及到的东西比较多,目前只讲退款的架构设计与代码分享. 退款,是一个易造成负体验的业务产品.原因是商户对于退款的要求务必退款成功.高效.快,而且又得很好地支撑业务,否则就容易招来吐槽. 退款,一个看似简单,但充满复杂性的产品. 要想做好退款系统,我们必须深入的了解业务发展趋势,将客户诉求与现状业务结

Java生鲜电商平台-小程序或者APP优惠券的设计与源码实战

Java生鲜电商平台-小程序或者APP优惠券的设计与源码实战 说明:Java生鲜电商平台-小程序或者APP优惠券的设计与源码实战,优惠券是一种常见的促销方式,在规定的周期内购买对应商品类型和额度的商品时,结算时满足一定条件会减免一定金额.通过发放优惠券,引导用户购买相应的商品,在下单的时候抵扣一定的费用,达到促销.提高客单价的目标. 优惠券不论在线上还是线下,适用范围都比较广泛.例如滴滴发的专车券.外卖平台发的外卖券.京东淘宝的优惠券等. 1.优惠券的类型和应用场景 优惠券有多种分类方式,按照使