短地址

 

web站点和wap站点本身的url实在是太长，其中有一些是历史遗留问题，有一些是不得不为之。而像专题活动这类的，很多时候需要用来营销。一个很长的url地址，太长， 不好看，所以就需要把长地址转为短地址。而就想新浪微博那样，你分享的帖子链接，会被自动转换为url.xxx的短地址类似。

短地址分为两个服务，一个是解析短地址（decode），一个是生成短地址（encode）。当然，其中也还涉及到缓存，负载均衡等问题。若一台服务器不能满足服务要求，那么负载均衡也就是势在必行了。

生成短地址，顾名思义，就是把web或wap的长地址转换为短地址。而短地址采用什么形式的编码呢。现在比较流行的，貌似是用[1-9|A-Z|a-z]共62个字符作为62进制编码使用。（ps:一开始没去网上看，后来做好了，想去看看别人是怎么做的，发现蛮多人都是这样的想法。）另外，涉及到方便营销，所以A-Z开头的短地址用于web站点，a-z开头的短地址用于wap站点,而0-9开头的短地址，就作为手工配置的预案，用于配置特别的短地址。

在上面的短地址分类中，A-Z开头和a-z开头的短地址，是通过httpInvoke来提供service服务。web站点和wap站点通过spring httpinvoke来调用。

缓存采用memcache。使用现有的四台缓存服务器来做缓存。如0001的短地址，对应http://www.ww.com?ca=2长地址;那么就会缓存有两个键值对，其中一个key为0001,value为http://www.ww.com?ca=2,另外一个key就是长地址，value为短地址。前者用于解析，后者用于生成。

生成短地址时，涉及到同步的问题，要考虑到短地址生成请求不会用同一个短地址生成，所以就做了如下的设计:

1.短地址与长地址的key-value匹配记录，在数据库中的主键ID和生成的短地址shortUrl形成一一对应。主键ID作为十进制数字，shoryUrl作为62进制数字。两者在数值上相等，如此就可以以主键ID对应短地址。（ps:0-9开头的特殊配置也可遵照这个规则）。

2.同步点,肯定不能在dao访问数据库insert数据时做同步控制。那么应该如何做呢？直接在内存里维护一个短地址最大编码对应的主键ID，写一个函数仅对这个主键ID做同步控制:

每个新的短地址请求，若在缓存中没有相应长地址的短地址存在，就会获取一个可用的短地址编码（已存在的短地址最大主键ID+1）,再调用dao insert 到db，若insert成功，则写入缓存，保留24小时。

而考虑到若由于网络或服务器的问题，产生访问数据库异常或其他问题，导致短地址浪费，所以定义一个内存map，用于存储dao insert异常的短地址。便于回收利用，并设置其最大数目，若超过则不生产新的短地址编码，而全部从map中获取，并提供日志报警。

又有一个新的问题，分布式情况下怎么办呢。这的确是相对前面比较棘手的问题。考虑之后，方案有以下几种:

1.memcache同步策略。采用memcache存储短地址最大编码的主键ID，这样的话多台服务器可以在这个ID上做同步控制，这样的话会存在同步锁频繁情况；

2.单台同步策略。采用一台服务器提供短地址最大编码的主键ID管理的服务，其他服务器通过访问服务来同步控制，但是这个方法就需要这个项目有两个版本，不好控制。

3. IP策略。因为公司的线上服务的ip是连续的，所以可以在生成算法中做一个跃步。如有4台服务器，IP分别为1,2,3,4.那么算法中就根据IP来取4的模，取得为m，每台服务器有一个自己的最大短地址编码ID。那么第1台生成的短地址主键ID为m依次为:1,4+1,4*2+1,...,4*n+1;第2台的主键ID一次为:2,4*1+2,...,4*n+2;第3和第4台类似。这样做的好处是项目只有一个版本，只用修改服务器台数。但涉及到一个问题是，若新增一台服务器或减少一台服务器，就会造成一个段地址管理婚礼和浪费。

4.范围控制策略。即若有4台服务器，若生成的短地址主键ID范围是0-1000.那么第1台生成的范围为:0-249;第2台为250-499;第3台为501-724;第4台为725-1000。这种情况下，项目版本也只需要一个版本，通过配置下限参数和上限参数来控制每台服务器的生成范围。优点是不易造成短地址浪费，也不会造成混乱。缺点就是需要对4个服务器的部署版本的上下限参数进行限制，在管理上有一定的瑕疵。

基本就想到以上几点。最终考虑了之后，选择了第4种方案。相比前三种，第4种只需要打包的时候打成4个部署版本即可。虽然麻烦了点，但是不会有其他的那些问题。当然，也可以集合第3方案的IP策略和第4中范围控制策略，但若IP不连续，那么就会存在问题了。(ps:若一台服务器的短地址用完了，怎么办，这个可以不会有上面问题，62进制的短地址版本，若是6位的话，就是62的6次方，很多很多...,若真出现了，那么日志会报警，可以进行范围升级)

解析短地址的话，就比较简单了，不做任何同步控制（ps：没有必要）。算法:

1.先查缓存，若有短地址对应的长地址，则直接重定向到长地址，否则进入2。

2.查询数据库，若有短地址对应的长地址，则直接重定向到长地址，否则进入3。

3,判断是A-Z开头还是a-z开头，若是前者就重定向到web首页，若是后者则重定向到wap首页，若是0-9，无法判断是web或wap，则默认跳转到web首页。(ps:0-9的配置，可以精细划分为0-4为web和5-9为wap，如此就不会默认跳转的问题)。

综合分析：因为解析短地址不会有同步控制，所以并发压力不算大。而生成短地址时，是对内存中的一个变量进行同步控制，速度非常的快，并发也不会存在太大问题。现在是单台服务器在跑，至今稳定运行中，没有出现什么问题（ps:网速慢除外）。

本来一直想写一下这个短地址的方案，但是一直在忙着sms系统的改版。再接再励...^_^,以后再写写下在线竞拍系统和osgi相关的东西。

 

原文地址:http://cmsky.yingjiawujin.com/?p=95