最近我操刀了leetcode的论坛迁移,整个过程持续了几周的时间,总算暂时告了一个段落。常使用leetcode论坛的用户应该已经发现论坛已经大变样了吧~
期间遇到了不少坑坑洼洼,将来也还会有好多问题等待去一一解决。关于这个迁移过程中的收货,这篇文章中就不细说了,有时间再另开一篇博文。这篇文章主要关注在url-mapping以及它的性能问题。
问:url-mapping的问题从何而来呢?
旧的论坛和新的论坛是两个不同的discuss框架。前者是 phpbb ,现在是 nodebb 。两者的 url routing 完全不一样,比如说同一个topic,
在原来的url是:
http://hostname/discuss/<topic_id>/<topic_name>
在新的论坛中是:
http://hostname/topic/<topic_id>/<topic_slug>
(这里就不讨论两者甚至连 topic_id 都不一样的问题了)。
而在广袤的互联网海洋中,旧论坛的url可能到处都存在。我们不希望在论坛迁移后,用户点那些链接就失效了。我们希望的是用户访问旧的url可以被重定向到新论坛的某个地址。所以就产生了url-mapping的问题。
方法
生成url-mapping
感谢 nodebb-plugin-import 提供了数据迁移以后自动生成url-mapping的方式,省了我自己写脚本生成这些mapping的时间。每一条mapping大致是这样的:
~^/discuss/questions/oj/add-two-numbers\b(\?[^/]*)*/?$ /category/10/add-two-numbers;
其中的 slug 和 id 的mapping是由插件生成的。 regular expression 是为了匹配url中如果有param添加的。
Nginx Map
官方文档 的demo可能对于刚想上手的同学来说不是那么友好,还是直接看现成的配置学得快:
http { ... map_hash_max_size 204800; map_hash_bucket_size 204800; map $request_uri $new { include /path/of/your/map/file; } include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; ... } server { ... if ($new) { rewrite ^ https://discuss.leetcode.com$new redirect; } location / { ... } ... } |
在server规则匹配中,$new值不为空,说明当前要访问的url已经在http模块的mapping文件中匹配到了,这个时候就不走各种 location 模块了,直接rewrite成新的地址。 注 :这里要是做成proxy_pass也行,后面的测试中就采用了proxy_pass。但线上的环境,担心nginx的压力太大了,就采用了rewrite方式给它减减压。
测试
考虑到mapping的条目有点多,几万量级,又都是正则匹配。每个请求来的时候都会先去看看mapping中有没有,即使mapping使用的是hash的方式也不免会让我对它的性能产生一些担忧,所以性能测试就必须要来一发了。
测试方案:
1、在新机器上跑helloworld
2、自动生成随机100个url-mapping,都重定向到helloworld
3、使用abtest分别对helloworld和随机url作压测
4、增大url-mapping的条目,重复1,2