# 进入定时任务编辑 crontab -e # 提交申请，我这里设置每两月一次，过期时间为三月 * * * */2 * cd /root/certificate/letsencrypt && ./letsencrypt-auto certonly --renew
nginx
yum install -y nginx
/etc/nginx/config.d/https.conf
server { # 使用 HTTP/2，需要 Nginx1.9.7 以上版本 listen 443 ssl http2 default_server; # 开启HSTS，并设置有效期为“6307200秒”（6个月），包括子域名(根据情况可删掉)，预加载到浏览器缓存(根据情况可删掉) add_header Strict-Transport-Security "max-age=6307200; preload"; # add_header Strict-Transport-Security "max-age=6307200; includeSubdomains; preload"; # 禁止被嵌入框架 add_header X-Frame-Options DENY; # 防止在IE9、Chrome和Safari中的MIME类型混淆攻击 add_header X-Content-Type-Options nosniff; # ssl 证书 ssl_certificate /etc/letsencrypt/live/www.luwuer.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.luwuer.com/privkey.pem; # OCSP Stapling 证书 ssl_trusted_certificate /etc/letsencrypt/live/www.luwuer.com/chain.pem; # OCSP Stapling 开启，OCSP是用于在线查询证书吊销情况的服务，使用OCSP Stapling能将证书有效状态的信息缓存到服务器，提高TLS握手速度 ssl_stapling_verify on; #OCSP Stapling 验证开启 ssl_stapling on; #用于查询OCSP服务器的DNS resolver 8.8.8.8 8.8.4.4 valid=300s; # DH-Key交换密钥文件位置 ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # 指定协议 TLS ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 加密套件,这里用了CloudFlare's Internet facing SSL cipher configuration ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; # 由服务器协商最佳的加密算法 ssl_prefer_server_ciphers on; server_name ~^(\w+\.)?(luwuer\.com)$; # $1 = 'blog.' || 'img.' || '' || 'www.' ; $2 = 'luwuer.com' set $pre $1; if ($pre = 'www.') { set $pre ''; } set $next $2; root /root/apps/$pre$next; location / { try_files $uri $uri/ /index.html; index index.html; } location ^~ /api/ { proxy_pass :3000/; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # socket代理配置 location /socket.io/ { proxy_pass :3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } # location /weibo/ { # proxy_pass https://api.weibo.com/; # } include /etc/nginx/utils/cache.conf; } server { listen 80; server_name ; rewrite ^(.*)$ https://$server_name$request_uri; }
附录
数据库存储结构思考历程
首先需求是画板可以作画实际大小为 { width: 1024px, height: 512px } ，这就意味着有 1024 * 512 = 524,288 个像素点，或则有 524,288 * 4 = 2,097,152 个表示颜色的数字，这些数据量在不做压缩的情况下，最小存储方式是后者剔除掉 rgba 中的 a ，也就是一个长度为 524,288 * 3 = 1,572,864 的数组，如果赋值给变量占用内存大概 1.5M （数据来源于 Chrome Memory）。为了存储以上结构，我首先分了两种类型的存储结构：
以点为对象存储，也就是说会有 524,288 条数据
颜色 rbga 存储，后优化为 rgb 存储
颜色 16 进制存储
整个画布数据当作一条数据存储
虽然看起来结构2有点蠢，但起初我确实思考过这样的结构，那时我还不清楚原来取数据最耗时的不是查询而是 IO 。
后来我分别测试 1.1 和 1.2 这两种结构，然后直接否定了结构 2，因为在测试中我发现了 IO 耗时占总耗时超过 98% ，而结构 2 无疑不能因为单条数据取得绝对的性能优势。
1.1
存储大小 10M
取出全部数据 8000+ms
全表查询 150ms （findOne 和 find 对比结果）
其余耗时 20ms （findOne 和 find 对比结果）
1.2
存储大小 10M
取出全部数据 7500+ms
全表查询
其余耗时
结构 2 如果取数据不是毫秒级，就是死刑，因为这种结构下单个像素变动就需要存储整个图片数据
老实讲这个测试结果让我有些难以接受，问了好几个认识的后端为什么性能这么差、有没有解决办法，但都没什么结果。更可怕的是，测试是在我 i7 CPU 的台式电脑上进行的，当我把测试环境放到单核服务器上时，取全表数据的耗时还要乘以 10 。好在只要想一个问题久了，即使有时只是想着这个问题发呆，也总能迸发出一些莫名的灵感。我想到了关键之一数据可以只在服务启动时取出放到内存中，像素发生改变时数据库和内存数据副本同步修改，于是得以继续开发下去。最终我选择了 1.1 的结构，选择原因和下文的“数据传输”有关。