暂无搜索历史
“在高并发互联网场景下,数据库主从延迟是高频痛点,会导致用户读到旧数据、业务逻辑异常。请问你在实际项目中是如何系统性解决这个问题的?”
作为一个北漂 12 年、从普通二本熬到架构师的 Java 开发,经历过移动互联网爆发、共享单车烧钱大战、在线教育雪崩、以及最近的 AI 重构全栈。带过几十个实习...
分库分表是解决单库单表性能瓶颈的核心方案,但它本质是 "用复杂度换性能",会引入 7 大类核心问题,我结合实际项目经验逐一说明:
分库分表本质上是数据库水平扩展的核心方案,当单库单表的数据量和并发量达到瓶颈时,通过 "化整为零" 的方式将数据分散到多个库和表中,解决单机存储和性能问题。
“假设生产环境数据库突然告警,出现大量慢SQL,老板让你去排查。说说你的整体思路。”
推荐方案:用 DataX 按主键范围切分 100-200 个并行任务做全量迁移,速度可达 10 万行 / 秒以上,10 亿数据约 2-3 小时完成。
面试官您好!关于亿级用户在线状态统计这个问题,我会从核心挑战、方案演进、最终架构和关键优化四个层面来回答。
扫码登录的核心本质是利用已登录的可信设备(手机),为未登录的不可信设备(PC)颁发身份凭证,本质是跨设备的身份授权流程。👇
示例:北京天安门的 GeoHash 是wx4g0ec1,附近 500 米内的用户 GeoHash 都以wx4g0e开头。
💡 核心理念:写的时候异步累加分数到 Redis,查的时候直接读 Sorted Set,客户端可以再缓存一小会儿。
结果往往是:前面的人把预算吃光了,最后一个人只有 0 分,或者变成了负数。这在金融场景下是要背责的。
互联网大厂主流采用 RocketMQ 定时消息 + 本地事务表 + 定时任务兜底 的组合方案,兼顾性能、可靠性和可维护性。
将库存热点数据放到 Redis,用 Redis 扛高并发,数据库做最终存储,是目前秒杀系统的标准方案。
秒杀系统的核心思想是:分层限流 + 异步削峰 + 最终一致性,把流量层层拦截,最终只有极少部分请求能到达数据库。
绝对禁止使用Redis decr()单独扣减(会出现超卖且无法控制负数),必须使用Lua 脚本保证原子性:
互联网场景设计题
暂未填写公司和职称
暂未填写学校和专业