问答社区的并发特点与配置

问答站点的访问曲线很有特点：平时风平浪静，一个热题被顶上榜，读取量几分钟内就能翻几倍。配置这类站点，先认清它的读写结构。 读多写少是基本面 提问和回答是低频动作，浏览是高频动作，读写比普遍在九比一以上。这意味着大部分压力可以用缓存化解，数据库只需要认真处理那不到一成的写入，以及偶尔激增的读穿透。 缓存的收益特别大 热门问题页适合整页缓存，命中之后数据库完全不出力；问题列表、标签页用 Redis 存热点集合，失效时间按内容更新频率分档。缓存命中率每提高一成，数据库的查询压力就有肉眼可见的下降。日常监控两个数就够：缓存命中率、数据库慢查询条数： ```bash redis-cli info stats | grep keyspace ``` 键数量突然跌到零，多半是缓存被清了，要立刻预热热点页，防止流量直接砸向数据库。预热动作可以放进发布流程：新内容上线后顺手请求一遍热门页，缓存空窗期从几分钟缩到几秒，这几秒恰好是最容易被流量砸穿的窗口。 搜索是隐性大户 站内搜索看起来不起眼，实际是 CPU 消耗大户，数据库自带的全文检索在大表上尤其吃资源。搜索量上来之后，要么给搜索单独划一台机器，要么换独立的搜索服务，别让搜索和主库抢同一颗 CPU，问答页打不开的体验比搜索慢更伤用户。搜索框加输入防抖和结果页缓存，同一个词短时间内的重复搜索直接复用上一次结果，无意义请求先挡掉一轮，机器压力立刻小一截。 配置的参考路径 起步阶段两核四G一台机可以同时跑应用、数据库和缓存；日请求量到几十万级，按应用、数据库、缓存各一台拆分；再往上是数据库主从加读写分离。 问答站点的架构演进，本质是把"读"的成本一步步挪向缓存和静态化，让数据库专心伺候"写"。资源围绕这个原则分配，大方向就不会错。