为啥要全站转go啊

语言本省造成的瓶颈不会太普遍啊，针对性的改成go版本。

其他还是保持php现状，多堆几台服务器而已。

全部转go，出于啥目的啊，作死的节奏....

不是类似virtualbox这样的东西，并没有完整虚拟一个OS，我的理解它只是个轻量级的应用层隔离。

类似FreeBSD下的jail。

所以说到资源，大致上只是多几个进程而已。

一、如果T_a T_b可以有较长时间停止数据更新
1. 修改业务代码，暂时停掉会导致T_a T_b更新的功能
2. 构建T_c
3. 直接切换到新业务代码使用T_c

二、如果T_a/T_b不能长时间停止写入
1. 写个触发器，记录T_a/T_b上的更新
2. 构建T_c
3. 停掉业务，把触发器收集到的更新记录还原到T_c上（量应该不会太大吧）
4. 切换到新业务代码使用T_c


以上只是随便想象，还需专业DBA来分析下

@Mac 旧表新增一列其实也是表复制，kw级的也得很久

动过ssl加密算法方面的配置参数？

@dale 没有深入折腾，当时拿来做收发传真的。 可能你要用到的模块会比较稳定。

还有当时买的山寨的PSTN网关设备对T38传真协议支持不行,后来放弃了。 改用最老式的56K猫和hylafax来收发传真。

顺便吐槽freeswitch

这玩意功能是强大，就是感觉架构不太合理，插件通过动态链接库形式载入，很考验插件开发人员水平啊，用过一段时间，稳定性不太让人满意。

freeswitch

以及PSTN网关设备，不知道是不是这么叫，就是voip到电话线路的设备

@dearroy 谢谢，直接reinstall了

貌似上个月微信改过一次登录页面，导致很多都失效了。

其实变化不大，不用现成的，自己写个模拟一下都很容易。

-_- , 我前两天美国的两个vps被黑了，多出了b26 b26h进程，一个月的流量几个小时被跑完，没准被拿来干DDOS去了。

印象中，没有哪个文件系统能吃得消这样整。

你这啥系统，设计方案有问题。

只要过程中不出现验证码，都好办。

@GTim
一般都缩略成jpg的吧，以ImageMagick为例

基本参数大致是 <尺寸变换参数> -type TrueColor <微调参数> +profile '*' -sampling-factor "1x1,1x1,1x1" -quantity 90 <input> jpg:<output>

当 imgW*imgH/toW/toH > 4.0 需要微调参数 -sharpen 1x1

只限宽度的，当 imgW/toW > 2.0 需要微调参数 -sharpen 1x1

如果原图是gif和png的类型可以带上微调参数 -mosaic

尺寸变化参数上也需要注意，
举个例子：
如果原图很大，但目标图只要200x宽的，
那从性能和最后的图片质量考虑可以直接采样 -size 500x 大小后再续处理
可以定几个采样区间。


以上只是些使用经验，仅供参考，专长不是图片处理方面的，如果描述有误请见谅:p

http://gi1.md.alicdn.com/imgextra/i1/401612253/T2ASPfXE4XXXXXXXXX_!!401612253.jpg_60x60.jpg 指的是这张图

一直也在用类似的图片动态缩略的网关。

1.支持任何图片源url
2.多种裁剪方式
3.可指定空白填色

额，前端配了个squid加速缓存

7年前最早用php写的，压力一大就渣了
5年前改成C写的fastcgi，存储是hash目录，都开到60个进程了，并发一大还是渣（无法分布式部署）
刚刚前几天用go重写了，存储用的redis协议加leveldb，保存原图和缩略图，热点数据识别，定时清理冷数据，可分布式部署。

公司线上在用，就不开源了。


另外，楼主的缩略参数得调调，大图缩小图，比例大于某个值得加锐化，要不然小图太雾蒙蒙了
当年对比flickr，测试无数次得到了一些参数值。

楼主还是先找份工作稳定一下吧

空余时间这个站还是做点百度喜欢的精品内容吧，这种信息在百度没啥前途。靠其他xxoo搜索引擎来的流量也有限得很，复制信息的站能有5w ip就了不得了。

个人做站主要还得靠SEO，基于用户这种得看机缘。

或者探索一下移动端领域，PC端越来越不好玩了。

楼主，你这个站这么搞淘宝客很危险啊，被淘宝发现就得封账号的节奏。

打开就自动跳转，属于cookie stuffing行为