All posts

4 threads

November 20261 thread
Ruby on Rails Scalability: MVP to Millions of UsersRails 能撑到百万级甚至更高流量；真正先崩的通常是数据库、任务队列和缺缓存，不是框架本身。Shopify BFCM 2025 应用服务器峰值超过 1.17 亿次请求/分钟，靠分片等架构手段留在 Rails。 常见误判 → 实际原因 「扛不住流量」→ 多半是 N+1 「数据库挂」→ 全打主库、没缓存 「高峰变慢」→ 请求里同步调第三方 「服务器打满」→ 单机、没水平扩展 「该上微服务了」→ 往往是缺索引 / 胖模型 瓶颈顺序与对应招 N+1 → includes / preload ，用 Bullet 连接池耗尽 → 算清连接；必要时 PgBouncer 后台队列堆积 → Solid Queue / Sidekiq，按优先级拆队列 单机顶满 → 无状态进程 + 负载均衡 多机后缓存/会话乱 → Solid Cache / Redis 数据库进阶（别跳步） 先查索引与执行计划 → 再读副本 → 再分区 → 最后才分片 。 真正硬伤： 单进程吞吐低于 Go/JVM，多花机器、少花工程时间。YJIT 能缩小差距。极低延迟、十万级 WebSocket、重 CPU 更适合拆独立服务，不必整站重写。 动手前先看： 各接口 p95、最慢 SQL 的 EXPLAIN ANALYZE 、所有 Puma/Job 的总连接数。
October 20263 threads
规范不止于代码，亦可照见自身只做一件事 SRP 保持简单直接 KISS 你并不需要它 YAGNI 不要重复你自己 DRY
两个女生从旁边走过，她们背着书包，穿着青绿色的校裤，上身搭配印有个性图案的白色T恤，看起来像是附近学校的学生。路灯一晃，她们的影子也在地上晃了两下，轻盈又遥远。牧风（风中的夏天）
跳过情绪，收藏了自己的博客我是一名软件从业者，收藏 Jant 很久了 一直在存在星标的书签栏中 在部署和写什么之间来回切换，虽然部署对技术人员来说并非难事 所以最大的问题，是不知道自己要写下什么，没什么墨 因为现实生活中工作性质原因，寡言少语