松江做移动网站,开发公司资料员岗位职责及工作内容,重庆手机网站推广报价,睢宁县凌城做网站的Java生鲜电商平台-缓存架构实战 说明#xff1a;在Java生鲜电商中#xff0c;缓存起到了非常重要的作用#xff0c;目前整个项目中才用的是redis做分布式缓存. 缓存集群 缓存集群存在的问题 1.热key 缓存集群中的某个key瞬间被数万甚至十万的并发请求打爆。 2.大value 某个k…   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