10-redis主从复制：对项目的主从redis架构进行QPS压测以及水平扩容支撑更高QPS

最新推荐文章于 2024-09-25 07:00:00 发布
最新推荐文章于 2024-09-25 07:00:00 发布
阅读量367 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： # redis的应用 # 【缓存学习】-大型高性能与高可用缓存架构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_40663800/article/details/90316427
本文介绍了使用redis-benchmark工具对Redis进行基准压测，以获取其性能和QPS。详细说明了读写分离架构压测的参数设置，并给出不同操作的测试结果。还提到不同服务器配置下QPS差异大，生产环境受网络影响。此外，介绍了通过水平扩容Redis读节点提升吞吐量的方法。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >


你如果要对自己刚刚搭建好的redis做一个基准的压测，测一下你的redis的性能和QPS（query per second）

redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测

1、对redis读写分离架构进行压测，单实例写QPS+单实例读QPS

在redis-3.2.8/src

./redis-benchmark -h 192.168.31.187，直接使用该工具进行测试，参数：

-c <clients>       Number of parallel connections (default 50)  设置多少客户端，默认50
-n <requests>      Total number of requests (default 100000)    设置总请求量，默认100000
-d <size>          Data size of SET/GET value in bytes (default 2) 设置每个数据的大小，默认2字节

根据你自己的高峰期的访问量，在高峰期，瞬时最大用户量会达到10万+，-c 100000，-n 10000000，-d 50

各种基准测试，直接出来

1核1G，虚拟机

====== PING_INLINE ======
  100000 requests completed in 1.28 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.78% <= 1 milliseconds
99.93% <= 2 milliseconds
99.97% <= 3 milliseconds
100.00% <= 3 milliseconds
78308.54 requests per second

====== PING_BULK ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.87% <= 1 milliseconds
100.00% <= 1 milliseconds
76804.91 requests per second

====== SET ======
  100000 requests completed in 2.50 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

5.95% <= 1 milliseconds
99.63% <= 2 milliseconds
99.93% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40032.03 requests per second

====== GET ======
  100000 requests completed in 1.30 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.73% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
76628.35 requests per second

====== INCR ======
  100000 requests completed in 1.90 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

80.92% <= 1 milliseconds
99.81% <= 2 milliseconds
99.95% <= 3 milliseconds
99.96% <= 4 milliseconds
99.97% <= 5 milliseconds
100.00% <= 6 milliseconds
52548.61 requests per second

====== LPUSH ======
  100000 requests completed in 2.58 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

3.76% <= 1 milliseconds
99.61% <= 2 milliseconds
99.93% <= 3 milliseconds
100.00% <= 3 milliseconds
38684.72 requests per second

====== RPUSH ======
  100000 requests completed in 2.47 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

6.87% <= 1 milliseconds
99.69% <= 2 milliseconds
99.87% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40469.45 requests per second

====== LPOP ======
  100000 requests completed in 2.26 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

28.39% <= 1 milliseconds
99.83% <= 2 milliseconds
100.00% <= 2 milliseconds
44306.60 requests per second

====== RPOP ======
  100000 requests completed in 2.18 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

36.08% <= 1 milliseconds
99.75% <= 2 milliseconds
100.00% <= 2 milliseconds
45871.56 requests per second

====== SADD ======
  100000 requests completed in 1.23 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.94% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
81168.83 requests per second

====== SPOP ======
  100000 requests completed in 1.28 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.80% <= 1 milliseconds
99.96% <= 2 milliseconds
99.96% <= 3 milliseconds
99.97% <= 5 milliseconds
100.00% <= 5 milliseconds
78369.91 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 2.47 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

15.29% <= 1 milliseconds
99.64% <= 2 milliseconds
99.94% <= 3 milliseconds
100.00% <= 3 milliseconds
40420.37 requests per second

====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 3.69 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

30.86% <= 1 milliseconds
96.99% <= 2 milliseconds
99.94% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
27085.59 requests per second

====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 10.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.03% <= 1 milliseconds
5.90% <= 2 milliseconds
90.68% <= 3 milliseconds
95.46% <= 4 milliseconds
97.67% <= 5 milliseconds
99.12% <= 6 milliseconds
99.98% <= 7 milliseconds
100.00% <= 7 milliseconds
9784.74 requests per second

====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 14.71 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 1 milliseconds
0.07% <= 2 milliseconds
1.59% <= 3 milliseconds
89.26% <= 4 milliseconds
97.90% <= 5 milliseconds
99.24% <= 6 milliseconds
99.73% <= 7 milliseconds
99.89% <= 8 milliseconds
99.96% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 10 milliseconds
6799.48 requests per second

====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 18.56 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 2 milliseconds
0.23% <= 3 milliseconds
1.75% <= 4 milliseconds
91.17% <= 5 milliseconds
98.16% <= 6 milliseconds
99.04% <= 7 milliseconds
99.83% <= 8 milliseconds
99.95% <= 9 milliseconds
99.98% <= 10 milliseconds
100.00% <= 10 milliseconds
5387.35 requests per second

====== MSET (10 keys) ======
  100000 requests completed in 4.02 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.01% <= 1 milliseconds
53.22% <= 2 milliseconds
99.12% <= 3 milliseconds
99.55% <= 4 milliseconds
99.70% <= 5 milliseconds
99.90% <= 6 milliseconds
99.95% <= 7 milliseconds
100.00% <= 8 milliseconds
24869.44 requests per second

我们这个读写分离这一块的第一讲

大部分情况下来说，看你的服务器的机器性能和配置，机器越牛逼，配置越高

单机上十几万，单机上二十万

很多公司里，给一些低配置的服务器，操作复杂度

大公司里，都是公司会提供统一的云平台，比如京东、腾讯、BAT、其他的一些、小米、美团

虚拟机，低配

搭建一些集群，专门为某个项目，搭建的专用集群，4核4G内存，比较复杂的操作，数据比较大

几万，单机做到，差不多了

redis提供的高并发，至少到上万，没问题

几万~十几万/二十万不等

QPS，自己不同公司，不同服务器，自己去测试，跟生产环境还有区别

生产环境，大量的网络请求的调用，网络本身就有开销，你的redis的吞吐量就不一定那么高了

QPS的两个杀手：一个是复杂操作，lrange，挺多的; value很大，2 byte，我之前用redis做大规模的缓存

做商品详情页的cache，可能是需要把大串数据，拼接在一起，作为一个json串，大小可能都几k，几个byte

2、水平扩容redis读节点，提升度吞吐量

就按照上一节课讲解的，再在其他服务器上搭建redis从节点，单个从节点读请QPS在5万左右，两个redis从节点，所有的读请求打到两台机器上去，承载整个集群读QPS在10万+
 

Redis高并发高可用—主从复制
weixin_53300731的博客
12-04 452
介绍了Redis主从复制，可以实现相同数据的多个Redis副本。
11. 【实战】对项目的主从redis架构进行QPS压测&&水平扩容支撑更高QPS
咸鱼翻面的博客
02-15 564
目录redis-benchmark注意问题水平扩容 对刚刚搭建好的redis做一个基准的压测，测一下redis的性能和QPS（query per second） redis-benchmark redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测。 对redis读写分离架构进行压测，单实例写QPS+单实例读QPS...
Redis_07_之主从架构QPS压测
superbeyone
02-25 419
QPS：query per second 使用redis自己提供的redis-benchmark压测工具测试 参数说明： -c &amp;lt;clients&amp;gt; Number of parallel connections (default 50) -n &amp;lt;requests&amp;gt; Total number of requests (default 100000) -d ...
redis主从复制测试
xtkinglong的专栏
10-13 306
以前已经介绍过redis的安装与启动，现在开始进行小小的demo进行主从复制 1、建立3个端口redis6379、6380和6381 2、怎么建大家都知道了吧，cd /home/soft/redis-6.0.8/utils，进行./install_server.sh，具体操作找前面的博客吧，总之就是一句话，一路按着回车键，创建端口不是梦 3、去你的路径下，再分别进入6379、6380和6381，rm -fr *，将里面的持久化内容删干净（方便测试）4、在随便建立一个目录，放*.conf文件，测试么，和
Redis -主从复制
weixin_30729609的博客
11-18 122
特点 Redis 的主从复制（master-slave replication）功能简单易用，特点如下： 一个主服务器可以有多个从服务器 从服务器可以有自己的从服务器 复制数据时，主服务器和从服务器都不会阻塞，可以处理连接请求 复制完成后，从服务器删除旧版本数据集并载入新版本数据集时， 连接请求会被阻塞 redis 的默认配置中，从服务器是只读的...
数据库优化
weixin_43856737的博客
04-15 163
数据库优化
Redis主从复制技术：理论基础、运行逻辑与应用场景
禅与计算机程序设计的艺术
10-29 1230
主从复制就是将主节点(master)的数据复制到从节点(slave)，让多个节点承载用户的请求。1. 数据冗余:主节点的数据都会同步到从节点上，所以多个节点都会有相同数据，从而实现数据冗余。2. 故障恢复:主节点出现故障后，从节点可以继续承载用户的请求，做到服务上的冗余。3. 负载均衡:主从复制机制实现主节点接收用户写请求，从节点承载用户读请求，对于读多写少的场景，这种机制可以大大提高redis的并发量。4. 高负载:主从复制+哨兵机制可以实现高负载，这点后文会介绍到。
Redis实战--Redis的数据持久化与搭建Redis主从复制模式和搭建Redis的哨兵模式
天冬忘忧的博客
09-25 1277
Redis是基于内存的数据库，这意味着一旦服务器宕机，内存中的数据就会丢失。为了解决这个问题，Redis提供了数据持久化的机制，包括RDB和AOF两种方式。此外，为了提高数据的可用性和可扩展性，Redis还支持主从复制和哨兵模式。本文将详细介绍Redis的数据持久化机制、如何搭建Redis主从复制模式以及如何搭建Redis的哨兵模式。
Redis主从复制详解
09-09
主从复制是Redis高可用架构的基础，它提供了数据安全、读写分离和故障转移的能力。正确配置和管理Redis主从复制，对于构建稳定、高效的分布式系统至关重要。通过不断学习和实践，我们可以更好地理解和利用这一功能，...
Redis如何做到高性能
weixin_41011482的博客
06-25 618
1、通过主从架构实现读写分离 单机redis的QPS，也就是每秒可以处理多少个请求，最多也就几万。如果你的机器配置特别高，性能特别好，并且操作处理没什么复杂性，才可能会更高一些。 那么这个时候QPS想要达到10万+，可以通过主从架构+读写分离来实现QPS的增加，redis master主机负责处理写的请求，其他主机负责读数据的请求，这样一来，一台主机可以处理5万请求，那2台主机不就可以处理10万请求了，想要20万也可以，再增加两台主机就是了。 如图： 2、Redis replication的基本原理 既然
对主从 Redis 进行 QPS 压测
u011679955的博客
01-24 1186
1、对redis读写分离架构进行压测，单实例写QPS+单实例读QPS   redis-3.2.8/src   ./redis-benchmark -h 192.168.31.187   -c &lt;clients&gt; Number of parallel connections (default 50) // 并发 -n &lt;requests...
Redis服务支持5000万的QPS，有什么好的思路？
u011277123的博客
12-13 6835
5000W QPS 量确实比较大，在当前的架构下，就以开源的redis cluster为例，假设每个节点跑8W QPS，那么也需要 5000/8 = 600+的节点，而Gossip在超过百级别节点的时候成本就越来越高，表现也越来越差了，所以用redis cluster来解这个问题不大靠谱，不靠谱的主要原因是Gossip的通信机制。 对于几个大厂来说，阿里云ApsaraDB for Redis/A
深度解析单线程的 Redis 如何做到每秒数万 QPS 的超高处理能力
资料qun832218493
05-10 406
有一次去面试服务器端岗位，面试官问我有一个连接过来，你该怎么编程处理它。我答道：“主线程收到请求后，创建一个子线程处理。” 面试官接着问，那如果有一千个连接同时来呢？我说“那就多创建一点线程，搞个线程池”。面试官继续追问如果一万个呢？我答道:“......不会...”。 事实上，服务器端只需要单线程可以达到非常高的处理能力，Redis 就是一个非常好的例子。仅仅靠单线程就可以支撑起每秒数万 QPS 的高处理能力。今天我们就来带大家看看 Redis 核心网络模块的内部实现，学习下 Redis 是如何做到如此
为什么 Redis 单线程能达到百万+QPS？
Java技术栈，分享最主流的Java技术
06-10 473
Java技术栈www.javastack.cn打开网站看更多优质文章作者：在江湖中codinghttps://juejin.im/post/5e6097846fb9a07c9f3fe74...
深度解析单线程的 Redis 如何做到每秒数万 QPS 的超高处理能力！
AI研习社
05-23 492
开发者（KaiFaX）面向全栈工程师的开发者专注于前端、Java/Python/Go/PHP的技术社区大家好，我是若飞！今天开篇先给大家讲个飞哥自己的小故事。我在学校和刚毕业头一年主要从事的客户端开发，那时候对服务器端编程还不擅长。有一次去面试服务器端岗位，面试官问我有一个连接过来，你该怎么编程处理它。我答道：“主线程收到请求后，创建一个子线程处理。” 面试官接着问，那如...
redis的哨兵模式测试
蓝天之枫
06-10 9175
上篇文章我们说到，一主二从的模式，如果主机挂掉，从机等待主机连上之后，继续成为主机的slave。但是这样会影响我们业务的正常运转呀，我们怎么来做呢？目前的我的服务器：192.128.116.128 6379为主：192.128.116.129 6380为从：192.128.116.130 6381为从：现在我们让主机挂掉另外两台从机在等待，我们在一台从机6380上执行命令 SLAVEOF no o...
Redis-Cluster 集群搭建（三主三从）
qq_16681279的博客
03-16 2470
搭建Ruby yum install ruby yum install rubygems 安装redis 和 gcc,tcl [root@izwz92bdx6sqk095sd98lez src]# yum install -y gcc-c++ [root@izwz92bdx6sqk095sd98lez src]# wget http://download.redis.io/re...
redis压力测试
张金玉的专栏
12-20 2555
参考网址: https://blog.youkuaiyun.com/yangcs2009/article/details/50781530 一yum 安装redis [root@testceph ~]# yum install epel-release -y [root@testceph ~]# yum install redis -y [root@testceph bin]# systemctl sta...
实时热榜架构：Redis SortedSet分片+Pipeline，5秒级更新，10万QPS
最新发布
08-15
<think>我们正在设计一个基于Redis Sorted Set分片和Pipeline的实时热榜架构，要求支持5秒更新周期和10万QPS的读取请求。以下是一个优化方案： ### 一、架构核心设计 1. **数据分片策略** - 使用**产品线ID+时间窗口**作为分片键 - 每个分片存储1小时数据（减少ZSET内存压力） - 分片数计算：$shards = \frac{\text{总数据量}}{\text{单ZSET最大容量}}$ 2. **读写分离模型** ```mermaid graph TD A[客户端] --> B[读写分离代理] B -->|写请求| C[主集群] B -->|读请求| D[从集群] C --> E[分片1-ZSET] C --> F[分片2-ZSET] D --> G[缓存层] ``` ### 二、Sorted Set优化技巧 1. **内存控制** - 启用`zset-max-ziplist-entries 1024`[^3] - 使用`ZRANGEBYSCORE`替代全量查询 ```redis ZRANGEBYSCORE hotlist:2023091510 -inf +inf WITHSCORES LIMIT 0 100 ``` 2. **分片算法** $$shard\_index = (product\_id + \lfloor timestamp/3600 \rfloor) \% shard\_num$$ ```java int getShardKey(String productId, long timestamp) { long hourWindow = timestamp / 3600000; return (productId.hashCode() + hourWindow) % SHARD_NUM; } ``` ### 三、Pipeline批量更新 1. **更新流程** ```mermaid sequenceDiagram 业务系统->>+消息队列: 发送行为事件 消息队列->>+处理器: 批量消费(5秒窗口) 处理器->>Redis: Pipeline执行 loop 每个分片 Redis-->>处理器: ZINCRBY更新分数 end ``` 2. **Pipeline脚本示例** ```lua -- KEYS[1]:分片键, ARGV[1]:更新数据JSON local items = cjson.decode(ARGV[1]) for _, item in ipairs(items) do redis.call('ZINCRBY', KEYS[1], item.score, item.id) end ``` ### 四、性能压测数据 | 操作类型 | 单节点QPS | 集群扩展性 | 延迟(99%) | |----------------|-----------|------------|-----------| | ZADD(单条) | 12,000 | 线性扩展 | 8ms | | Pipeline(100条)| 48,000 | 线性扩展 | 15ms | | ZRANGE(TOP100) | 35,000 | 依赖分片 | 5ms | > 注：8节点集群可支撑10万QPS，需满足：$\frac{100000}{35000} \times 1.2 \approx 3.4$ → 至少4个从节点 ### 五、热点数据治理 1. **本地缓存降级** ```java public class LocalCache { private LoadingCache<String, List<RankItem>> cache = Caffeine.newBuilder() .expireAfterWrite(1, TimeUnit.SECONDS) .build(this::loadFromRedis); } ``` 2. **动态分片迁移** - 监控命令：`redis-cli --hotkeys` - 自动触发分片分裂：当单分片QPS>15000时，按`product_id`二次哈希 ### 六、监控指标 1. **关键监控项** - Pipeline执行耗时分布 - Sorted Set内存增长率 - 分片负载均衡率：$\frac{\max(qps_i)}{\min(qps_i)}$ 2. **报警规则** ```bash # 当Pipeline延迟>1s ALERT PipelineSlow IF rate(redis_pipeline_duration_seconds_sum[5m]) > 1 ``` ### 七、架构优化对比 | 方案 | 更新延迟 | 读取QPS | 数据一致性 | 复杂度 | |-----------------|----------|---------|------------|--------| | 原生ZSET | 实时 | 5万 | 强一致 | 低 | | 分片+Pipeline | 5秒 | 10万+ | 最终一致 | 中 | | 旁路存储 | 分钟级 | 100万+ | 弱一致 | 高 | ### 相关问题 1. 如何验证分片后数据的一致性？ 2. Pipeline批量更新时如何保证原子性？ 3. Sorted Set内存爆增的应急处理方案是什么？ 4. 如何设计跨机房热榜数据同步？ 5. 行为事件丢失对热榜准确性的影响如何量化？</think>## 基于Redis SortedSet分片和Pipeline的实时热榜架构优化方案 ### 一、架构设计要点 ```mermaid graph TD A[客户端] --> B[API网关] B --> C[热榜服务] C --> D[Redis分片集群] D --> E[SortedSet分片1] D --> F[SortedSet分片2] D --> G[SortedSet分片N] H[消息队列] --> C I[行为日志] --> H ``` 1. **数据分片策略** - 采用**产品线ID+时间窗口**作为分片键 - 每个分片存储1小时数据（减少ZSET内存压力） - 分片算法：`shard_index = hash(product_id + timestamp/3600) % shard_num` 2. **读写分离设计** - 写操作：Pipeline批量更新（5秒窗口） - 读操作：直接查询（支持10万QPS） - 使用Redis集群从节点处理读请求 ### 二、SortedSet优化技巧 1. **内存优化** - 启用`zset-max-ziplist-entries 1024`配置[^3] - 使用`ZRANGEBYSCORE`替代全量查询 ```redis ZRANGEBYSCORE hotlist:2023091510 -inf +inf WITHSCORES LIMIT 0 100 ``` 2. **冷热数据分离** - 热榜TOP1000保留在内存 - 历史数据转存SSD（使用Redis RDB持久化） ### 三、Pipeline批量更新实现 ```python # 5秒窗口批量更新处理器 def update_rank(): pipe = redis.pipeline() while True: events = message_queue.consume(5000) # 5秒窗口 for event in events: key = f"hotlist:{event.product_id}:{time_window}" pipe.zincrby(key, event.score, event.item_id) # 批量执行并重置过期时间 pipe.execute() pipe.expire(key, 7200) # 2小时过期 time.sleep(0.1) # 控制CPU占用 ``` ### 四、性能优化关键点 1. **分片扩展公式** 所需分片数： $$N = \frac{QPS_{read}}{30000} + \frac{QPS_{write}}{5000}$$ - 单分片读能力：30,000 QPS - 单分片写能力：5,000 QPS（Pipeline批处理） 2. **内存计算模型** 单分片内存占用： $$M = (20 \times N_{items}) + (16 \times N_{items}) \text{ bytes}$$ - 20字节/item（成员存储） - 16字节/item（分数存储） ### 五、10万QPS保障方案 | **组件** | **优化措施** | **预期性能** | |----------------|--------------------------------------|-------------| | 网络层 | 使用TCP连接池（最大500连接） | 降低50%延迟 | | 序列化 | MessagePack替代JSON | 提升30%吞吐 | | Pipeline | 批量大小=500条/批次 | 减少90%RTT | | 缓存策略 | 本地缓存TOP100结果（1秒过期） | 拦截60%请求 | ### 六、监控与熔断 1. **关键监控指标** ```bash # Pipeline执行延迟 redis_latency = redis.info('latency_monitor_threshold') # 内存使用率 memory_used = redis.info('memory_used')/redis.info('memory_limit') # 分片负载均衡 shard_load = std_dev(shard_qps) / mean(shard_qps) ``` 2. **熔断规则** ```python if redis_latency > 100: # >100ms延迟 enable_degraded_mode() # 降级到本地缓存 if memory_used > 0.8: # 内存>80% trigger_data_archive() # 归档冷数据 ``` ### 七、压测结果对比 | **优化项** | 优化前QPS | 优化后QPS | 提升幅度 | |------------------|----------|----------|---------| | 单分片原生ZSET | 12,000 | - | - | | Pipeline批处理 | - | 48,000 | 300% | + 本地缓存 | 48,000 | 76,000 | 58% | | MessagePack编码 | 76,000 | 108,000 | 42% | > 实测8节点Redis集群可稳定支持120,000 QPS，满足10万QPS要求[^1] ### 八、架构演进建议 1. **数据分片** → **业务分片** 将大流量产品线（如电商）独立集群 2. **Redis** → **Redis+CDN** 全球热榜通过CDN边缘缓存加速 3. **定时更新** → **实时更新** 引入Flink实时计算引擎 ### 相关问题 1. Pipeline批量更新时如何处理部分失败？ 2. 如何设计SortedSet分片的自动扩缩容机制？ 3. 热榜数据如何与持久化存储（如MySQL）保持同步？ 4. 多数据中心场景下如何保证热榜数据一致性？ 5. 如何验证10万QPS下的系统稳定性？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值