今年五一开车 2000 多公里，一路上找景点，找路线，找美食，这里记录一些比较好用的 App，当然在记录这写应用的时候，又发现了其他人推荐的应用，虽然之前并没有用上，但可以做一个备份期望可以用上。

PS 部分免责声明，PS 部分我并没有深入的用过，但是口碑还不错。

去哪里

这个问题早已经应该在心中确定，但如果没有确定，可以浏览马蜂窝 站点，一来对目的地有一个基本的了解，二来可以留心目的地的路况等等。虽然市场上游记类网站和应用也是泛滥的，但是马蜂窝确实多少年来一直兢兢业业专攻旅行的网站。写到这里不免想起，一直萦绕在我脑海里面的一个疑问，其实做内容的网站很容易转型做“工具”，比如马蜂窝就可以很轻松的售卖旅行产品，包括机票火车票，住宿等等，反而携程，去哪儿这一类“工具”类网站要转型做“内容”就要难很多。虽然携程也有游记，但终究只是为买票而生的辅助。

PS. 穷游锦囊，有个叫浪浪的，常有人推荐

选好车

说到选车，我只能推荐神州租车了，其他租车行并没有接触过，所以也不好推荐。而针对性的选择一辆舒适的车就成了关键，因为可能需要长时间在车上度过，选择一辆空间大，舒适的 SUV 就比较好。而如果目的地都是平原，可以选择轻便的小汽车

PS. 并没有使用过的租租车

制定路线

推荐 Google My Maps，使用 Google My Maps 可以快速制定一条大致路线，可以从宏观上对整个路线有个了解。

当然还要推荐另外一个很好用的工具 Trello，然后可以制作出如下的计划

当然真正出行的时候，少不了导航应用，Google Map 看卫星图，高德导航

天气

国内墨迹，国外雅虎天气

找美食

大众点评，必不可少。在不熟悉的地方，选择一个品类，往往评价不错的菜肴是不会有什么差错的。

PS. 国外似乎有这俩 Yelp 和 Trip advisor，还有预订位置的 Open Table

住宿

强推 Airbnb，虽然很久前注册过 Airbnb 但是一直没怎么使用过，然而突然发现这么好用，每一个房子主人都很友好，房子也都非常新，房子里面各种设置都很不错。但是 Airbnb 可能有一个不好的地方，就是可能有些地方并没有那么多的选择，这个时候就需要携程，马蜂窝等等有旅馆预定的应用了。

如果不嫌弃你可以点击我的邀请链接：https://zh.airbnb.com/c/einv 注册成功后你会得到 175 的优惠券。

PS. Booking 也是个好网站。

其他

绝大部分情况下停车并没有太大问题，可是如果真的到了城市环境，有一个 ETCP 还是需要的。

当然以上大部分只能局限于国内自驾的大部分情况，国外去如果要租车，可能还需要准备驾照翻译件或者国际驾照，不同国家的国情可能都需要调整。

去年年底装上了头条系全系列产品包括新闻，抖音，火山小视频，而半年多过去了，最后留下来的只有抖音。而之前不久也刚刚看到新闻报道抖音日活已经超 1.5 亿了。所以想整理下自己的看法。

以产品划分用户

全年年底的时候看过一篇文章，其核心思想就是 “头条以产品划分用户群”，虽然并不知道这是不是头条内部有意而为之或者就是产品定位的问题，确实头条内部关于视频的应用报的上名字的就有仨，火山，西瓜，抖音。这三个应用却各有特点，虽然我并没有很深入的使用，但也能快速的感觉到他们的差别，抖音明显要更年轻化，年龄 10+,20+ 主打的产品，而火山则是主打 ugc，各种内容都有，质量参差不齐，西瓜视频，后来者，却继承了头条视频的大量的积淀。而着三款应用能很明显的区分出一部分用户群，如果按照现在 2017 年底的时间来看，明显子女一代用抖音，父母一代更加偏向用火山和西瓜，这是天然的划分。如果要以地域划分，明显大城市是抖音的用户群，而中小城市就是西瓜的天下。

虽然我对这样的产品划分理念并不是那么的“理解”，但确确实实现在移动互联网的发展就是那样的一个趋势，这或许也是有了 Facebook 也还有 Instagram 和 Snapchat 的原因，当随着年龄的变化，一个平台的用户逐渐增多，下一个年龄层的用户自然的就去寻找代替品，或许是为了潮流，或者只是为了凸显不同。就像厌倦了 QQ，逃到了 Wechat，厌倦了 Wechat 的一代，或许又逃回了 QQ。

为什么抖音会火

很多人说拍抖音简单，但我想很多说这个话的人应该没怎么自己拍过。抖音的短视频看起来简单，那是因为他的难度系数正好介于普通用户和专业自媒体拍摄难度系数的中间，抖音大量的视频都只需要用一部手机就能拍摄出来，但是仔细看这短短的十几秒，里面可能包含十几个场景，包括大量的剪辑，而曾经这些剪辑手法我都只在 YouTube 等等平台的长视频或者电影片段中才能看到；另外一点很多人说抖音的成功是将视频引入音乐，可是这难道不是常识吗，电影电视剧 OST，或者 YouTube 去搜一下会看到很多教你如何给视频选择 BGM 的教程，而抖音成功的是让音乐成为了用户拍摄视频的入口，创作相同主题的短视频，一来带动了 BGM 的流行，二来将用户的视频天然的进行了分类。

基于这一点认识，我之前曾经和朋友聊天聊起，抖音流行的歌甚至可能改写音乐的发行历史，如果歌手的歌拿来在抖音发行，或许比拿去发专辑，或者拿去音乐平台要流传更广，毕竟好的音乐只有被人知道，歌才有他的价值，中国目前最缺乏的就是一个有效的渠道让有价值的内容让人知道，抖音或者头条的出现正是弥补了这一空缺。或许有人要说以前也出现过优酷土豆还有 bilibili 等等的网站，还有门户网站推出的新闻客户端为什么无法做到，其实道理很简单，对于优酷等等他们太慢以至于跟不上快速发展的移动互联网，而且对于长视频其实无形中过滤了很大一批的入门却能制作出很有趣内容的作者。而门户网站往往都是自上而下的内容输出，很多用户其实并不关心那些国家大事，而更关心和我们一样的普通人，并且门户网站的写作者和庞大的互联网用户贡献的内容来看几乎就是沧海一粟，Web2.0 带来的就是源源不断的内容输出。

关于运营

不可否认的一点就是运营在产品中的重要地位，抖音这样一款产品我相信以任何一家大公司的实力就能够在几个月的时间内轻松的复制，但是大家都做不到抖音的一点就是大家仅仅认为抄袭一个同样的产品就能够刮分一片市场，这个想法是多么的天真。虽然我也并没有那么关注抖音产品的发展历史，但是作为一个普通用户能够感受到抖音玩法的变化，这无疑是有引导性质的，抛出一个亮点，大家跟风也好，抛砖引玉也好，对任何一个内容型产品都是帮助。而现在大部分场内的玩家能够复制他的系统却抓不到他们的精神内核。

抖音这样一个产品的出现是好是坏？很多人都在想这个问题，其实完全不需要担心，你说他消耗时间也好，让人沉迷也好，如果它能够在流行文化中烙下自己的印记就已经是他产品的胜利。至于他所带来的话题效应，好坏，留待后人判别吧。

7 天的旅程已经结束，更加准确的说应该是完整的 6 天，还有一天时间在路上。这一次经历很多第一次，第一次使用 Trello 规划出行，第一次长时间驾驶超过 2000 公里，第一次使用 Airbnb 来计划住宿，第一次上 3000 多米的高原，这许许多多的第一次让我感受了很多也收获了很多。

旅途遥远记得欣赏沿途的风景

大环线的路程相较于短短 6 天，时间非常赶，但是尤其是从大柴旦到敦煌，以及从张掖到西宁的路上，会路过无数的山脉和平原，别那么赶，看看两边风景。在很大一段时间内，你会看到两边延伸到天边的大漠，以及面前一直通向天边的公路，还有远处层叠的群山。当我们从张掖沿着 G227 穿过祁连山的时候，山上的积雪还没有化尽，从远处看云雾缭绕，太壮观了。

提前计划好住宿

如果说对行程有什么遗憾的话，那么就是没有提前预定好住宿，虽然其实并没有那么的失望，但是如果提前制定好落脚点，那么行程会完美很多。这一次的行程让我爱上了 Airbnb ，虽然很早就已经注册，却一直呆在无数的应用中没有体现出他的价值，我可以说这是我使用至今体验最好的应用了，不管是界面友好程度，还是下单预定，或是之后联系房东，没有人我这个第一次使用的他的人感受到一点点阻碍，而且在绝大部分情况下过滤结果的前几个都是能够满足我的要求的，正因为时间赶，所以预定也很赶，但是却都超出意外，尤其是在西宁和敦煌，家中设施齐全，更甚至敦煌的房东也给我们准备了葡萄干、杏仁干等等特色干果，我最关心的电视也是资源充足。且不说住宿条件，虽然也预订到了一些不那么满意的房子，但是 Airbnb 总体给我的感觉都还是不错的。

Trello

使用 Trello 的时间并没有那么的长，但却一点一点慢慢地适应了 Trello 并且喜欢上了 Trello 独特的设计。“看板” 的概念接触没多久，甚至之前一直拿他当做 todo list，但现在我是知道我小看了这个概念，看板可以让很多工作得到有效的管理，甚至可以提前规划，他提供的图片，附件，checklist 等等功能可以让计划有条不紊的执行，并且界面非常美观。

雅丹和丹霞的区别

过去西北最多被提及的就是这两个容易弄混的名词。

雅丹地貌，或者称为风蚀脊（Yardang）是典型的风蚀性地貌。“雅丹”在维吾尔语中的意思是“具有陡壁的小山包”。由于风的磨蚀作用，小山包的下部往往遭受较强的剥蚀作用，并逐渐形成向里凹的形态。如果小山包上部的岩层比较松散，在重力作用下就容易垮塌形成陡壁，形成雅丹地貌，有些地貌外观如同古城堡，俗称魔鬼城。

丹霞地貌的定义为“有陡崖的陆上红层地貌”，形成丹霞地貌的是一种沉积在内陆盆地的红色岩层，这种岩层在千百万年的地质变化过程中，被水切割侵蚀，形成了红色山块群。

张掖丹霞因其与众不同的岩石色彩而举世闻名。这些岩石光滑而险峻，高数百米，是砂岩和其他矿物经过 2400 万年的沉淀堆积而成。

使用 Maven 来管理项目的依赖，带来便捷性的同时也引入了一些问题。对于一个大型项目来说，引用数十个依赖是经常遇到的。Maven 在管理这些依赖的时候，遵循一些基本原则，这就是这篇文章主要要定义的问题。另外如果项目中出现了依赖冲突，也是这篇文章的重点。

dependencyManagement 作用

dependencyManagement 主要有两个作用

• 集中管理项目的依赖项
• 控制使用的依赖项的版本

使用 dependencyManagement 声明依赖，实际项目并不会引入，因此子项目需要显示声明需要用的依赖

• 如果不在子项目中声明依赖，是不会从父项目中继承下来的
• 只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且 version 和 scope 都读取自父 pom
• 如果子项目中指定了版本号，那么会使用子项目中指定的 jar 版本

dependencies 即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项。父工程使用 dependencyManagement 假引用，目的是管理版本号。dependencies 用于实际上需要引入的工程，这些工程如果继承于父工程会找到对应的版本号。

maven 中的仓库分为两种，snapshot 快照仓库和 release 发布仓库。snapshot 快照仓库用于保存开发过程中的不稳定版本，release 正式仓库则是用来保存稳定的发行版本。定义一个组件或者模块为快照版本，只需要在 pom 文件中在该模块的版本号后加上 -SNAPSHOT 即可（注意这里必须是大写）。

在 distributionManagement 段中配置的是 snapshot 快照库和 release 发布库的地址

<distributionManagement>
  <repository>
    <id>central</id>
    <name>artifactory-releases</name>
    <url>releases-url</url>
  </repository>
  <snapshotRepository>
    <id>snapshots</id>
    <name>artifactory-snapshots</name>
    <url>snapshots-releases</url>
  </snapshotRepository>
</distributionManagement>

maven 区别对待 release 版本构件和 snapshot 版本，snapshot 为开发过程中版本，实时但不稳定。

一般来说发布到远程仓库还需要认证，没有任何配置信息，可能会得到 401 错误。所以还需要在 maven 的 settings.xml 文件中做如下配置：

<server>
  <id>central</id>
  <username>admin</username>
  <password>admin123</password>
</server>

<server>
  <id>snapshots</id>
  <username>admin</username>
  <password>admin123</password>
</server>

需要注意的是，settings.xml 中 server 元素下 id 的值必须与 POM 中 repository 或 snapshotRepository 下 id 的值完全一致。将认证信息放到 settings 下而非 POM 中，是因为 POM 往往是它人可见的，而 settings.xml 是本地的。配置完成后就可以通过 mvn deploy 进行发布了。

Maven 依赖原则

在之前的 Maven 介绍中也有提及，这边展开。

Maven 解决依赖冲突

在之前的 maven 介绍 中指出来 Maven 的传递性依赖两个原则，第一就近原则，第二依赖路径距离一样则优先定义的依赖。

而当项目比较复杂之后，避免不了可能会出现打包时依赖的 jar 出现冲突。当引入新的依赖，发现项目中突然出现很多 method not found，或者 class not found 问题，基本上可以确定是因为依赖产生了冲突。

举一个比较直观的例子

加入我们的项目 A ，依赖 B， C 两个包，而 B ，C 各自依赖了 G1.0 和 G2.0 两个版本的包，那么 Maven 怎么选择？

Maven 的依赖传递会自动寻找到 B，C 两个依赖，并且发现依赖的 C，并自动引入，那么 G 会引入 1.0 还是 2.0 呢？这里就要引入 Maven 的第一个原则，最短路劲优先，这条原则是 A - B - C - D1.0 另外 A - E - D2.0 显然 Maven 会选择 D2.0，而显然在这个例子中是不行的；那么就要提到第二条原则，谁先定义则使用谁，所以在路径一致前提下，如果先定义了 A - B - G1.0，会选择 G1.0，而这个时候可能就会产生问题，命名我需要使用 G2.0 中新的方法和类，但是 G1.0 中并没有就会出现错误。

这个时候就需要通过下面的步骤来排查错误。

判断 jar 是否被正确引用

在项目启动时把所有的加载的 jar 包都打印出来，添加 VM 参数 -verbose:class 。通过打印的信息确认是否正确的 jar 包被依赖。

查看依赖树

通过 maven 自带的工具来查看依赖树

mvn dependency:tree -Dverbose

通过查看其中可能导致冲突的 jar 包，然后使用 exclusions 来排除掉。

<dependency>
  <groupId>info.einverne.chat</groupId>
  <artifactId>common-biz</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <exclusions>
    <exclusion>
      <artifactId>slf4j-log4j12</artifactId>
      <groupId>org.slf4j</groupId>
    </exclusion>
  </exclusions>
</dependency>

使用 enforcer 快速发现冲突

上面提到的例子是一个很简单的演示，实际情况要比这个复杂许多，有的时候仅仅通过 mvn dependency:tree 可能无法快速的发现冲突，这个时候就可以尝试使用 Enforcer 插件，这个插件也可以自定义许多规则，我们可以使用 dependencyConvergence – ensures all dependencies converge to the same version. 来保证所有的依赖都使用相同的版本。

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>1.4.1</version>
        <configuration>
            <rules><dependencyConvergence/></rules>
        </configuration>
    </plugin>
</plugins>

在定义了插件之后就可以使用 mvn 的 goal —- mvn enforcer:enforce 来分析项目，会给出可能的冲突结果

Dependency convergence error for log4j:log4j:1.2.17 paths to dependency are:
+-com.ricston.conflict:conflict-info:2.1.3-SNAPSHOT
  +-org.slf4j:slf4j-log4j12:1.7.6
    +-log4j:log4j:1.2.17
and
+-com.ricston.conflict:conflict-info:2.1.3-SNAPSHOT
  +-log4j:log4j:1.2.16

对于这个插件更多的介绍，可以查看另一篇插件的文章

reference

• https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
• https://dzone.com/articles/solving-dependency-conflicts-in-maven

可能是之前测试短域名生成服务的时候，添加了 http://localhost:8080 的跳转，导致了此后所有对该地址的访问都被重定向到了另一个网址，即使我在 8080 端口的服务已经停止，并且已经更换了其他测试的服务，Chrome 依然缓存了 301 重定向。

而由因为跳转的时间非常快，所以我无法使用以前经常使用的 Ctrl+Shift+R 来强行刷新页面清除缓存。所以只能求助 Google，幸而操作并不复杂，不过让我学到了一些 Chrome 的小 tips，因此记录下来。

强制刷新

之前提到的 Ctrl + Shift + R 就能够强制刷新，但其实还有一种UI上面的操作，如果打开 DevTools 的情况下，点击刷新按钮，并长按，会弹出如下的菜单，选择 Empty Cache and Hard Reload 即可。

针对我的情况，直接打开 http://localhost 然后强行刷新即可。

开启 Devtools 中的停止缓存

开启 Developer Tools，一般的快捷键是 Ctrl + Shift + I ，如果从菜单上开启是Chrome的点点点 -> 工具 -> 开发者工具；或者任意的页面点击 Inspect 审查当前页面，就能打开。

然后再打开的开发者调试工具集中，打开 Settings，快捷键 F1，在工具集的右上角，点点点-> Settings。

在 Perferences -> Network 标签下 有一个 Disable Cache(while Devtools is open) ，选中即可。

最暴力清除数据

当然最暴力的就是清除数据了，不建议这么做。

reference

• https://superuser.com/a/869739/298782

UFW，全称 Uncomplicated Firewall，是通过 iptables 实现的防火墙工具。ufw 是对 iptables 的封装，iptables 的规则太过于复杂，不适合新手。这篇文章也是如何增强VPS安全性的扩展篇，在修改了SSH端口，登录用户之后，最好清楚自己开放了VPS的哪些端口访问，把他们用 ufw 管理起来，防止被滥用。

安装

Ubuntu 默认已经安装如果没有安装，使用一行命令即可：

sudo apt update && sudo apt install ufw

配置及使用

默认情况下，ufw 的配置文件在 /etc/default/ufw ，然后用户定义的防火墙规则文件会存在 /etc/ufw/*.rules 和 /lib/ufw/*.rules。

UFW 默认允许所哟出站连接，拒绝所有入站连接

sudo ufw default deny incoming
sudo ufw default allow outgoing

允许管理IPv6

sudo vim /etc/defaulf/ufw

然后修改

IPV6=yes

允许SSH连接

sudo ufw allow ssh
# 等价于
sudo ufw allow 22

如果修改了SSH连接端口，记住相应的允许端口连接。

允许HTTP/HTTPS

sudo ufw allow http
# 等价于
sudo ufw allow 80

sudo ufw allow https
sudo ufw allow 443

默认情况下 ufw allow 不加 in 是指允许入站连接，如果要允许出站，加上 out

sudo ufw allow in port
sudo ufw allow out port

允许指定端口的协议

sudo ufw allow ftp
# 等价于
sudo ufw allow 21/tcp

允许指定范围的端口连接和协议

sudo ufw allow 6000:6005/tcp
sudo ufw allow 7000:7005/udp

允许指定的IP连接

默认情况下相应的端口允许所有IP连接，通过from指定允许某IP的连接

sudo ufw allow from 123.45.67.89
sudo ufw allow from 123.45.67.89 to any port 22

如果要允许子网的连接

sudo ufw allow from 15.15.15.0/24
sudo ufw allow from 15.15.15.0/24 to any port 22

拒绝连接

和允许连接一样，只要将相应的allow换成 deny 即可

删除规则

首先查看当前的规则，并且打印出规则号

sudo ufw status numbered

每条规则前都有一个序号

sudo ufw delete [number]

也可以通过协议删除

sudo ufw delete allow http
# 等价于
sudo ufw delete allow 80

查看UFW状态

sudo ufw status verbose
sudo ufw show added

启用禁用UFW

sudo ufw enable
sudo ufw disable

ufw 默认会开机启动，如果没有，手动设置

sudo systemctl start ufw
sudo systemctl enable ufw

启用日志

sudo ufw logging on
sudo ufw logging off
sudo ufw logging low|medium|high    # 指定日志级别 日志文件在 /var/log/ufw.log

日志的格式

其中前面列出了主机防火墙日志的日期、时间、主机名，后面的内容意思是：

[UFW BLOCK]：表示事件描述的开始以及是何种事件。在此例中，它表示阻止了连接。 IN：如果它包含一个值，那么代表该事件是传入事件 OUT：如果它包含一个值，那么代表事件是传出事件 MAC：目的地和源 MAC 地址的组合 SRC：IP数据包的源IP DST：目的地的IP LEN：数据包长度 TTL：数据 TTL，或称为time to live。 PROTO：数据包的协议 SPT：数据包的源端口 DPT：目标端口 WINDOW：发送方可以接收的数据包的大小 SYN URGP：指示是否需要三次握手。 0 表示不需要。

重置防火墙

这条命令将禁用 ufw，并删除所有定义的规则

sudo ufw reset

默认情况下， ufw 会备份规则。

这里主要是介绍威联通 NAS 上面的 Virtualization Station （虚拟机工作站），这个应用能够在 NAS 上运行虚拟机，支持 Windows， Linux，Android 等等系统。威联通的虚拟机功能可以让用户在一台机器上同时运行多个系统。

Virtualization Station 支持通过 .ova, ovf, .qvm 或者 .ios 文件来安装虚拟化系统。

安装

使用这个虚拟机非常容易，直接在应用中安装 Virtualization Station 即可，然后在桌面上点击打开，就能够见到基本的界面，如下图

安装虚拟系统的方法也很简单，只要有系统 ova, ovf, qvm, 或者 iso 镜像就可以。

虚拟机的使用

和绝大部分虚拟机的需求一样，你可以在 NAS 的虚拟机上做任何事情，包括测试，备份，恢复等等。对于一个 7*24 小时都开着的机器来说，比如可以安装一个 Windows 虚拟机，将百度网盘的文件拖下来，使用 BT 软件挂机等等功能都可以被开发出来。

下面放一张图，可以解释为什么威联通里面有三个类似功能的 APP(Virtualization Station, Container Station, Linus Station) 他们的区别

总结来说 Virtualization Station 是一个虚拟机，在 NAS 上跑虚拟化的系统，虽然利用率，不错，但是可能比不上 Linus Station。而如果更加愿意使用单独的服务，比如跑 Docker ，那么 Container Station 其实更加适合。

因为威联通现在已经不支持百度云，所以在威联通上使用百度云非常的难受，只能够通过虚拟化 Windows 在 Windows 上跑百度云再将文件拉下来存到 NAS 上。

reference

• https://www.qnap.com/feature/virtualizationstation3/
• https://www.qnap.com/en/how-to/tutorial/article/how-to-use-virtualization-station

如今各种设备各种数据日益增多，当越来越多的私人数据需要存储时，NAS 进入了我的视线。早之前我以为云端存储可以涵盖我的一切，而我多年的数据也都安稳的存在互联网的各个领域，我的文件在 Dropbox，我的照片在 Google Photos，我的音乐原来在 Google Play Music，现在转移到了网易云音乐，我的书籍大部分都在 Kindle 上，也就是亚马逊的云上，我的文章、代码大都在 GitHub，我的笔记都在 WizNote，我的书签 Chrome 保存着，我的密码 LastPass 保存着。其实说实话原本这一切都是非常完美的，直到这两年网络越来越不稳定，互联网各种环境越来越糟糕，各种数据泄露让我原本一切都在云端的幻想破灭了，于是才有了这篇私有云储存。

为什么买这个 TS-453B mini，主要是便宜，4Bay 的 NAS 是最低，如果以后因为要升级可能会更加麻烦，至少 4Bay 的 NAS 我觉得近 5 年或者更远来说应该能够满足我个人的需求了。并且写下这篇文章的主要原因也是在初次使用 NAS 的时候需要解决的几个重要的问题，也就是我的主要需求。

从开始硬盘系统安装，到摸清楚其中的主要功能，也花了不少时间，写这篇文章的时候对这个威联通的 QTS 系统有并没有很深入的了解，唯一曾经看测评的时候就了解的功能就是他对虚拟化技术的使用，这是群晖所不拥有的。而其他同步文件，备份系统等等功能我以为应该是必须的功能，在威联通这边竟然有一丝丝的麻烦，我以为只需要安装一个同步软件或者工具就能够实现的功能而竟然还要稍微复杂一些些。不过这都不是什么问题，充分利用起他的硬件才是这篇文章想要探讨的事情。

在写这篇文章的时候 QNAP 发生了不知名错误，导致我无法登录 admin 页面，只能 reset，以至于丢失了我所有的设置和配置。只能从头再来，很麻烦。

QTS 系统

首先用 admin - admin 登录进去，第一步就是修改密码，添加二步验证，然后切换语言。

启用 myQNAPcloud 这样可以外网访问，不过也别抱太高期望，这个连接速度真的很慢。

然后去 App Center 中安装各种需要的应用。

然后可以去添加 QNAP Club 这个第三方应用商店，地址是这个 https://www.qnapclub.eu/en/repo.xml

更多关于 QTS 4.3.x 系统的使用可以查看官方的用户文档

存储空间总管

NAS 中非常重要的就是数据了，威联通在存储时引入了一些新概念。QNAP 引入了弹性磁盘区架构作为基础，包括了这些功能：

• 存储池和多个 RAID 群组
• 动态配置磁盘区和空间回收
• 快照和快照同步复制
• 在线扩充容量

威联通的弹性磁盘区架构从底层到上层，分别是磁盘管理、存储池管理、磁盘区管理及共享文件夹管理

基本存储管理架构

• RAID 群组：RAID 群组将多个实体硬盘组成一个逻辑单元，以提供数据备份、提升性能
• 存储池：存储池将实体硬盘或 RAID 群组合并成大型存储空间。存储池可以藉由在其中新增 RAID 群组，或将磁盘新增至当前 RAID 群组来进行扩充
• 热备份：热备份是 NAS 的备用硬盘，只会载 RAID 群组中的硬盘故障时使用。热备份会自动取代故障硬盘，数据也会在热备份中重建。
• 磁盘区：磁盘区是 NAS 上的存储空间。磁盘区为一存储单位，并可被格式化成文件系统来存储分享文件夹及文件。磁盘区有三种类型：完整配置、精简和静态。完整配置／精简磁盘区必须在存储池中创建，一个存储池可有多个完整配置／精简磁盘区。如果存储池的可用空间足够，完整配置／精简磁盘区可以调整至更大的容量。而静态磁盘区则是从 RAID 群组（而不是存储池）中创建的。静态磁盘区可以藉由在其中新增 RAID 群组，或将磁盘新增至当前 RAID 群组来进行扩充。
• iSCSI LUN：iSCSI LUN 是挂载到 iSCSI 目标的逻辑磁盘，LUN 的类型有两种：文件类型 LUN 和区块类型 LUN。区块类型 LUN 通常优先于文件类型 LUN。如需了解区块类型 LUN 和文件类型 LUN 的差异，请参阅 此处。
• 共享文件夹：共享文件夹会创建在磁盘区中，用于存储文件并将文件与拥有访问权限的用户或群组共享

威联通还提供了一种 Qtier 存储池（自动分层存储解决方案），由不同类型的硬盘（机械或 SSD）所组成而形成一个多硬盘磁盘区，在低负载期间或是根据您的计划， 将常用数据搬移到高性能硬盘（即 SSD）以达成高可用性或高 I/O 高速缓存吞吐量。将不常用的数据搬移到低成本的高容量硬盘（即 SATA 硬盘）以提高成本效益。

同步手机照片及文件

这其实是一个非常简单的需求了，不论是现在通过网络备份到 Google Photos 和 Flickr，还是说备份到小米的路由器上，都是一个非常容易实现的需求。在威联通的 QTS 上可以通过 Qfile 和 Qphoto 来实现。设置倒也简单。

自动备份照片的目的地址，千万不要选择 Qsync 的文件夹，选择 multimedia 或者其他文件夹，这样在 Linux SMB 访问的时候才能访问到。 QSync 文件夹内的内容是不支持 SAMBA，FTP，AFP 访问的。

SQL 服务

QNAP 自带 MySQL Server 设置中启用即可，用的是 MariaDB ，这是 MySQL 开源社区维护的一个分支。然后可以安装 phpMyAdmin 来管理 MySQL，默认的用户名和密码是 root 和 admin（如果设置过 NAS 密码，可以尝试 NAS 密码），如果要修改密码，可以再 phpMyAdmin 安装完成之后在 phpMyAdmin 后台 -> 权限中，编辑 root 在 localhost 的密码。参考官网.

SMB 挂载文件夹

在“控制台” - “网络与文件服务” 中开启 Samba，然后在局域网中就能够通过 SMB 来挂载 NAS 中的文件夹。

reference

• https://www.qnap.com/zh-cn/how-to/tutorial/beginner

RAID 全称 Redundant Array of Independent Disks，独立冗余磁盘阵列，将多块独立物理硬盘按不同方式组合形成一个逻辑硬盘，提供比单盘更高的存储性能和数据备份。

RAID 0

至少需要两块物理硬盘，将数据以位或者字节分割，并行地读 / 写到磁盘，但是没有数据冗余，当其中一块硬盘故障时，所有数据无法恢复。假设有两块物理硬盘前提下，读写速度提高 2 倍，数据安全性降低 2 倍。

RAID 0 不适用于数据安全性高的场合。

RAID 1

至少需要两块物理硬盘，通过磁盘数据镜像冗余，在成对的独立磁盘上互为备份。原始数据繁忙时，直接从镜像拷贝数据，RAID 1 可以提高读取性能。假设两块物理硬盘前提下，存储空间只能利用 50%，单位成本最高，提供很高的数据安全性和可用性，当其中一块硬盘故障时，可以自动切换到另一块磁盘读写。

RAID 1 适用于安全性要求比较高的场合。

RAID 3

至少需要三块物理硬盘，数据条块化分布不同硬盘，使用冗余的单块磁盘存放奇偶校验，当物理盘故障，奇偶盘和数据盘可以重新恢复数据，而如果奇偶盘故障则不影响数据使用。

RAID 3 可对连续数据读写提供很好的性能，但对于随机数据写操作可能成为瓶颈。

RAID 5

至少需要三块物理硬盘，提供热盘实现故障恢复，校验位会分布存放在三块磁盘中；当其中一块故障，则可以恢复数据；如果其中两块损坏，则所有数据都会损坏。

RAID 5 通过奇偶校验位提高了数据安全性，可实现单盘故障后的数据恢复。

RAID 10

又被称为 RAID 1+0 或者 RAID 0+1，至少需要四块物理磁盘。RAID 01 则是 1,2 磁盘，3,4 磁盘先组 RAID 0，然后组起的两个 RAID 0 阵列组 RAID 1。 RAID 10 则是先组 RAID 1 然后组 RAID 0。在提供性能的同时提供一定的安全性能。

总结

reference

• https://zh.wikipedia.org/wiki/RAID
• https://en.wikipedia.org/wiki/Nested_RAID_levels

在整理之前那篇 [Git 分支管理]¹ 的时候接触了 git bisect ，用了那么长时间的 git 竟然又出现了一个不曾用过的命令，于是就看了下文档学习下使用。

git bisect 使用二分查找来快速定位出错的 commit，举个例子来说，假设线上正常运行的一个版本，之后进行了大量的开发，提交了成百上千次提交，而导致了线上其中一个小功能的失效。为了定位问题，你可能需要查看过去的提交。

• 如果你知道这个功能具体在那个文件，那其实很好办，git blame 找出修改的部分，修正即可
• 而如果提交实在太多，无法定位问题文件的话，那么就需要使用 git bisect

git bisect 使用

在使用之前你需要知道两个前提，一个是已知的正常运行的版本，一个是出问题的版本，git bisect 会在两个版本之间使用二分查找，然后根据定位的 commit id 创建新的分支，然后在此分支上可以进行检查，是否有问题。

假设这个中间版本依然可以运行，那么通过 git bisect good 命令告诉 git，然后进行剩下一半的查找，以此类推，最终会快速的定位到问题所在 commit。因为每次都把提交历史切为两半，所以非常快，时间复杂度 log(n)

运行 git bisect 的整个过程

git bisect start         # 告诉 git 开始二分查找
git bisect good [good-commit-id] # 告诉 git 该版本无问题
git bisect bad [bad-commit-id]   # 告诉 git 出问题版本 git bisect bad HEAD
# 此时 git 就会检出中间版本，然后就可以去测试该版本
git bisect good/bad      # 此时就会遇到两种可能，有问题或者无问题，使用 good/bad 来告诉 git
# 当找到第一个问题版本后，git 会告诉你 bisect 结束
git bisect reset         # 返回到 git bisect 初始的版本
git bisect log           # 显示最后一次完全成功的 git bisect 日志

git branching

看完整个过程就知道了为什么在 [Git 分支管理]¹ 那篇文章中要提到这个 bisect 了，因为如果在 master 上的提交每次都 rebase ，而不是使用 merge ，就会让 master 分支非常干净，而 bisect 去查找的时候就不会那么的费力，而如果 master 分支非常多的分叉，查找过程就会非常费力了。