缓存预热和热点数据（storm）解决方案

最新推荐文章于 2024-04-16 19:07:20 发布
最新推荐文章于 2024-04-16 19:07:20 发布
阅读量865 收藏
点赞数
分类专栏： 笔记 文章标签： storm 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_40682142/article/details/104954590
版权
本文介绍了Storm在实时数据处理领域的应用，强调其高可伸缩性、数据不丢失和健壮性的特点。Storm的核心概念包括拓扑(topology)、数据源(spout)、处理组件(bolt)以及数据传输单元(tuple)。文章还探讨了流分组策略和并发度，并提及了BaseRichSpout和BaseRichBolt的生命周期方法。最后，文章提及了缓存预热和热点数据处理在实时计算中的重要性。
摘要由CSDN通过智能技术生成

storm的特点：

  • 支撑各种实时类的项目场景：实时处理消息以及更新数据库，基于最基础的实时计算语义和API（实时数据处理领域）
  • 对实时的数据流持续的进行查询或计算，同时将最新的计算结果持续的推送给客户端展示，同样基于最基础的实时计算语义和API（实时数据分析领域）对耗时的查询进行并行化，基于DRPC，即分布式RPC调用，单表30天数据，并行化，每个进程查询一天数据，最后组装结果
  • 高度的可伸缩性：如果要扩容直接加机器，调整storm计算作业的并行度，storm会自动部署更多的进程和线程到其他的机器，无缝快速扩容
  • 数据不丢失的保证：storm的消息可靠机制开启后，可以保证数据不丢失
  • 超强的健壮性：storm比hadoop、spark等大数据类系统健壮的多，因为元数据全部放zookeeper不在内存中，稳定性和可用性很高
  • 使用的便捷性：核心语义非常的简单，开发起来效率很高

Storm的集群架构： Nimbus，Supervisor，ZooKeeper，Worker，Executor，Task

Storm的核心概念：

  • topology ：拓扑，一堆 spout+bolt，就会组成一个topology，一个拓扑涵盖数据源获取/生产+数据处理的所有的代码逻辑
  • spout ：数据源的一个代码组件，可以写一个Java类实现一个spout接口去数据源获取数据，
最低0.47元/天 解锁文章
鱼获飞
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
基于storm实时热点统计的分布式并行缓存预热
03-19
一、基于nginx+lua完成商品详情页访问流量实时上报kafka的开发 ==================================== 在nginx这一层，接收到访问请求的时候，就把请求的流量上报发送给kafka 这样的话，storm才能去消费kafka中的实时的访问日志，然后去进行缓存热数据的统计 用得技术方案非常简单，从lua脚本直接创建一个kafka producer，发送数据到kafka ``` wget https://github.com/doujiang24/lua-resty-kafka/archive/master.zip yum install -y unzip unzip lua-resty-kafka-master.zip cp -rf /usr/local/lua-resty-kafka-master/lib/resty /usr/hello/lualib nginx -s reload local cjson = require("cjson") local producer = require("resty.kafka.producer") local broker_list = { { host = "192.168.31.187", port = 9092 }, { host = "192.168.31.19", port = 9092 }, { host = "192.168.31.227", port = 9092 } } local log_json = {} log_json["headers"] = ngx.req.get_headers() log_json["uri_args"] = ngx.req.get_uri_args() log_json["body"] = ngx.req.read_body() log_json["http_version"] = ngx.req.http_version() log_json["method"] =ngx.req.get_method() log_json["raw_reader"] = ngx.req.raw_header() log_json["body_data"] = ngx.req.get_body_data() local message = cjson.encode(log_json); local productId = ngx.req.get_uri_args()["productId"] local async_producer = producer:new(broker_list, { producer_type = "async" }) local ok, err = async_producer:send("access-log", productId, message) if not ok then ngx.log(ngx.ERR, "kafka send err:", err) return end ``` 两台机器上都这样做，才能统一上报流量到kafka ``` bin/kafka-topics.sh --zookeeper 192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181 --topic access-log --replication-factor 1 --partitions 1 --create bin/kafka-console-consumer.sh --zookeeper 192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181 --topic access-log --from-beginning ``` （1）kafka在187上的节点死掉了，可能是虚拟机的问题，杀掉进程，重新启动一下 nohup bin/kafka-server-start.sh config/server.properties & （2）需要在nginx.conf中，http部分，加入resolver 8.8.8.8; （3）需要在kafka中加入advertised.host.name = 192.168.31.187，重启三个kafka进程 （4）需要启动eshop-cache缓存服务，因为nginx中的本地缓存可能不在了 二、基于storm+kafka完成商品访问次数实时统计拓扑的开发 ==============
Redis缓存及热点 缓 key问题解决方案
最新发布
08-07
主要介绍了Redis缓存及热点key问题解决方案,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下； 今天又学到了很多，感觉雪崩和穿透很有意思理解起来也比较清晰，...
Redis解决多卖或者少卖_当下热点词再学：redis缓存预热、更新、降级，限流
weixin_39680208的博客
10-26 138
学习还是要有的，梦想不能破灭，你说呢？缓存预热系统冷启动当系统上线时，缓存内还没有数据，如果直接提供给用户使用，每个请求都会穿过缓存去访问底层数据库，如果并发大的话，很有可能在上线当天就会宕机，这种情况就叫“系统冷启动”，因此我们需要在上线前先将数据库内的热点数据缓存至Redis内再提供出去使用，这种操作就成为"缓存预热"。解决方案提前给redis中嵌入部分数据，再提供服务。这宛如一句f...
16.redis缓存预热（基于storm）
kang123488的博客
03-10 3019
0、缓存预热缓存冷启动，redis启动后，一点数据都没有，直接就对外提供服务了，mysql就裸奔（1）提前给redis中灌入部分数据，再提供服务（2）肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二根本redis容纳不下所有的数据（3）需要根据当天的具体访问情况，实时统计出访问频率较高的热数据（4）然后将访问频率较高的热数据写入redis中，肯定是热数据也比较多，...
缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级、缓存热点 key
河湾
04-11 1931
关于Redis经常被问到的问题：缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级、缓存热点 key等概念的入门及简单解决方案。 一、缓存雪崩 缓存雪崩我们可以简单的理解为：由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一...
针对热点数据的处理
weixin_54256249的博客
08-22 946
针对热点数据的处理
基于Java和Redis的shiro缓存集中式解决方案设计源码
05-31
shiro缓存集中式解决方案项目源码，共63个文件，全部采用Java语言编写，涉及多种文件类型如Java源代码、XML...该项目是一个基于Java和Redis的shiro缓存集中式解决方案设计，旨在提供一个高效、稳定的缓存管理解决方案。
AutoLoadCache缓存管理解决方案-其他
06-12
AutoLoadCache 是基于AOP+Annotation等技术实现的高效的缓存管理解决方案，实现缓存与业务逻辑的解耦，并增加异步刷新及“拿来主义机制”，以适应高并发环境下的使用。 现在使用的缓存技术很多，比如Redis、 ...
当下热点词再学：redis缓存预热、更新、降级，限流
看，未来的博客
09-03 5871
愿打开此篇对你有所帮助。
Redis 缓存预热、预热数据选取策略、缓存保温、性能边界
EasyChillの博客
04-16 885
基于上面的性能边界，我们需要根据自身的业务特性和需求来做一些选择和妥协。
缓存预热！真香
m0_67597657的博客
02-12 1839
在上面的例子中，我们使用 Caffeine.newBuilder().refreshAfterWrite(1, TimeUnit.MINUTES) 配置了缓存的自动刷新机制，即每个缓存项在写入后的1分钟内，如果有读请求，Caffeine 会自动触发数据的刷新。在启动过程中预热有一个问题，那就是一旦启动之后，如果需要预热新的数据，或者需要修改数据，就不支持了，那么，在应用的运行过程中，我们也是可以通过定时任务来实现缓存的更新预热的。减少冷启动影响：当系统重启或新启动时，缓存是空的，这被称为冷启动。
基于storm实时热点统计的分布式并行缓存预热解决方案
qq_41793222的博客
06-08 1038
缓存冷启动，redis启动后，一点数据都没有，直接就对外提供服务了，mysql就裸奔（1）提前给redis中灌入部分数据，再提供服务（2）肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二根本redis容纳不下所有的数据（3）需要根据当天的具体访问情况，实时统计出访问频率较高的热数据（4）然后将访问频率较高的热数据写入redis中，肯定是热数据也比较多，得多个服务并...
Redis缓存预热，该如何实现
weixin_43114209的博客
03-19 1842
缓存预热是一种在程序启动或缓存失效之后，主动将热点数据加载到缓存中的策略。这样，在实际请求到达程序时，热点数据已经存在于缓存中，从而减少了缓存穿透和缓存击穿的情况，也缓解了SQL服务器的压力。
【Redis】缓存预热、缓存雪崩和缓存击穿
愿万事胜意
07-25 786
缓存预热 现象： 服务器启动后迅速宕机。 问题排查 请求数量较高 主从之间数据吞吐量较大，数据同步操作频度较高 解决方案 前置准备工作： 日常例行统计数据访问记录，统计访问频度较高的热点数据 如果热点数据量较大，利用LRU数据删除策略，构建数据留存队列（手工维护或storm+kafka等） 启动前准备工作： 将统计结果中的数据分类，根据级别，redis优先加载级别较高的热点数据 利用分布式多服务器同时进行数据读取，提速数据加载过程 实施： 使用脚本程序固定触发数据预热过程 如果条件允许，使用CDN（内容
关于实时更新的热点数据，高QPS场景的缓存建议（Redis）
邪恶八进制
11-18 1064
关于实时更新的热点数据，高QPS场景的缓存建议（Redis）
高并发高可用复杂系统中的缓存架构(二十一)缓存热点数据 预热、热数据 storm讲解
liuerchong的博客
07-18 1034
接下来，这个商品详情页缓存架构，缓存预热问题和解决方案，缓存热点数据可能导致整个系统崩溃的问题，以及解决方案 缓存相关的「热」：预热、热数据 在解决方案和架构设计中，会引入大数据的实时计算的技术 storm。为什么要引入这个 storm，难道必须是 storm 吗？我们后面去讲解那个解决方案的时候再说 缓存架构和 storm 的关系 因为有些热点数据相关的一些实时处理的一些方案，比如快速预热，热点数据的实时感知和快速降级，全部要用到 storm 因为我们可能需要实时的去计算出热点缓存数据，我们的业
1.缓存架构和storm的关系
kang123488的博客
03-10 271
缓存架构和storm的关系 有些热点数据相关的一些实时处理的一些方案，比如快速预热，热点数据的实时感知和快速降级，全部要用到storm 因为我们可能需要实时的去计算出热点缓存数据，实时计算，亿级流量，高并发，大量的请求过来 这个时候，你要做一些实时的计算，那么必须涉及到分布式的一些技术，分布式的技术，才能处理高并发，大量的请求 目前在时候计算的领域，最成熟的大数据的技术，就是storm ...
热点商品更新缓慢的一种优化方案
gt9000的博客
02-27 343
文章内容 其实本文没有结论,对优化方案持开发态度。类似秒杀的优化核心是削峰填谷，排队处理。本文只是考虑如何优化DB层面的并发更新的速度。 背景 因为有赞接入快手以及部分商家的热卖商品的交易流程走的是正常的商品交易途径，但是他们具有秒杀的属性。发生热点商品售卖对应的数据库监控如下图: 数据库的qps 瞬间增长4倍，tps 则暴涨30-40倍，活跃会话暴涨导致正常的请求被堵住(都在处理扣减库存以及库存...
ASP.NET缓存策略与Memcached分布式解决方案
"ASP.NET缓存解决方案和最佳实践主要探讨了如何在ASP.NET环境中提高应用程序性能，通过缓存策略减少数据库交互和计算成本。本文涵盖了ASP.NET内置的页输出缓存和应用程序缓存，以及针对分布式环境的Memcached缓存...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值