python实现短网址系统

前言：    

    在看了这篇文章短 URL 系统是怎么设计的？之后打算自己实现一个出来。这个系统真的很简单，但是里面包含的内容却不少，体现出基本功。嗯，我的第一想法也是文章所说的最烂的方案

短URL系统主要解决下面几个问题：

     1·长URL怎么对应短URL（基本）

    2·短URL怎么还原成长URL（基本）

    3·如何提高并发能力（进阶

长URL怎么对应短URL：

    如果简单地以为可以寻找一个可逆算法，将一个长URL转换成短URL，然后逆运算回来就行了的话，you are native。这个想法有个致命的bug，就是如果真的找到，现在的所有压缩算法可以歇菜了。因为将一个可能是无限长的输入压缩成4，5个字符以内，这个压缩率是多么的厉害！

    其中一种正确的做法是通过发号器生成序号（类似银行的取号机），例如第一个网址是a.cn -> 1, 第二个网址b.cn->2, 第三个网址 c.cn->3,...如此下去，不但唯一，而且可以处理无穷多的URL（理论上）。不过这里还是不够好，当第9亿个URL的时候,d.cn->900000000，这样太长了，怎么缩短呢？对了，就是换进制，换成62进制（26+26+10）。5位的62进制已经是9亿多了，足够使用30年了。这里留个问题：怎么使得62进制看起来没有规律？例如1A的下一个不是1B，而是1m？

如何生成发号器：

    数据库的自增字段啊！我使用的是redis.incr()

短URL怎么还原成长URL：

    使用redis的key-value存起来，空间换时间。

应付高并发：

    多台redis发号器（做法就像利用id分库分表，一台发1，3，5，7。。。，一台发2，4，6，8。。。）

    文章中还有几个有趣的问题，读者们可以自己细细看看。这里我就说说301和302的重定向。百度的短网址是使用302（临时）重定向的。这里有两个好处，第一对于SEO是有好处的，第二对流量统计也是有好处的。一个坏处是服务器压力加大了（浏览器还是会访问我们的服务器）。使用301（永久）重定向，如果从业务角度来说应该是使用301的，明显是永久的重定向嘛。但是302的好处明显比较好。

    最后附上我的代码github，这个系统从实现到结束，大概花1小时半左右，因为真的太简单了。

如果想短网址一开始就是4位或者5位呢？就直接从1000（62）开始发号呀！