营口房地产网站开发甘肃建设厅网站官网

营口房地产网站开发,甘肃建设厅网站官网,wordpress数据库太大,美康优选网站怎么做的昨晚一个 4 年经验的粉丝在群里复盘 B 站#xff08;哔哩哔哩#xff09;的后端二面#xff0c;人有点麻。 面试官问了一个非常贴合 B 站业务场景的题目#xff1a;“B 站的视频、动态、弹幕都能点赞。面对千亿级数据量、几十万 QPS 的流量#xff0c;这个点赞系统你怎么…昨晚一个 4 年经验的粉丝在群里复盘 B 站哔哩哔哩的后端二面人有点麻。面试官问了一个非常贴合 B 站业务场景的题目“B 站的视频、动态、弹幕都能点赞。面对千亿级数据量、几十万 QPS 的流量这个点赞系统你怎么设计”这哥们心想点赞不就是一个 count 1 吗自信回答“简单用 Redis 存点赞数MySQL 持久化。用户点赞就写 Redis异步刷回 MySQL。为了防刷再加个限流。”面试官听完抛出了三连追问“周杰伦发新歌流量瞬间打爆热点你的 Redis 单分片扛得住吗”“点赞记录超过 1000 亿 条Redis 存不下MySQL 分库分表成本太高怎么降本增效”“内存聚合写入时服务宕机了怎么办数据丢了Redis 挂了怎么降级”这哥们瞬间哑火才意识到自己把“国民级 App”的架构想简单了。兄弟们点赞系统看似简单实则是高并发High Concurrency与海量存储Big Data的双重噩梦。今天 Fox 结合 B 站的真实架构演进带你拆解这道题的 3 种段位。一、 为什么 “简单的 Redis MySQL” 是死路在小公司Redis MySQL 确实够用。但在 B 站这种体量读 QPS 30w写 QPS 1.5w数据量千亿级简单架构有两个死穴写穿透Write Penetration如果每次点赞都直接落库或者 Redis 没拦住1.5 万的 TPS 能把 MySQL甚至 TiDB的 CPU 打满。热点雪崩Hotspot像“周杰伦发歌”这种超级热点流量会集中打向 Redis 的某一个分片Sharding导致单节点过载。结论必须上“多级缓存”和“智能聚合”。二、 核心架构3 种主流解法从青铜到王者解法 1Redis Cache Aside标准版—— 青铜段位这是最基础的解法。数据结构点赞数String 结构 count:business:id。点赞列表ZSet 结构 user:likes:id。持久化数据库存流水表和计数表。Fox 点评能跑但扛不住热点且 ZSet 会无限膨胀。必须限制 ZSet 的长度比如只存最近 500 条老的走 DB 回源。解法 2WAL 智能聚合防丢数据—— 黄金段位面对 1.5w 的写 QPSB 站采用了 “内存聚合 WAL” 策略。逻辑写内存用户点赞先在应用层内存中 hold 住。WAL 日志关键为了防止服务宕机导致内存中未合并的数据丢失先写一条本地日志Write Ahead Log。动态窗口聚合不是死板的 10 秒而是根据当前流量水位动态调整聚合窗口1s - 10s。将同一稿件的点赞数合并count N同时记录用户 ID 用于去重。异步落库聚合后的数据通过 MQ 异步写入持久层。优势数据库的 IO 次数减少了数千倍且通过 WAL 保证了准实时一致性。解法 3三级存储 TaiShan KVB 站真题—— 王者段位这是 B 站目前的生产级架构核心在于“热点隔离”和“极致降本”。1. 扛得住热点治理三板斧为了应对超级热点B 站设计了 L1 L2 防御体系热点探测HotKey Detector实时统计流量精准识别出“周杰伦”这种热 Key。L1 本地缓存Caffeine识别到热点后直接利用 Caffeine 将数据缓存在应用节点本地Local Cache并开启 Window-TinyLfu 淘汰策略。请求直接返回连 Redis 都不用查。L2 分布式缓存Redis Cluster承载常规流量。2. 存得下TaiShan KV TiDB数据量千亿级Redis 存不下MySQL 存不起。核心存储TaiShan KVB 站自研的高性能 KV 存储。利用 SSD 盘存储冷热数据成本仅为 Redis 的 1/10。它不再是“归档”而是主力存储。Key 设计{业务类型}{实体ID}{用户ID}支持高吞吐的 Exists 查询判断用户是否点赞。3. 容灾降级保命绝招TiCDC 同步数据库与缓存之间的数据一致性通过 TiCDCTiDB 的变更日志捕获来实现而不是业务层双发。乐观更新Optimistic UI如果后端挂了前端直接反馈“点赞变红”给用户成功的错觉后台默默重试或等服务恢复。用户体验第一。三、 最后的“防杠”指南扫清死角设计完架构面试官会追问这 3 个实战死角答不上来也是挂Q1L1 本地缓存Caffeine各节点数据不一致怎么办答“接受短暂不一致。 对于点赞数这种非强一致数据A 节点显示 100WB 节点显示 99W完全不影响业务。 等到热点消退或 TTL 过期数据自然会追平 Redis/DB 中的真实数据。”Q2聚合写入时用户刚点赞刷新页面发现没变红数据没落库怎么办答“读写分离 客户端乐观更新。客户端侧用户点赞后前端直接把按钮变红乐观 UI不需要等后端返回最新 count。服务端侧读接口优先读Redis 里的实时聚合态包含内存中未落库的增量而不是读 DB。这样保证用户能看到自己的操作。”Q3Redis 挂了TaiShan 扛得住吗答“多级降级策略。存储降级Redis 挂了流量打到 TaiShan KV它本身就是高性能 KV读性能强于 MySQL。功能降级如果 TaiShan 也抖动立刻关闭‘点赞数’的实时展示显示 999 或静态值只保留‘点赞状态’查询保住核心体验。”四、 面试标准答案模板建议背诵下次被问到“B 站/抖音 点赞系统设计”直接按这个套路输出“对于点赞这种千亿级数据、突发热点的系统我的架构遵循 ‘多级缓存 存储降本 异步聚合’流量防御Caffeine Redis引入HotKey 探测利用Caffeine做本地缓存抗住超级热点常规流量走 Redis Cluster。写入优化WAL 聚合采用动态窗口内存聚合策略并配合WAL 日志防止宕机丢数据将 DB 写入压力降低 3 个数量级。海量存储TaiShan KV放弃传统的 MySQL 分表采用自研KV 存储TaiShan作为核心底座配合TiCDC保证数据一致性实现极致的降本增效。体验兜底前端采用乐观更新策略后端具备Railgun 降级能力确保极端情况下服务不雪崩。”写在最后架构设计没有完美的方案只有被业务逼出来的方案。 B 站的点赞系统之所以复杂是因为它要在“周杰伦发新歌”的洪峰下依然保持丝滑。把“热点”隔离把“成本”打下来把“容灾”做到底你就是架构师。https://mp.weixin.qq.com/s/T_5xDocvTSKFkcuM0yl4qA