招牌疯子

如果之前有存每个图片的 key，再起一个 redis 做后端 zimg 服务器，然后写个脚本挨个下载原图然后重新上传到 redis 后端的 zimg 里面，这样最保险。 如果之前没有在数据库里保存 key，需要去遍历本地的文件夹，每个 md5 的文件夹里面的 0*0 文件就是原图，也是写个脚本挨个打开然后上传到新的 zimg 服务器上。

现在代码结构不是很清晰，想自己加storage backend的话建议仔细看看代码。

确实是少一种规定画布大小，不允许裁剪的方法，考虑将来支持。

Ummm... It's hard to scan the thumbnails' keys in backend db. If necessary, I suggest you do a transfer. You need write a shell to do these: - find all...

非常感谢！

图像内容小于画布的时候，背景色确实是可以调的，但是要再增加一个参数来传给 zimg，需要开发。 正常放大一个图片是不会出现图像内容小于画布的情况，把你出错的 url 贴一下。 `max_size`是设置在配置文件里的，不是传过来的。 https://github.com/buaazp/zimg/blob/master/bin/conf/zimg.lua#L93

现有的结构不好实现这样的功能。建议一台服务器起两个 zimg 实例，比如 ip:4869 和 ip:4868，前面用 nginx 配两个 upstream，叫 zimg-app1 和 zimg-app2，配置到两个 location 里面即可。

统一回复下，因为工作上面临的挑战更大（转码上亿次/天），发现了许多以前没遇到问题，主要是imagick在高压力下的崩溃和卡死，目前还没有找到根本性的解决办法，所以不想放出一个半成品。新版本希望是生产级别的，编译部署非常简单的，而且接口会不兼容，还请耐心等待。

gmagick之前就测试过，跟imagick相比并没有什么提升，严重怀疑gmagick的性能数据是特殊环境benchmarketing出来的。

zimg 无状态，最简单可以多起几个实例，前面用 nginx 配一组 upstream 即可。