【hellocharts源码分析】【铣刀溯源码】【永恒online源码】10086源码购买
1.用建站ABC做的源码购买网站怎么样？
2.面试官说：你来设计一个短链接生成系统吧
用建站ABC做的网站怎么样？
首先，建站ABC的源码购买免费建站，然后想要升级就是源码购买交钱，里面一大堆缴费服务其次，源码购买售后的源码购买话，反正交钱之后就别想退款，源码购买hellocharts源码分析因为这个是源码购买相当于肉包子打狗
最后，说里面的源码购买东西的话，真的源码购买垃圾，服务器，源码购买端口，源码购买会员，源码购买其实就是源码购买给你个二级网站差不多，就好像去注册一个博客，源码购买想吃亏就可以考虑
面试官说：你来设计一个短链接生成系统吧
引言
相信大家在生活中，源码购买特别是铣刀溯源码最近的双十一活动期间，会收到很多短信，而那些短信都有两个特征，第一个是几乎都是垃圾短信，这个特点此处可以忽略不计，第二个特点是链接很短，比如下面这个：
我们知道，短信有些是有字数限制的，直接放一个带满各种参数的链接，不合适，另外一点是，不想暴露参数。好处无非以下：
太长的链接容易被限制长度
短链接看着简洁，长链接看着容易懵
安全，不想暴露参数
可以统一链接转换，当然也可以实现统计点击次数等操作
那背后的永恒online源码原理是什么呢？怎么实现的？让你实现这样的系统，你会怎么设计呢？来自于某鹅场面试官
短链接的原理短链接展示的逻辑这里最重要的知识点是重定向，先复习一下/tzHLFw与/gmccapp/webpage/payPhonemoney/index.html?channel=之间的装换是怎么样的呢？前面路径不变，变化的是后面，也就是tzHLFw与gmccapp/webpage/payPhonemoney/index.html?channel=之间的转换。
实际也很简单，就是数据库里面的一条数据，一个id对应长链接（相当于全局的发号器，全局唯一的ID）：
idurl1/gmccapp/webpage/payPhonemoney/index.html?channel=这里用到的，也就是我们之前说过的分布式全局唯一ID，如果我们直接用id作为参数，貌似也可以：/1，访问这个链接时，去数据库查询获得真正的url，再重定向。
单机的1688插件源码唯一ID很简单，用原子类AtomicLong就可以，但是分布式的就不行了，简单点可以用 redis，或者数据库自增，或者可以考虑Zookeeper之类的。
id 转换策略但是直接用递增的数字，有两个坏处：
数字很大的时候，还是很长
递增的数字，不安全，规律性太强了
明显我们平时看到的链接也不是数字的，一般都是大小写字母加上数字。为了缩短链接的长度，我们必须把id转换掉，比如我们的短链接由a-z,A-Z,0-9组成，相当于进制的春促源码数字，将id转换成为进制的数字:
publicclassShortUrl{ privatestaticfinalStringBASE="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";publicstaticStringtoBase(longnum){ StringBuilderresult=newStringBuilder();do{ inti=(int)(num%);result.append(BASE.charAt(i));num/=;}while(num>0);returnresult.reverse().toString();}publicstaticlongtoBase(Stringstr){ longresult=0;for(inti=0;i<str.length();i++){ result=result*+BASE.indexOf(str.charAt(i));}returnresult;}publicstaticvoidmain(String[]args){ //tzHLFwSystem.out.println(toBase("tzHLFw"));System.out.println(toBase(L));}}id转 位的key 或者key装换成为id都已经实现了，不过计算还是比较耗时的，不如加个字段存起来，于是数据库变成了：
idkeyurltzHLFw/gmccapp/webpage/payPhonemoney/index.html?channel=但是这样还是很容易被猜出这个id和key的对应关系，要是被遍历访问，那还是很不安全的，如果担心，可以随机将短链接的字符顺序打乱，或者在适当的位置加上一些随机生成的字符，比如第1，4，5位是随机字符，其他位置不变，只要我们计算的时候，将它对应的关系存到数据库，我们就可以通过连接的key找到对应的url。（值得注意的是，key必须是全局唯一的，如果冲突，必须重新生成）
一般短链接都有过期时间，那么我们也必须在数据库里面加上对应的字段，访问的时候，先判断是否过期，过期则不给予重定向。
性能考虑如果有很多短链接暴露出去了，数据库里面数据很多，这个时候可以考虑使用缓存优化，生成的时候顺便把缓存写入，然后读取的时候，走缓存即可，因为一般短链接和长链接的关系不会修改，即使修改，也是很低频的事情。
如果系统的id用完了怎么办？这种概率很小，如果真的发生，可以重用旧的已经失效的id号。
如果被人疯狂请求一些不存在的短链接怎么办？其实这就是缓存穿透，缓存穿透是指，缓存和数据库都没有的数据，被大量请求，比如订单号不可能为-1，但是用户请求了大量订单号为-1的数据，由于数据不存在，缓存就也不会存在该数据，所有的请求都会直接穿透到数据库。如果被恶意用户利用，疯狂请求不存在的数据，就会导致数据库压力过大，甚至垮掉。
针对这种情况，一般可以用布隆过滤器过滤掉不存在的数据请求，但是我们这里id本来就是递增且有序的，其实我们范围大致都是已知的，更加容易判断，超出的肯定不存在，或者请求到的时候，缓存里面放一个空对象也是没有问题的。
作者简介： 秦怀，公众号秦怀杂货店作者，技术之路不在一时，山高水长，纵使缓慢，驰而不息。个人写作方向：Java源码解析，JDBC，Mybatis，Spring，redis，分布式，剑指Offer，LeetCode等，认真写好每一篇文章，不喜欢标题党，不喜欢花里胡哨，大多写系列文章，不能保证我写的都完全正确，但是我保证所写的均经过实践或者查找资料。遗漏或者错误之处，还望指正。