1. 问题描述
   大家应该注意到了最近社区访问速度有点慢，一直以为是家里 wifi 不给力覆盖范围不够，直到 @leo 喊我说服务器太慢，CPU 爆了：
   
   上 UCloud 后台看数据比较直观：
   
   CPU 使用率居高不下，有时候还伴随着 MySQL 爆掉的情况，如下图。当这种情况发生时，你就会发现网页请求卡住不动：
   
   经过一番调查，定位到两个问题，下面分别讲解各自的解决方案。
   问题一：话题显示时实时更新查看数
   
   每次页面的查看，都要触发一次数据库 UPDATE 操作，当社区帖子 PV 很高时候，瓶颈就会很明显。
   解决方案
   核心思路是尽量少碰到数据库，利用较快的记录器来做记录。这里选择使用 Redis 的 Hash 数据类型来存储。Redis 运行在内存中，效率将会非常高。
   实现逻辑：
2. 按照日期分开存储 view_count 到 Redis 里，按日期命名 Hash，如：laravelchina:counter_cache_2018-06-17;
3. 字段名按照命名规则 数据表_字段名_ID，如话题表里 ID 为 1 的 view_count 字段 ——topics_view_count_1 ；
4. 设置计划任务每天凌晨将昨天的 Hash 同步到 DB 中，并删除；
   问题二：未读消息 Ajax 请求太频繁
   
   登录用户情况下，每一个浏览器打开的社区页面，每过 15 秒钟就会发送一次未读消息的 Ajax 请求，像我查阅资料时，很多时候会同时打开几十个页面：
   
   上图这种情况每 15 秒钟就会给服务器发送几十个请求… 看着自己写的 Bug，无奈感叹：
   
   解决方案
   核心思路是不论浏览器打开了多少窗口，浏览器内的所有窗口在单位时间内（15 秒），只能发送一个请求。怎么做到呢？利用现代浏览器内置的 localStorage 功能可以很容易实现：
5. JS 端使用 localStorage 在请求成功后记录 notification_requested_at 的值为Date.now()；
6. 在每一次请求发送前，拿当前时间 Date.now() 减去 notification_requested_at 时间；
7. 如果大于 15 秒，就发送请求；
8. 否则放弃请求，直接读取 localStorage 里的 notification_count；
9. 请求成功后将获取到未读消息数存入 localStorage 键为 notification_count ；
10. 每次刷新页面，JS 初始化时未读消息数存入 localStorage 键为 notification_count 。
    有同学在问为啥不使用长链接，首先这里要求的实时性不需要那么高，其次，我有意保持程序架构的简单，Keep it simple and stupid ，越简单越方便维护，够用就行。
    优化结果
    
    看来又可以延迟升级服务器配置的时间了。性能优化的路漫漫，准备找个时间好好优化下社区程序，顺便看看能不能输出一些优化日记。听说 PHP 7.2 性能要好个 10%， 现在也趋于稳定，有在考虑升级下 PHP 版本。

感觉原作者分享的内容特别清楚，把原因和解决的方式都说的很明白，很喜欢