短连接原理

1. 什么是短连接

  顾名思义，短连接便是长度较短的网址。经过短连接技术，咱们能够将长度较长的连接压缩成较短的连接。并经过跳转的方式，将用户请求由短连接重定向到长连接上去。短连接主要用在诸如微博，BBS等对帖子字数有限制的网站，经过使用短连接，用户能够把注意力放在帖子的内容上，而不是在担忧连接超长的问题。这里以百度的 dwz.cn 短连接服务为例，咱们使用百度搜索"hello world"，连接为 https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=0&rsv_idx=1&tn=baidu&wd=hello%20world&rsv_pq=8487bffe00068c60&rsv_t=a9e0f5b6haiMQwAi4N2y8PHDv37rM6sjjKrHJb6KdMGg2dQuUjAnmSEnXtE&rqlang=cn&rsv_enter=1&rsv_sug3=10&rsv_sug1=9&rsv_sug7=100，统计了一下，这条连接长度为230。如此长的连接占据微博篇幅不说，也会影响微博的美观度。这个时候咱们可使用百度短连接服务压缩一下上面的长连接，压缩后的连接为：http://dwz.cn/5DDXhH。能够看到，压缩后的连接长度比原连接明显变短了。

百度短连接服务

2. 常见的短连接压缩算法

  常见的短连接压缩算法有两种，第一种是对 URL 进行hash运算，在获得的hash值上作进一步运算，获得一个较短的hash值。第二种是经过数据库自增ID或分布式key-value系统模拟发号器进行发号压缩URL。两种方式各有优劣，hash运算简单易实现，可是有必定的冲突率。随着 URL 压缩数量的增长，冲突数也会增长，最终致使一部分用户跳转到错误的地址上，影响用户体验。而发号器发号压缩 URL 优缺点刚好和hash压缩算法相反，优势是不存在冲突问题。缺点是，实现上稍复杂，要协调发号器取初始号。本文对应的练手项目是基于第二种压缩算法实现的，下面也将对详细分析第二种算法。

3. 使用发号策略压缩URL

  发号策略是这样的，当一个新的连接过来时，发号器发一个号与之对应。日后只要有新连接过来，发号器不停发号就好。举个例子，第一个进来的连接发号器发0号，对应的短连接为 xx.xxx/0，第二个进来的连接发号器发1号，对应的短连接为 xx.xxx/1，以此类推。
  发号器发出的10进制号须要转换成62进制，这样能够大大缩短号码转换成字符串后的长度。好比发号器发出 10,000,000,000 这个号码，若是不转换成62进制，直接拼接在域名后面，获得这样一个连接 xx.xxx/10000000000。将上面的号码转换成62进制，结果为AOYKUa，长度只有6位，拼接获得的连接为 xx.xxx/AOYKUa。能够看得出，进制转换后获得的短连接长度变短了一些。6位62进制数，对应的号码空间为62⁶，约等于568亿。也就是说发号器能够发568亿个号，这个号码空间应该可以知足多数项目的需求了，因此基本上不用担忧发号器无号可发的状况。
  上述是发号策略压缩URL的原理，实际在写代码的过程当中还须要考虑不少细节，好比缓存，存储等。本文对应的项目使用的缓存是 Guava 工具包中提供的缓存模块，数据库使用的是 MySQL。基于上述两个工具以及其余一些第三方库，项目实现了URL压缩，还原以及跳转功能三个基础的功能。项目代码放到了 Github 上了 -> 短连接练手项目代码

4. 几个细节问题

Q：同一长连接，每次转成的短连接是否同样

A：同一长连接，每次转成的短连接不必定同样，缘由在于若是查询缓存时，若是未命中，发号器会发新号给这个连接。须要说明的是，缓存应该缓存常常转换的热门连接，假设设定缓存过时时间为一小时，若是某个连接很活跃的话，缓存查询命中后，缓存会刷新这个连接的存活时间，从新计时，这个连接就会长久存在缓存中。对于一些生僻连接，从存入缓存开始，在存活时间内极可能不会被再次访问，存活时间结束缓存会删除记录。下一次转换这个生僻连接，缓存不命中，发号器会从新发号。这样一来会致使一条长连接对应多条短连接的状况出现，不只浪费存储空间，又浪费发号器资源。那么是否有办法解决这个问题呢？是否是能够考虑创建一个长连接-短连接的key-value表，将全部的长连接和对应的短连接都存入其中，这样一来就实现了长短连接一一对应的了。可是想法是美好的，现实是不行的，缘由在于，将全部的长连接-短连接对存入这样的表中，自己就须要耗费大量的存储空间，相对于生僻连接可能会对应多条短连接浪费的那点空间，这样作显然就得不偿失了。

Q：短连接使用301跳转仍是302跳转

A：这里啰嗦一下301和302的跳转在短连接服务使用场景下的区别：用户第一次访问某个短连接后，若是服务器返回301状态码，则这个用户在后续屡次访问同一短连接时，浏览器会直接请求跳转地址，而不是短连接地址，这样一来服务器端就没法收到用户的请求。若是服务器返回302状态码，且告知浏览器不缓存短连接请求，那么用户每次访问短连接，都会先去短连接服务端取回长连接地址，而后在跳转。从语义上来讲，301跳转更为合适，由于是永久跳转，不会每次都访问服务端，还能够减少服务端压力。但若是使用301跳转，服务端就没法精确搜集用户的访问行为了。相反302跳转会致使服务端压力增大，但服务端此时就可精确搜集用户的访问行为。基于用户的访问行为，能够作一些分析，得出一些有意思的结论。好比能够根据用户IP地址得出用户区域分布状况，根据User-Agent消息头分析出用户使用不一样的操做系统以及浏览器比例等等。

参考

https://www.zhihu.com/question/29270034/answer/46446911
http://blog.csdn.net/xyz_lmn/article/details/8057270
http://blog.csdn.net/beiyeqingteng/article/details/7706010

本文在知识共享许可协议 4.0 下发布，转载请注明出处
做者：code4fun
为了得到更好的阅读体验，请移步至本人的我的博客：http://www.coolblog.xyz

本做品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。