作者：京东零售郝彦军

什么是短网址？

短网址，是在长度上比较短的网址。简单来说就是帮您把冗长的URL地址缩短成8个字符以内的短网址。

当我们在腾讯、新浪发微博时，有时发很长的网址连接，但由于微博只限制140个字，所以微博就自动把您发的长网址给转换成短网址了。在微博和手机短信提醒等限制字数的地方来使用短网址，的确是一个不错的方案。

短网址通常使用“短域名/短码”的形式，打开短网址网页会直接跳转到长网址页面。例：3.cn/CdEyF2、t.cn/RlB2PdD、dwz.cn/134128 等短网址，分别是由以下短网址服务缩短后的网址京东短网址：http://s.3.cn/，新浪短网址：https://sina.lt/ ，百度短网址：http://dwz.cn/。

短网址服务主要包含功能：生成短网址（长网址缩短）、二维码简化、修改短网址、短网址跳转（访问短网址跳转到长网址）、唤醒APP、短网址统计等。

短网址能解决什么问题？

长网址存在的问题：

1、长网址的长度太长，下面的长网址，共记312个字符，在微博场景中，限制140字符，已无法发布出去。在短信场景中，限制70字符，会产生5条短信费用，被拆分后还无法访问，严重影响用户体验。http://wjorder-http.jd.com/scan/np?encodePrcode=2hP_lwNr&encodeShcode=2-S83&businessSource=1&scanSkuType=2&ec=1&salerId=167916&discountsUrl=%2F%2Fcoupon.m.jd.com%2Fcoupons%2Fshow.action%3FlinkKey%3DAAROH_xIpeffAs_-naABEFoePLd7eC4GJgwsPUkFtDqklu805DO1cEqFyTHVT7fbD12AHD7DElAKgh0pfvQpX-E5PbgwLQ&unionId=1001465750

2、长网址生成的二维码，极其复杂，导致手机扫描识别极其困难，低端手机甚至无法识别，严重影响用户体验。

短网址则完美解决了上述问题：

1、使用短网址服务缩短上面长网址后的短网址（3.cn/1jK-CDAE），仅有13个字符，在微博、短信等场景中发送十分容易，而且简洁清晰，用户体验极好。

2、短网址生成的二维码，极其简洁，非常容易识别，用户体验良好。

京东短网址的业务场景：

京东短网址http://s.3.cn/，是京东唯一的短网址服务平台，已应用到京东体系的各个业务场景中，日均产生1亿条带有3.cn的短消息，点击短网址还可直接唤起对应的APP和小程序。

如下图1-2是来自七鲜、金龙鱼、京东金融、蒙牛、京东等业务的营销消息，下图3-4是唤起七鲜小程序、京东APP、金融APP并跳转至落地页的截图。

图1

图2

图3

图4

京东短网址服务的架构优化：

改造前短网址生成流程图说明：

1、系统首先查询长网址（长链）是否已存在于redis（jimdb）或hbase中，

2、如果长链已存在，则表示该长网址已经生成过，可直接返回查到的短网址，流程结束。

3、如果长链不存在，则使用长网址进行MD5随机算法生成一个长串，并分成3段，转化成62进制短码，拼装成短网址，然后查询短网址（短链）是否存在于redis或hbase中

4、如果短链不存在，则保存长网址到短网址的映射、以及短网址到长网址的映射，到redis或hbase中，返回短网址，流程结束。

5、如果短链已存在，说明随机算法生成的短码发生了冲突碰撞，需要循环回到步骤3，加盐重新生成一个短码，直到生成的短码检测没有冲突后，走到步骤4结束。

从原流程图分析原系统优劣势：

优势：采用随机算法，同一长链在同一账号下始终唯一，适用于长网址大量重复生成的情景，可以在步骤2快速返回，且随机算法遍历难度相对较高。

劣势：外部操作太多，性能影响较大，每次生成短网址涉及的网络请求次数至少8次（2次查redis、2次写redis、2次查hbase、2次写hbase）。

且从上面步骤5可以看出，系统存在一个碰撞循环，随着短码数据量日益增加，碰撞率也会大大增加，每次碰撞都要额外增加1次redis与1次hbase查询，导致性能越来越差。

分析原流程&历史数据，寻找原流程优化点：

1、从原流程可以看出，如果继续采用随机算法，很难进行优化，因此，想到了可以采用自增算法，因为自增不存在碰撞，就不需要进行双向检索存储，能够极大的降低外部请求数。

2、分析历史数据发现，很少存在长网址被大量重复生成的情况，也就是说，可以采用自增算法的单向存储（仅存储短网址到长网址的映射），并不会增加存储量，反而会比随机算法的双向存储（存储短到长的映射，及长到短的映射，即双倍存储）节省存储量。

3、分析历史数据发现，90%超过1个月的短网址都不再有访问量了，同时调研业务也发现，43%用户1个月有效期就够了，46%用户3个月，10%用户1年，极少有用户需要短网址永久有效。

4、分析历史数据发现，生成的数据量很大，日均1亿+，且大多数短网址并不需要永久保存，需要做好清理规划

5、分析历史数据发现，生成量远大于跳转量，跳转服务流程简单仅做查询，优化空间不大，倒是对生成服务性能要求极高，优化重点在于生成服务。

优化后的短码生成流程说明：

1、系统直接采用自增算法生成了一个短码，因为自增算法没有了随机碰撞，也就不需要再检索短网址是否存在redis或hbase中。

2、直接保存短网址到长网址的映射到redis中，因为没有了检索长网址是否存在于redis或hbase，也就不再需要保存长网址到短网址的映射，也就可以把hbase的写入改成异步写入，然后直接返回短网址，流程结束。（可以看到系统仅剩下1次同步的redis操作，流程极大简化，可以预见接口性能将得到极大提升）

自研专利算法介绍

细心的同学可能会有疑问，上面的分布式自增算法是怎么实现的呢？

目前市面上已知方案，1、通过数据库自增（并发QPS数有限）2、通过redis自增（存在单key热点问题，也就是所有的发号请求都会打到同一分片上），两种方案均会增加性能损耗，且存在扩展瓶颈，无法满足京东的海量业务请求。3、雪花算法（长度太长不符合，短网址要求长度一般在7个字符）

因此设计了下面的专利自增算法：（性能近乎于内存，损耗可忽略）

下面介绍一下核心的自增算法原理：主要采用缓存发号加内存自增方式，既无碰撞率又性能极高，主要体现在下图的三条彩色通道上面。

1、绿色通道：内存发号，速度极快，每次从缓存取出10000个无重复号码，然后在内存中便可连续生成10000个短码，因此速度比传统基于数据库及缓存自增发号方式快万倍。

2、蓝色通道：缓存取号，依赖缓存保证分布式发号无碰撞，批量发号，每1万次内存绿色通道才走一次蓝色缓存通道取号，因此性能极高

3、红色通道：保障机制，保障生成的号码都在短网址对应长度的号码总容量范围内，仅在初始化及总容量用尽时执行，性能损耗可忽略不计。

长度&有效期规划：

• 有访问会自动延期N天（7位短码总容量3万亿，过期时间30天，每天有1000亿短码可用，30天内有1次访问就会重置30天有效期，也就是说保持“热数据”始终在redis中）

• 连续N天无访问自动回收（7位短码，连续30天没有访问的情况下，才会过期回收，也就是说“冷数据”无访问N天后会自动过期清理回收）

以下统计了最近6天的各短码长度的使用分布占比情况，目前使用最多的是7位与8位短码，占比总和近90%。其中43%的用户选择了30天有效期，46%的用户选择来了100天有效期。

提效成果：

Ø 接口性能极大提升：tp999：从150+ms ->7ms，解决了业务调用缓慢及超时的痛点

Ø 单机承载量极大提升：单机QPS：从497->10184，提升了20倍+，无扩容支撑了日生成量：从1千万->2亿+

Ø 按百度短网址费用核算，1年可节约2700万元（证明短网址产生价值很大

Ø redis缓存30天热数据，缓存量 1.2TB

Ø Hbase存储全量数据，存储量 4TB

Ø 6月18日生成量4.7亿、6月日均1亿、峰值QPS 7.2万

Ø 6月1日跳转量1600万、6月日均800万

Ø 线上仅8台4核docker（优化后日常节约了760核机器，618节约3572核）

Ø 有访问自动延期，无访问自动过期回收，避免了死码长期占用资源消耗费用，避免短码越积越多导致的数据量太大及性能下降，系统可长期稳定运行

创新性：

Ø 产出技术发明专利1篇，编号：JDZL2019N5022

Ø 技术关键点是分布式无碰撞高效短码生成算法：

Ø 该算法利用redis的incrby实现分布式号段发放（5位短码每次发放1000个号，当然6、7位短码可设置更大步长值10000个），利用本机原子id自增减少redis请求（每10000个id自增后请求1次redis），因为id始终自增所以短码无碰撞概率（id可以直接转化为62进制短码），避免了因短码碰撞带来的循环生成检索的性能开销。利用redis.set原子检测key不存在时才能设置成功实现分布式加锁，解决多线程并发重置问题，最终实现比传统自增方案快万倍的高性能无碰撞短码自增算法。

Ø 利用容量规划及过期时间机制（5位短码总容量9亿，有效期10天，每天有9千万可用），实现号段循环重复利用（10天后第1天的号段过期，可以再次使用）（当然如果是6位短码、总容量有550亿，有效期也可以更长。7位短码总容量3万亿，基本可以不用过期了），保障了系统的长期稳定运行。

影响力：

Ø 宙斯平台-京麦服务市场中上架，有**470+**京东商户应用使用。3.cn/1-jMkHBf

Ø 3.cn作为京东唯一的短网址服务平台，合作的应用50+（京东APP、京东金融、京东云、京东保险、七鲜、京东健康、京东物流等等）、小程序20+、合作的二级部门80+

京东短网址高可用提升最佳实践 | 京东云技术团队相关推荐

全链路压测构建高可用应用最佳实践
简介:电商大促.明星直播.在线教育等大量场景,用户访问量会在一定时间段剧增,或者在业务上云过程中需要高可用体系评估客户系统在云环境下面的性能表现,判断是否符合客户的预期. 通过阿里云的PTS+AHAS ...
腾讯云mysql高可用方案_腾讯云数据库团队：MySQL数据库的高可用性分析
作者介绍:易固武,腾讯高级工程师,参与腾讯账号安全建设,腾讯数据仓库(TDW)优化改造,腾讯云数据库等项目,对大规模分布式存储和计算系统有浓厚的兴趣和经历 MySQL数据库是目前开源应用最大的关系型数 ...
研发效能提升最佳实践的探索
GIAC(GLOBAL INTERNET ARCHITECTURE CONFERENCE)是长期关注互联网技术与架构的高可用架构技术社区和msup推出的,面向架构师.技术负责人及高端技术从业人员的年度 ...
移动App測试实战：顶级互联网企业软件測试和质量提升最佳实践
这篇是计算机类的优质预售推荐>>>><移动App測试实战:顶级互联网企业软件測试和质量提升最佳实践> 国内顶级互联网公司測试实战经验总结.阿里.腾讯.京东.携程.百 ...
高并发、高性能下的会员系统[同程艺龙] — 高可用架构设计实践
目录会员系统[同程艺龙] - 高可用架构设计实践 ES高可用方案 ES双中心主备集群架构 ES流量隔离三集群架构 ES集群深度优化提升会员Redis缓存方案 Redis双中心多集群架构高可用会员 ...
技术分享：从双11看实时数仓Hologres高可用设计与实践
简介:本文将会从阿里巴巴双11场景出发,分析实时数仓面临的高可用挑战以及针对性设计. 2021年阿里巴巴双11完美落下为帷幕,对消费者来说是一场购物盛宴,对背后的业务支撑技术人来说,更是一场年度大考. ...
阿里云AHAS Chaos：应用及业务高可用提升工具平台之故障演练
简介: 阿里云AHAS Chaos:应用及业务高可用提升工具平台之故障演练应用高可用服务AHAS及故障演练AHAS Chaos 应用高可用服务(Application High Availabili ...
你的可用性达标了吗？云端业务性能高可用的深度实践
近年来由于国内移动互联网的飞速发展,国内互联网用户也有了大踏步的飞跃.这对企业来说,既是机遇,也有挑战. 机遇在于,现实中如此多的互联网用户,都有可能是你的产品用户.尤其在当前流量为王的时代,如此大基 ...
从双11看实时数仓Hologres高可用设计与实践
2021年阿里巴巴双11完美落下为帷幕,对消费者来说是一场购物盛宴,对背后的业务支撑技术人来说,更是一场年度大考.在这场大考中,一站式实时数仓Hologres以每秒11.2亿条的高速写入,和每秒1.1 ...

京东短网址高可用提升最佳实践 | 京东云技术团队