博友圈优化

前面搭建的友圈模块让我可以实时监控到邻居们的最新动态，以便第一时间访问送上评论，留下足迹。该模块的存在确实给我带来了很大便利，而且不依赖第三方Freshrss这类的工具，保证了博客整体的独立性。以后迁移或者二次搭建都是很方便的。能做到这点的原理就是实时动态请求解析feed地址数据，生成outrss.json文件然后展示在前端。

前情提要及原理解析可以参考我上一篇博客：https://liuqingwushui.top/archives/66/

但是这样做的弊端就是如果用户刚好在缓存时间外访问就会触发请求更新，随着feed地址的增多。请求时间也会变长。就会让访客等待较长时间。在这个人心浮躁的当下，刷个视频卡五秒都算的上大逆不道，更遑论打开个网页？

后续也对友圈模块进行过几次细节优化，比如解析feed格式除了rss，还有atom。网址的跳转解析，排版布局等。不过随着细节优化的愈加完美，刷新等待这个问题更加显得尤为突出。我想，也是时候解决一下了。

方法一，定时请求。

我第一个想法是写一个定时器定时请求来达到刷新的目的，尽量避免哪个幸运儿刚好在缓存期外访问造成等待的问题。但是让我没想到的是，这个缓存期是指的2小时时间段，我就算定时每小时请求刷新，也只是缩短缓存期罢了。终归是治标不治本。

方法二，后台刷新

另一个想法就是客户端发送请求过来，我直接返回旧数据，后台去请求并刷新outrss.json本地文件缓存数据。避免客户端长链接造成等待。这样的话。第二个用户再来访问就是新的数据了。

方法二确实是可行的，因为php提供了如下几个机制代码：

// 设置脚本执行时间无限制
set_time_limit(0);
// 忽略用户中断，确保脚本继续执行
ignore_user_abort(true);
// 使得客户端响应结束后，PHP 脚本继续执行
fastcgi_finish_request();

在确技术可行性之后，就是开发调试了，中间经历了一些曲折。经过总结大概就是如下两个问题：

    1.多并发的问题，可能会造成多个php脚本后台执行造成影响。这里要考虑文件锁机制

    2.fastcgi_finish_request()执行后，会默认后面的php代码都走后台执行。假如fastcgi_finish_request()后面还有echo输出该如何处理

不过最终优化的结果，仅从目前来看好像没啥问题，友圈模块确实访问提升了，也不会触发缓存期外等待了...

不过也说不准，暂时先这样吧，如果出了问题再优化就是了，生命不息，折腾不止！