水、设计、生活
昨天半夜又搞了一下web服务器，想着将calibre-web的静态目录static放到对象存储中，将web服务器的存储空间给解放出来，因为calibre-web的在线阅读用的目录就是static目录，整个目录一直是在不断的增长中的，calibre-web对整个解压目录没有采用统一文件夹，而是直接放到了static的跟目录下了。
这让整个迁移和实时解压文件产生了问题，将静态css，js这些文件通过腾讯的对象存储的挂载磁盘方式挂载static目录后python flash 对整个静态目录读写貌似慢了很多。主要体现在第一次对文件的读写上，因为要上传和实时解压上影响了程序响应效率。
既然上传资源文件到对象存储，那就继续考虑对象存储文件的外部访问通过对象存储的cdn方式访问。找到python flash_cdn 插件，可以统一配置 url_for调用static 的资源cdn 域名，在访问url_for函数生成时自动生成cdn 域名前缀的资源。
[……]
这两天测试了一次开通两个小蜜蜂账号，这样每天可以增加100本的存储量，小蜜蜂防止滥用下载的程序还挺严格，一不小心就被封禁下载4小时。试了很多次才用两个浏览器下载完成。
下载完的书籍重复还是很多，为了防止浪费每天的下载次数，通过chrome 的自定义搜索，在加入书库的时候先搜索一下书库是否存在相同的书，相同的话就不再下载。自定义搜索用起来还是挺好用的。
因为增加了书库下载量，自己感觉笔记本整天干转换，下载图书的工作太费硬盘，基本上calibre转换为epub和mobi时正常使用电脑都受影响。想着测试一下把calibre的本地书库整理工作放到华为云桌面上。复制文件迁移到云桌面，配置cos的本地同步工具，但从笔记本拷贝过去的本地同步工具还要全量上传一次到云存储上。迁移到云桌面后的书库目录有变化，又研究一下虚拟磁盘把云桌面的磁盘虚拟一个E盘出来，保持与原来相同的目录后cos本地同步工具就可以沿用同步记录了，不需要再次全量上传一次到云存储了。
[……]
因为calibre-web服务器环境目前基本稳定了，所以自己开始考虑如何进行图书墙的数据扩容问题了。前段时间因为需要下载图书，开通了小蜜蜂书库的vip，自己每天抽空把下载权限给用上，每天可以新增到书库50本新书，去掉重复的部分基本可以达到30本，一个月能新增1000本。一年能新增一万本图书，应该也能服务不少用户了。
小蜜蜂的书库基本都是正版书籍，在排版和质量上都能有所保障，之前的一部分图书是从其他网站下载的，很多不是亚马逊的版本。这几天我对重复图书的处理是不重复添加，现在想来应该重复添加才对，这样可以将原来非官方的图书版本更新掉，逐渐实现图书质量的提高，反正上传不花钱。只不过是重新覆盖一下。然后通过 calibre的插件 Find Duplicates 处理重复图书。
小蜜蜂的vip只需要30元每年，对于电子书资源来说性价比超高。但下载权限的限制也很明显，一天只能存储50本，一天只能下载20次,下载还有频率和带宽限制，好在打包下载速度还可以，一般50本下载下来需要20多分钟，不能一起下载，一次一个进程下载比较安全。
[……]
calibre-web 程序放在腾讯云中，用了腾讯云的cos对象存储来放置图书库。可以让书库容量变得接近无限大。
为了充分发挥对象存储的优势，通过修改模板文件和代码程序，把calibre-web 的缩略图和图书下载阅读都直接使用了对象存储的cdn访问。这样既能提高用户下载速度，又可以节约python转发对象存储内容的服务器算力，要让对象存储的请求数减少一些。cos对象存储的访问域名和对应的对象存储cdn域名是单独两个，直接使用对象存储域名还是cdn域名也是各有优缺点。
cdn域名可以对资源进行加速和缓存，而且能抵消一些免费cdn流量，用上cdn以后如果用户少也许空中率会没有这么高，基本还是回源访问的话达不到加速效果还损失下载时间。cdn另外一点是不能再通过对象存储的加密访问来防止盗链资源的发生。cdn加速效果和加密访问资源这个在后面需要继续测试和改进。
[……]
现在图书库中有1.3万本图书，其中有90%是从网上下载的各个网站的资源。书籍的meta编目信息混乱的很，标签有几千个，作者、书名、出版舍也都混乱。
因为一些网站为了推广自己而在图书的meta植入广告，如果是自己看一两本书没什么影响，几万本书的时候对资源统一管理，整理势在必行。好在calibre 可以辅助索引检索。自己人工用排序将没有意义书籍标签先处理了，处理了几千条。通过批量管理吭哧吭哧搞了一个小时，一晚上基本都在干整理标签的事。整理完以后还剩一些标签需要再规整，但先将广告标签和书名当标签的情况处理掉了。
整理书签顺道把放到出版社位置的广告也都删掉了，搞完书库的标签和出版社。后面发现作者和标题的重复人工基本无法处理，太分散，太难发现。
[……]
因为上周末在腾讯云上搭建了Calibre-web 程序。为了节省服务器硬盘，为了以后书库扩容方便，自己把书库文件通过腾讯云的对象存储挂载到云主机的方式存放的。
开始主要是想用腾讯云免费的50G对象存储（cos）空间，但后来发现用户对象存储好像天热比较适合这种固定且读写不频繁的图书库场景。
但用对象存储挂载到云服务器上发现读写瓶颈非常明显，基本上只要一更新calibre的数据库就会把 Calibre-web的程序搞崩溃。自己开始不知道是对象存储当磁盘挂载的读写造成的。结果反复的尝试和研究calibre-web的驱动方式与挂载磁盘的关系，一个劲的重启、删除数据库、重装来测试。
最后才发现原来是对象存储当磁盘使用不能把对象文件当数据库来使用。仔细研究了一下calibre管理图书的原理，发现书库的索引库放在了跟图书源文件一个目录，这行好处是可以配置一个数据库文件地址，就能按照数据相对索引到图书文件。
[……]
Calibre-web 程序本身自带了将图书文件存储在谷歌硬盘的解决方式，按照教程配置应该就可以搭建成功，为什么是应该呢？因为我还没有尝试这种在Google Dirve存放图书文件方式搭建。原因是我的谷歌硬盘只有15G大小（存储升级并不贵，1T空间貌似只需要9.9美元/月）。另外是在国内无法访问谷歌硬盘，这样在国内基本就无法使用这种方式。
所以只能自己用国内的存储方案来实现硬盘够大，还比较优惠的方案。开始我准备直接用腾讯云或者阿里云的服务器来买块大硬盘就可以提供服务了，但考虑到未来如果图书库越来越大的话备份和迁移服务器都会是比较麻烦的，重要的一点是把如此大的文件放到一台服务器备份也很麻烦，文件的下载速度完全取决于自己服务器的带宽能力，1M的服务器跑个web应用还可以，如果再加上大量图片和下载就不行了。
综合了阿里云和腾讯云的服务器的存储和对象存储后，直接在腾讯云的cos对象存储中存放40G的书库文件，腾讯云提供50G的cos对象存储免费空间，基本可以满足需要了，未来如果增长也只需按量付费就可以。
[……]
之前部署的 Calibre-web 书库一直遗留了一个问题，就是书库服务器软件自己开机无法自己启动 nginx，自己一直没有找到原因。这个问题加上 cloudatcast 的开发服务器性能不足和经常宕机直接导致了整个书库服务网址三天打鱼两天晒网。经常程序奔溃后我没有时间重启机器，然后几天就无法访问。
最近这段时间感觉书库服务器已经比较稳定了，今天中午休息时间正好有空，登上服务器仔细看看到底是什么问题。先是怀疑服务没有加入开机启动项，自己尝试了几种方式都不能正常开机启动。基本排除没有开机启动原因了。
联系自己手动通过 nginx 的命令行就可以开启服务，但直接使用系统服务却无法启动服务。感觉是开机启动的服务启动方式也许遇到了问题。开始模拟开机启动服务的方式启动 nginx 却发现报错显示服务启动失败，但 nginx 居然还在运行。仔细排查一下 nginx 的开机启动方式，具体报错居然是配制的访问日志没有权限写的问题。
[……]
昨天书库的 cloudatcost 服务器突然无法连接了，500 错误，在网站管理后台重启服务器，结果就连不上服务器了。
这种情况又没有什么办法重启服务器，也没有办法登录。只能在后台不断的尝试重启服务器，最后好像网站后台也没有办法重启服务器了，完全失联的感觉。
这下子就坑了，也许只能发个工单寻求支持了。
把很长时间不用的笔记本电脑启用了，然后尝试用笔记本来扩充书库，台式机硬盘已经爆满了。从百度网盘往下同步以前转存的书库中。
最后发现使用服务器提供的管理 Api 可以重启服务器。通过官方 app 重启了服务器可以正常连接了服务了，又把百度网盘拉下来的一部分书给整理了一下放到服务器上，大概增加 9G，同步模式太慢了。还需要优化上传方式，通过文件修改时间筛选好新增文件直接上上传。
[……]
新做的 Calibre-web 书库晚上又重新同步了一遍，整个同步基本是失败部分，只有 18M 需要同步。把几千个文件对比一遍用了很长时间。
做完以后星期日没有什么需要做的了，但早上醒来发现书库打不开了，请求基本没有响应，ssh 也连接不上服务器，看了一下管理后台显示服务器的 cpu 居然接近用到 500%，用服务器的 web 管理后台硬重启了服务器，重启后再测试发现负载正常了。这个问题需要持续观测一下，真的需要装一个监控软件看一下服务器一天的负载变化，研究下是不是自己服务器的配置分配过低了。
重启完成后测试书籍 send to kindle 的功能又不能访问了，是服务器的 dns 设置又被系统还原了，linux 的一些配置是一次性的，重启机器会被还原、学习了一下如何改服务器配置为不还原的修改，过程就是搜索。搜索完发现 linux 配置文件是只读的，保存不了，再学习如何保存，用 sudo 都不能保存，搞了很久发现 vi 编辑器保存命令后再加 ! 可以强制保存 。:wq! 这个命令保存即可，看到这个才对应起来在保存不成功时 linux 的提示有让强制保存加！的提示，可我这英文不好又给忽略了。还是要尽快磨块英语这把刀，绝对不会影响砍柴功，这个事情本是很简单的按照提示操作即可，但我居然用了几个小时才找到答案。
[……]