今天是农历二〇二〇年正月十四了，二〇二〇年的开局，简直是地狱难度开局，每天都会被新型冠状病毒的新闻刷屏，口罩一罩难买，甚至昨天的论坛，京东连泡面都脱销了。当然，影响最直接的，还是越放越长的假期了。

从来没想过会嫌假期太长，这半个多月的假期，由于在家呆的可谓一个无聊，吃饭，睡觉，看电视，玩手机。偶尔看点文档了解了解新东西，就算是学习了。百无聊赖中，我想起了我还有一个博客的来着。于是乎，这两天折腾了下博客。距离上次折腾博客，差不多有半年了吧，确实太久没打理了。

我这次又迁移了一次博客，重新编译了nginx，php等，之所以迁移，主要是原来的vps带宽只有1M，已然是瓶颈了，虽然我把很多静态资源都做了分离，还套了cdn，但我自己打开还是经常会慢慢慢，这次的vps的带宽加到了10M，立马就快了很多。

同时，我对之前的主题一直不满意，这次我新安装了Wordpress后，意外的发现默认主题“二〇二〇”挺漂亮的，就直接用默认主题了，不过，我做了一点点小修改，主题默认的文章显示宽度太窄了，我给加宽了一点，从58em加到了78em，也就是现在看到的这个宽度了。然后发现代码高亮插件对这个主题支持不好，代码块会靠左贴边，我也修改了下，现在是居中的了。

刚刚说到了插件，这次迁移也是一切从简，我只安装了3个插件，都是必备插件，分别是代码高亮插件：Enlighter，垃圾评论过滤插件：Akismet Anti-Spam和网站sitemap生成插件：XML Sitemap & Google News。想之前我刚开始接触Wordpress时，当时装了一大堆插件（20+），现在想想其实完全没必要的，毕竟网站最重要的，还是内容本身。

与博客一起迁移的，还有我的图床程序，这个是用chevereto部署搭建的图床，本博客的图片都是通过这个图床进行管理的，这样会比较方便。

到此，这两天的工作都记录完毕，今天在网站后台，发现有网友在留言，心里挺高兴的，毕竟，我的文章帮到了这位网友了，也算是一点微小的贡献吧。二〇二〇，要坚持写文章，可别再让网站荒了。

目前已是凌晨1点30，折腾了一晚上总算完成了迁移工作。

其实严格来讲，也算不上迁移，应该叫renew，因为这一切都是在同一台VPS上操作的，大致过程就是先备份了数据，接着制作了VPS的快照镜像，然后重装了系统，然后再进行恢复。不过理想很美好，现实很骨干，中间也是出了一些幺儿子。

还没说为啥要迁移呢！最主要的还是VPS本身的原因，不知道什么原因，VPS动不动就是load超过20，而且从top上看不是某个进程引起的，当卡住的时候，所有进程的CPU占用率都奇高无比。我也怀疑过是不是中招了，可无奈才疏学浅，差了几天也没查出所以然，索性直接重装了得了。

回到迁移话题，上一次搭建的博客，为了尝鲜，是直接用的docker compose，除了Wordpress外，还用docker弄了一些其他服务，比如gitea啥的，然后在母鸡（姑且把VPS叫母鸡了）上用Nginx反代出来。虽说docker是很简单，也非常方便，不过这次迁移我却还是回归了LNMP架构（注意啦，埋坑啦）。

在我LNMP都安装配置完以后，开始恢复数据，文件啥都一切正常，开始恢复数据库，数据库我偷懒，不是直接用mysqldump导出来的，而是直接用的日常备份里的sql文件。并且我docker版用的是mysql，版本记得没错是5.8，然后我新搭建的数据库用的是mariadb，再导入sql语句的时候满屏错误，主要是主键相关，但最后还是执行完了，一刷新页面，网站直接打不开了。

搜索了一通，没发现有什么有价值的解决方法。转念一想：我的文件目录结构和之前是一模一样的，现在就差个数据库了，既然我是用Wordpress备份插件导出的数据库，那我直接新安装个Wordpress，在用同一个插件导入回去不就好了？最后的答案是：不行，这个插件只认自己备份的数据库文件，其他的一概不管，哪怕我替换了它新备份的文件也无法恢复。

仔细看了插件的文档，里面提示说恢复有两种途径，一个是和上面一样，直接从插件上恢复，还有有一种是用phpMysqlAdmin工具恢复，于是乎，我又装了个phpMysqlAdmin工具。最后的结果是：诶，还真恢复了！虽然还是有不少错误提示。但好歹能打开了网站，进入后台了。

不过，首页就是404是什么鬼？进入后台一看，文章、标签、URL里虽然恢复了七七八八，但中间有大量的乱码，应该是mysql和mariadb不兼容导致的，这些乱码有些我还能记得是什么内容，不过还是有一些记不清了，好在谷歌搜索引擎有收录，最后从搜索引擎的收录镜像中恢复了。

至此，流水帐记录完毕。本次迁移除了恢复博客，除了从docker compose恢复到了LNMP架构，最大的改变应当属于Nginx了，这个下篇文章说明。

好久没打理博客了，刚刚更新了5.1版wordpress，感受下新版的文章编辑器。

1
2
3
4

这里是引用，瞎写一句吧：

落霞与孤鹜齐飞，秋水共长天一色。

发现有一个诗句模块，试试效果！！！

1
2
3
4
5
6
7
8
9
10

桃花坞里桃花庵，桃花庵下桃花仙。
桃花仙人种桃树，又摘桃花换酒钱。
酒醒只在花前坐，酒醉还来花下眠。
半醉半醒日复日，花落花开年复年。
但愿老死花酒间，不愿鞠躬车马前。
车尘马足富者趣，酒盏花枝贫者缘。
若将富贵比贫贱，一在平地一在天。
若将贫贱比车马，他得驱驰我得闲。
别人笑我太疯癫，我笑他人看不穿。
不见五陵豪杰墓，无花无酒锄作田。

这里是带删除线的2级标题

下面是测试代码块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import sys
import os
import fcntl

fd = sys.stdin.fileno()
fl = fcntl.fcntl(fd, fcntl, F_GETFL)
fcntl.fcntl(fd, fcntl.F_SETFL, fl|os.O_NONBLOCK)

try:
    for line in sys.stdin():
        print(line)
except IOError:
    pass

print(233)

在这里插入一张图片试试

上个月苹果发布了MacOS 10.14，也就是MacOS Mojave版本，一直没有更新，今天抽空更新了一下，第一感觉就是看了这么久的白色皮肤，这新出的黑色主题也是很帅的嘛～～

其实在更新Mojave之前，我并不了解具体更新了什么内容，

====2019年6月30日补充====

突然发现这篇文章后面内容断了，可能和迁移博客有关，也可能是其他原因，总之现在是之前写的啥已经完全忘记，原本想删除了文章，想象也是一个自己过失的见证，所以还是留着吧。现在已经是用了半年了，只能补充一句：其实新功能真没啥感觉，动态的壁纸平时基本看不见，其他还有啥完全没印象，相比而言，还是更期待macOS 10.15以及ipadOS13（iOS 13）的更新。不过现在的beta版就算了，毕竟吃饭的家伙可不敢瞎折腾了

众所周知，brew 可谓是Mac下管理软件的一大神器，通过brew，可以很方便的安装各种软件，非常方便。

安装brew不是本篇文章的重点，网上有非常多的文档了，其实也很简单，参照官网，一条指令的事。

前两天，更新完MacMojave后，发现brew无法使用了，一直提示”Error：Failure while executing;”

1
2

Error: Failure while executing; `git config --local --replace-all homebrew.analyticsmessage true` exited with 1.
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

一番搜索后，在国外论坛stackexchange发现解决之道：更新下xcode command line即可。

安装命令：

1

xcode-select --install

安装完后再执行brew upgrade，一切正常。

上个月苹果发布了MacOS Mojave（10.14），今天趁有时间，准备更新一下，结果遇到了不少麻烦。

第一次更新，花了两个多小时下载完更新包后，一直安装不上，删除了重新下载。可不知道什么原因，App store里点了 下载后就一直卡在那不动了，没有进度条，按钮也无法点击，同时也没报任何信息。尝试设置代理再下载，这次是有进度条了，但下载了一点点后进度条就回滚，并且启动器里的图标也自动删除了。

打电话给苹果客服，苹果客服听完描述后教了一招，不但下载没出问题，而且速度飞快，北京联通200M的宽带跑满了，分分钟就下载并完成了更新安装。

有此黑科技，自然要记录分享一下了。

• 第一步：打开Wi-Fi设置界面，选择最上方的“位置”选项，选择“编辑位置”。

• 第二步：在点左下角加号，新建位置，位置的名称随意，比如我这写了tinkol。

• 第三步，一路完成，应用，Wi-Fi会先断开并重新连上。

到此，黑科技设置完毕，这时候再去App Store下载软件，发现速度瞬间爆炸，能跑满带宽了。至于这是什么原理，我也不知道，所以才叫黑科技吧。

前因

今天收到客服反馈很多用户说播放视频卡，甚至无法播放，检查后发现分布式存储系统里的某台服务器带宽满了，而导致带宽突然跑满的原因是由于某视频爆火，带宽一下子增加了3G。

过程

简单说下这块的访问流程：当用户访问 http://file.example.com/a.mp4 ，根据DNS解析，这个请求会先到达调度器（100.0.0.1)，调度器经过数据库查询，得知这个文件存储在存储服务器1（200.0.0.1)上，然后会给用户返回一个302，把地址指向到 http://200.0.0.1/file.example.com/a.mp4 ，用户请求302后的地址，即得到了资源。

服务器物理带宽跑满，那没其他办法了，只能把带宽调度均摊到其他服务器上。这就有一个问题了，调度器给的地址，是以IP开头的地址，而要修改调度器的话，就要去改数据库了，这个不是一个规范的操作，而且是个危险的操作，所以这个方案直接排除。调度器这块不能更改，那只能从存储服务器1上动手了，当用户访问302后的地址也就是 http://200.0.0.1/file.example.com/a.mp4 时，实际上访问的是Nginx的80端口，这就有文章可以做了，下面是具体思路。

存储1（高流量）：当收到用户请求时，先在Nginx里对请求做一个处理，将60%的流量302到存储2和存储3的8080端口，同时新开放一个81端口，用于存储2以及存储3服务器的回源。
存储2、存储3（低流量）：安装OCT软件（一个内容缓存服务，类似squid服务），从存储1的81端口进行缓存资源，OCT开放8080端口。

下面是存储1的Nginx配置文件，在对应的location里添加了lua代码，这个是这个架构的核心所在。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

server {
        listen  80 default_server;
        #新增81端口用于存储2以及存储3用于回源
        listen  81 default_server;
        charset utf-8;
        server_name 200.0.0.1;

        location ~ "^/\d{1,2}/" {

    #下面这段lua代码是核心，将用户请求中的60%流量进行302重定向，返回一个存储2以及存储3服务器上带8080端口的URL

            rewrite_by_lua '
                if ngx.var.server_port == "81" then
                return
            end

            x = math.random()
            if x > 0.4 and x <= 0.7 then
                ngx.redirect("http://200.0.0.2:8080" .. ngx.var.request_uri)
                return
            end

            if x > 0.7 then
                ngx.redirect("http://200.0.0.3:8080" .. ngx.var.request_uri)
                return
            end
            ';
        }

}

存储2以及存储3上OCT的配置文件则如下：

1
2
3
4
5
6
7
8
9
10
11

threads 4 #4线程
store ssd  #存储组名叫ssd
path /dev/sdb  #ssd对应的快设备（硬盘）

listen 8080  #监听8080端口
description stf  #备注
upstream_host 200.0.0.1:81 #从存储1的81端口进行回源
expires_default 6000000  #默认过期时间，单位秒
order_of_store ssd  #缓存存在名叫ssd的存储组上
check_consistency on  #开启一致性检查
mp4 mp4|flv start end second  #对视频文件开启拖拽支持

配置文件配置好后，分别重载服务，即可生效。此时用户再来访问 http://file.example.com/a.mp4 ，那过程就是先到调度器，调度器302到 http://200.0.0.1/file.example.com/a.mp4 ，而后面有60%的概率再返回一个302，将用户302到 http://200.0.0.2:8080/file.example.com/a.mp4 。

结果

原来流量跑满的服务器，流量成功降了下来，而低流量的服务器，流量瞬间上升，客服回访用户，均恢复正常。