我是Redis，一个叫Antirez的男人把我带到了这个世界上。

“快醒醒！快醒醒！”，隐隐约约，我听到有人在叫我。

慢慢睁开眼睛，原来旁边是MySQL大哥。

“我怎么睡着了？”

“嗨，你刚才是不是出现了错误，整个进程都崩溃了！害得一大堆查询请求都给我怼过来了！”，MySQL说到。

刚刚醒来，脑子还有点懵，MySQL大哥扶我起来继续工作。

“糟了！我之前缓存的数据全都不见了！”

“WTF？你没有做持久化吗？”，MySQL大哥一听脸色都变了。

我尴尬的摇了摇头，“我都是保存在内存中的，所以才那么快啊”

“那也可以在硬盘上保存一下啊，遇到这种情况全部从头再来建立缓存，这不浪费时间嘛！”

我点了点头，“让我琢磨一下，看看怎么做这个持久化”。

RDB持久化

没几天，我就拿出了一套方案：RDB

既然我的数据都在内存中存放着，最简单的就是遍历一遍把它们全都写入文件中。

为了节约空间，我定义了一个二进制的格式，把数据一条一条码在一起，生成了一个RDB文件。

不过我的数据量有点大，要是全部备份一次得花不少时间，所以不能太频繁的去做这事，要不然我不用干正事了，光花时间去备份了。

还有啊，要是一直没有写入操作，都是读取操作，那我也不用重复备份，浪费时间。

思来想去，我决定提供一个配置参数，既可以支持周期性备份，也可以避免做无用功。

就像这样：

• save 900 1 # 900秒（15分钟）内有1个写入
• save 300 10 # 300秒（5分钟）内有10个写入
• save 60 10000 # 60秒（1分钟）内有10000个写入

多个条件可以组合使用，只要上面一个条件满足，我就会去进行备份。

后来我又想了一下，这样还是不行，我得fork出一个子进程去做这件事，不能浪费我的时间。

有了备份文件，下次我再遇到崩溃退出，甚至服务器断电罢工了，只要我的备份文件还在，我就能在启动的时候读取，快速恢复之前的状态啦！

MySQL:binlog

我带着这套方案，兴冲冲的拿给了MySQL大哥看了，期待他给我一些鼓励。

“老弟，你这个方案有点问题啊”，没想到，他竟给我浇了一盆冷水。

“问题？有什么问题？”

“你看啊，你这个周期性去备份，周期还是分钟级别的，你可知道咱们这服务每秒钟都要响应多少请求，像你这样不得丢失多少数据？”，MySQL语重心长的说到。

我一下有些气短了，“可是，这个备份一次要遍历全部数据，开销还是挺大的，不适合高频执行啊”

“谁叫你一次遍历全部数据了？来来来，我给你看个东西”，MySQL大哥把我带到了一个文件目录下：

• mysql-bin.000001
• mysql-bin.000002
• mysql-bin.000003
• ···

“看，这些是我的二进制日志binlog，你猜猜看里面都装了些什么？”，MySQL大哥指着这一堆文件说到。

我看了一眼，全是一堆二进制数据，这哪看得懂，我摇了摇头。

“这里面呀记录了我对数据执行更改的所有操作，像是INSERT，UPDATE、DELETE等等动作，等我要进行数据恢复的时候就可以派上大用场了”

听他这么一说，我一下来了灵感！告别了MySQL大哥，回去研究起新的方案来了。

AOF持久化

你们也知道，我也是基于命令式的，每天的工作就是响应业务程序发来的命令请求。

回来以后，我决定照葫芦画瓢，学着MySQL大哥的样子，把我执行的所有写入命令都记录下来，专门写入了一个文件，并给这种持久化方式也取了一个名字：AOF（Append Only File）。

不过我遇到了RDB方案同样的问题，我该多久写一次文件呢？

我肯定不能每执行一条写入命令就记录到文件中，那会严重拖垮我的性能！我决定准备一个缓冲区，然后把要记录的命令先临时保存在这里，然后再择机写入文件，我把这个临时缓冲区叫做aof_buf。

说干就干，我试了一下，竟然发现数据没有写入到文件中去。多方打听才知道，原来操作系统也有个缓存区，我写的数据被他缓存起来了，没有给我写入到文件中去，这不是坑爹呢嘛！

看来，我写完了还得要去刷新一下，把数据真正给写下去，思来想去，我还是提供一个参数，让业务程序去设置什么时候刷新吧。

appendfsync参数，三个取值：

• always: 每个事件周期都同步刷新一次
• everysec: 每一秒都同步刷新一次
• no: 我只管写，让操作系统自己决定什么时候真正写入吧

AOF重写

这一次我不像之前那么冲动，我决定先试运行一段时间再去告诉MySQL大哥，免得又被他戳到软肋。

试用了一段时间，各方面都运行良好，不过我发现随着时间的推移，我写的这个AOF备份文件越来越大，越来越大！不仅非常占硬盘空间，复制移动，加载分析都非常的麻烦耗时。

我得想个办法把文件给压缩一下，我把这个过程叫做AOF重写。

一开始，我打算去分析原来的AOF文件，然后将其中的冗余指令去掉，来给AOF文件瘦瘦身，不过我很快放弃了这个想法，这工作量实在太大了，分析起来也颇为麻烦，浪费很多精力跟时间。

原来的一条条记录这种方式实在是太笨了，数据改来改去，有很多中间状态都没用，我何不就把最终都数据状态记录下来就好了？

比如：

• RPUSH name_list'编程技术宇宙'
• RPUSH name_list'帅地玩编程'
• RPUSH name_list'后端技术学堂'

可以合并成一条搞定：

• RPUSH name_list '编程技术宇宙' '帅地玩编程' '后端技术学堂'

AOF文件重写的思路我是有了，不过这件事干起来还是很耗时间，我决定和RDB方式一样，fork出一个子进程来做这件事情。

谨慎如我，发现这样做之后，子进程在重写期间，我要是修改了数据，就会出现和重写的内容不一致的情况！MySQL大哥肯定会挑刺儿，我还得把这个漏洞给补上。

于是，我在之前的aof_buf之外，又准备了一个缓冲区：AOF重写缓冲区。

从创建重写子进程开始的那一刻起，我把后面来的写入命令也copy一份写到这个重写缓冲区中，等到子进程重写AOF文件结束之后，我再把这个缓冲区中的命令写入到新的AOF文件中。

最后再重命名新的AOF文件，替换掉原来的那个臃肿不堪的大文件，终于大功告成！

再三确定我的思路没有问题之后，我带着新的方案再次找到了MySQL大哥，我都做到这份儿上了，这一次，想必他应该无话可说了吧？

MySQL大哥看了我的方案露出了满意的笑容，只是问了一个问题：

这AOF方案这么好了，RDB方案是不是可以不要了呢？

万万没想到，他居然问我这个问题，我竟陷入了沉思，你觉得我该怎么回答好呢？

彩蛋

“你怎么又崩溃了？”

“不好意思，又遇到bug了，不过不用担心，我现在可以快速恢复了！”

“那老崩溃也不是事儿啊，你只有一个实例太不可靠了，去找几个帮手吧！”

作者：谭东

最近刚完成点播视频防盗链的部署，也对视频防盗链技术方案有了研究与了解。在这里给大家分享下技术方案和原理。

一、先说下为什么要防盗链？

这个主要是：

1. 网站方为了防止自己的点播服务器的资源和流量被盗用；
2. 保护视频版权；
3. 防止视频被下载盗用等。

二、防盗链技术方案

一般盗链者可以直接获取播放地址盗用或者破解播放器盗用、录屏盗用、下载盗用、视频链接破解提取原地址等方式进行盗链。

所以我们在防盗链时要综合这些因素考虑，当然不可能面面俱到，但是能够覆盖大部分常见的手段即可。

常见方案有：

1. 视频加水印；
2. 视频加DRM版权水印；
3. 视频加密；
4. 播放器加解密；
5. Referer防盗链；
6. URL防盗链；
7. 采用m3u8等盗链难度高的文件格式，也可以防下载；
8. IP黑白名单限制等。

说了这么多，我们来看看目前主流的视频防盗链技术方案，例如央视网、腾讯、优酷等平台一般都采用Referer防盗链和URL防盗链方式进行防盗链。针对直播视频防盗链或点播视频防下载，我们还可以将视频文件格式变成m3u8格式，这样可以防止视频被下载。

那么接下来我们就简单讲解下Referer防盗链和URL防盗链方案：

（1）Referer防盗链

Referer防盗链比较简单，是基于 HTTP 协议支持的 Referer 机制，通过播放请求 Header 中携带的 Referer 字段识别请求的来源。开发者可以设置一批域名为黑名单或白名单，CDN 节点将按照名单中的域名做鉴权，从而允许或拒绝播放请求。也就是携带了播放来源，如果播放这个视频源的页面地址不对的话，则会拒绝播放。当然Referer是可以伪造的，所以建议结合URL防盗链进行使用。

（2）URL防盗链

URL防盗链是主流防盗链方案，也是安全度比较高一种防盗链方式。当然也有称作是Token校验方式，也有叫做鉴权防盗链，这里统称URL防盗链。

URL防盗链可以设置很多功能，如视频链接过期时间、播放人数控制、视频播放时长控制（如试看5分钟这种功能）等等。而控制鉴权的这部分放在CDN节点中去处理。

URL防盗链，允许开发者将视频的播放控制参数以 QueryString 的形式拼接在视频 URL 中，CDN 节点将检查 URL 中的播放控制参数，并依据参数控制视频的播放。目前，Key 防盗链通过“过期时间参数”、“允许播放的 IP 数量参数”和“试看时间参数”，支持“防盗链有效时间控制”、“防盗链播放人数控制”和“视频播放时长控制”。

• 防盗链有效时间控制

在视频 URL 中指定过期时间。如果请求的视频 URL 已过期，则视频无法播放。通过这种方式，可以为视频 URL 设置有效时间，防范他人将视频 URL 转移到其他站点后长期使用。

• 防盗链播放人数控制

在视频 URL 中指定链接最多能供多少人播放。不在同一内网的播放终端，它们的公网 IP 一般是不同的。通过限制一个 URL 允许最多能被多少公网 IP 播放，就能够限制同一个 URL 可以播放的人数，从而可以防范他人将视频 URL 转移到其他站点后，无限制地分发给任意多的人数观看。

• 视频允许播放时长控制

在视频 URL 中指定试看时长（如仅允许播放视频的前5分钟）。通过这种方式，可以实现对未付费用户的试看功能。

URL防盗链功能简介：

• 支持在视频 URL 中指定过期时间，他人获取后无法长期使用。
• 支持在视频 URL 中指定最大允许播放 IP 数，他人获取后不能无限制地分发给更多人观看。
• 支持在视频 URL 中指定试看时长，实现试看功能。
• 开发者使用密钥KEY对视频 URL 签名，并在 URL 中带上签名结果。只要用户密钥不泄露，其他用户无法伪造视频 URL。
• CDN 节点检查视频 URL 中的参数和签名，对视频播放请求进行控制。如果请求检查不通过，则返回403响应码。
• 支持的文件类型：MP4、TS、M3U8、FLV、AAC、MOV、WMV、AVI、MP3、RMVB、MKV、MPG、3GP、WEBM、M4V、ASF、F4V、WAV、MPEG、VOB、RM、WMA、DAT、M4A、MPD、M4S。

三、具体URL防盗链生成和使用

URL的生成是由我们这边服务器处理的，根据指定规则进行生成防盗链处理后的URL。

URL的生成是由我们这边服务器处理的，根据指定规则进行生成防盗链处理后的URL。
URL的生成是由我们这边服务器处理的，根据指定规则进行生成防盗链处理后的URL。

• 开发者在视频的地址中均存在视频原始 URL。未开启防盗链时，使用视频原始 URL 即可播放视频。
• 开启 Key 防盗链后，视频原始 URL 不再能播放，此时需要构造视频的防盗链 URL，CDN解析鉴权通过后返回视频数据。

（1）生成URL

防盗链 URL 的生成规则是在原始 URL 尾部，以 QueryString 的方式加入防盗链参数，形如：

http://example.vod.com/dir1/myVideo.mp4?t=[t]&exper=[exper]&rlimit=[rlimit]&us=[us]&sign=[sign]

这几个参数含义：

• t（必填）：播放地址的过期时间戳，以 Unix 时间的十六进制小写形式表示；过期后该 URL 将不再有效，返回403响应码。考虑到机器之间可能存在时间差，防盗链 URL 的实际过期时间一般比指定的过期时间长5分钟，即额外给出300秒的容差时间；建议过期时间戳不要过短，确保视频有足够时间完整播放。
• exper（选填/选用）：试看时长，单位为秒，以十进制表示，不填或者填0表示不试看（即返回完整视频）；试看时长不要超过视频原始时长，否则可能导致播放失败。
• rlimit（选填/选用）：最多允许多少个不同 IP 的终端播放，以十进制表示，不填表示不做限制；当限制 URL 只能被1个人播放时，建议 rlimit 不要严格限制成1（例如可设置为3），因为移动端断网后重连 IP 可能改变。
• us（选填/选用）：链接标识，用于随机化一个防盗链 URL，增强链接的唯一性；建议每次生成防盗链 URL 时，指定一个随机的 us 值。
• sign（必填）：防盗链签名，以32个字符长的十六进制数表示，用于校验防盗链 URL 的合法性；签名校验失败将返回403响应码。

签名计算公式如下：

sign = md5(KEY + t + exper + rlimit + us)

有人可能注意到了，怎么多了一个KEY？这个KEY就是我们的一个密钥，CDN和我们生成URL的服务器都要使用相同的KEY才能进行加密和解密配对，开启 URL 防盗链时填写的密钥。必须由大小写字母（a - Z）或者数字（0 - 9）组成，长度在8 - 20个字符之间。

（2）防盗链URL生成示例：

例如视频原始地址：[https://example.vod.com/dir1/myVideo.mp4]()，密钥KEY为：24FEQmTzro4V5u3D5epW，随机字符串us为72d4cd1101，URL 的过期时间是2018年01月31日20:00（Unix 时间为1517400000）即t为1517400000这里就不设置exper和limit了。

计算签名：

sign = md5("24FEQmTzro4V5u3D5epW5a71afc072d4cd1101") = "01ad188259e1f34979c06a10e6d0fb89"

最后我们生成URL防盗链：

http://example.vod.com/dir1/myVideo.mp4?t=5a71afc0&us=72d4cd1101&sign=01ad188259e1f34979c06a10e6d0fb89

我们这边服务器自己按照规则生成防盗链后的URL即可，CDN结点也按照这个规则和KEY来进行鉴权即可，匹配即允许播放，否则不允许访问资源。

好了，大致内容就是这么多，是不是很简单？对视频防盗链有了进一步了解？当然如果你想防止下载的话，建议使用HLS（m3u8）文件格式来进行传输，这样可以避免文件下载，安全性更高，而且HLS（m3u8）也可以对分片文件进行标准化或者自定义加密，安全度会更高。

我们这边服务器自己按照规则生成防盗链后的URL即可，CDN结点也按照这个规则和KEY来进行鉴权即可，匹配即允许播放，否则不允许访问资源。

好了，大致内容就是这么多，是不是很简单？对视频防盗链有了进一步了解？当然如果你想防止下载的话，建议使用HLS（m3u8）文件格式来进行传输，这样可以避免文件下载，安全性更高，而且HLS（m3u8）也可以对分片文件进行标准化或者自定义加密，安全度会更高。
我们这边服务器自己按照规则生成防盗链后的URL即可，CDN结点也按照这个规则和KEY来进行鉴权即可，匹配即允许播放，否则不允许访问资源。

好了，大致内容就是这么多，是不是很简单？对视频防盗链有了进一步了解？当然如果你想防止下载的话，建议使用HLS（m3u8）文件格式来进行传输，这样可以避免文件下载，安全性更高，而且HLS（m3u8）也可以对分片文件进行标准化或者自定义加密，安全度会更高。