system desing 系统设计(四)：网站API和短网址short url的生成

　　1、（1）逆向APP时，第一个干的事就是抓包了，抓包的结果类似下面：

GET https://aweme.snssdk.com/aweme/v1/commit/item/digg/?aweme_id=6956180208793718055&type=1&channel_id=-1&city=510100&activity=0&os_api=22&device_type=M973Q&ssmix=a&manifest_version_code=150501&dpi=480&uuid=865166023654745&app_name=aweme&version_name=15.5.0&ts=1620296753&cpu_support64=false&app_type=normal&appTheme=light&ac=wifi&host_abi=armeabi-v7a&update_version_code=15509900&channel=xiaomi&_rticket=1620296754623&device_platform=android&iid=2744832902828125&version_code=150500&cdid=7addad62-d097-41da-b852-e0de8b24fe75&openudid=338803367b93a120&device_id=70039083151&resolution=1080*1920&os_version=5.1.1&language=zh&device_brand=Meizu&aid=1128&minor_status=0&mcc_mnc=46000 HTTP/1.1
Accept-Encoding: gzip
x-tt-dt: AAA7NE2KX2XRH5ZIBMIIJHUGNWEXQLPT2G5U2VKAPRSBVVGBNOLZGYT36N7VMCWTDFTQBQXBW6FSC2IWBD36QSIH6MSUI2SKDMHF4T27M5MS6TL2XHUCXVFWWDJM2Y3HQZEHXQ42UCB7JUEHURQRH6Y
passport-sdk-version: 18
X-Tt-Token: 000e8f473aea647b3c44fd3b9f7482439e02da23d858b1609a77f5edbf3bcc6c774f39175ea27eed09ffb2dee02c173fcc137b53019bb3614db48a84e88879cf2cabc8a810d38b88fb1d9bc7640b02e655a186f8b1e0daf197e60067b35a68adc68ad-1.0.1
sdk-version: 2
X-SS-REQ-TICKET: 1620296754625
Cookie: passport_csrf_token_default=f4442957bc07adf1986f4df139296dd7; install_id=2744832902828125; ttreq=1$184784690dc292ea1ad4e5db65553166a5674c3e; multi_sids=95063141447%3A0e8f473aea647b3c44fd3b9f7482439e; odin_tt=fac32cc300e49d8f22a70f1cd7b92569039d7305b6fdef7f2389cb98e0f9e9493f6c8374ad33dabed24ea41c55e1834e; n_mh=B6WRe0yd-1qIuffF6ZWNO-CSGlW1Q-VhC0E79NrqYTg; sid_guard=0e8f473aea647b3c44fd3b9f7482439e%7C1620296607%7C5184000%7CMon%2C+05-Jul-2021+10%3A23%3A27+GMT; uid_tt=d06498fc7329b7187e209d0e6279e1d7; sid_tt=0e8f473aea647b3c44fd3b9f7482439e; sessionid=0e8f473aea647b3c44fd3b9f7482439e;
X-Ladon: gW1IO3ulq0eYymnbYa+7nAu2l116ADdAdmSIA1eB3Cv5BBIo
X-Khronos: 1620296754
X-Gorgon: 0404401f40051f42c987ec09aebf8038d629adf2add584933f8f
X-Tyhon: s2S+nKZ8jrepKJ2VtCulu7carp/ZLqe2gn24aHA=
X-Argus: Uictv+neuH8ZqjOjXzvEIvXCEXYEgUy3dUKWzj08JUtmGeYa4HfNfN8bp7Yga22Jbik2N2dBKezA48YN1E9A1KaBjXi2ixu5cHzAkQU9Tl4f/+a9xWuLYIZ/+PkW/YXUsmRCfszWlcMePPeyNQYEGkb5FssTkIr3EZ87TJ9NLBDJCJGA0i4PICbLnClzdfmBs+57JVi1sU2/MELCr9gO/Nka5eIJsEoGB/CIaL3gPmEbZ0sUl7sxIvKksMwj3f7tYBCriYBKmfeREuiYf1S18c7i
Host: aweme.snssdk.com
Connection: Keep-Alive
User-Agent: okhttp/3.10.0.1

　　client和server通信靠的全是这类API的方式：要么是GET，要么是POST！后台又是怎么生成这些API接口的了？还是要靠springboot！文章末尾参考1有个工程，把unidbg和springboot结合起来了，用起来很方便，demo如下：

package com.anjia.unidbgserver.web;

import com.anjia.unidbgserver.service.TTEncryptServiceWorker;
import lombok.SneakyThrows;
import lombok.extern.slf4j.Slf4j;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

import javax.annotation.Resource;

/**
 * 控制类
 *
 * @author AnJia
 * @since 2021-07-26 18:31
 */
@Slf4j
@RestController
@RequestMapping(path = "/api/tt-encrypt", produces = MediaType.APPLICATION_JSON_VALUE)
public class TTEncryptController {

    @Resource(name = "ttEncryptWorker")
    private TTEncryptServiceWorker ttEncryptServiceWorker;

    /**
     * 获取ttEncrypt
     * <p>
     * public byte[] ttEncrypt(@RequestParam(required = false) String key1, @RequestBody String body)
     * // 这是接收一个url参数，名为key1,接收一个post或者put请求的body参数
     * key1是选填参数，不写也不报错，值为,body只有在请求方法是POST时才有，GET没有
     *
     * @return 结果
     */
    @SneakyThrows @RequestMapping(value = "encrypt", method = {RequestMethod.GET, RequestMethod.POST})
    public byte[] ttEncrypt(String key,String body1) {
        String key1 = key;
        String body = body1;
        /*String key1 = "key1";
        String body = "body";*/
        // 演示传参  http://127.0.0.1:9999/api/tt-encrypt/encrypt?key=aaaa&body1=bbbbb
        byte[] result = ttEncryptServiceWorker.ttEncrypt(key1, body).get();
        log.info("入参:key1:{},body:{},result:{}", key1, body, result);
        return result;
    }
}

　　类上面加了一个 @RequestMapping(path = "/api/tt-encrypt", produces = MediaType.APPLICATION_JSON_VALUE) 的注释，表明请求的API中，凡是有“api/tt-encrypt”路径的，都在这个类内部的方法中处理；再看类中有个方法叫ttEncrypt的，上面也带了@RequestMapping(value = "encrypt", method = {RequestMethod.GET, RequestMethod.POST})这样的注释，说明这个方法的访问路径是“/api/tt-encrypt/encrypt”，访问的方法可以是GET，也可以是POST！所以如果client想调用server的ttEncrypt方法，windows下完整的路径如为：http://127.0.0.1:9999/api/tt-encrypt/encrypt?key=aaaa&body1=bbbbb ，这样server就会执行ttEncrypt方法，然后把执行结果反回给client，是不是很方便了? 正式如此，spring相关的“脚手架”一跃成为java应用层开发的“一哥”！在浏览器调用API接口时，能看到的日志如下：

2022-08-16 16:19:59.054  INFO 9280 --- [nio-9999-exec-8] c.a.u.web.TTEncryptController   : 入参:key1:aaaa,body:bbbbb,result:[116, 99, 3, 0, 0, 1, -97, -48, -122, 106, -96, -53, -48, 50, 57, 51, -46, -46, -4, -116, 32, -20]

　（2）这种API接口的设计，业界最流行的莫过于rest风格了！这种风格的接口有几个要点：

　变化的部分做成参数，不变的部分做成路径！比如“POST /api/accounts/1/transfer/500/to/2/”就是错误的示范，正确的应该是这样：“POST /api/transaction/?from=1&to=2&money=500”；其实站在代码角度也容易理解：URL的路径最终会变成函数的路径，这部分代码写死后就固定了，没法变，能变的只能是参数了！这样做成松耦合的形式，也方便后续扩展！
常见的method除了GET、POST，还有DELETE、PUT等，建议都在@RequestMapping(value = "encrypt", method = {RequestMethod.GET, RequestMethod.POST})这类注释这里指定，而不是直接写死在URL里面：比如“/api/accounts/1/delete/” 这样就是错的，应该是“DELETE /api? account = 1”才对！

　 2、（1）大家平时常用的网址都很长，为了方便传输和使用【比如跨设备优化链接、跟踪单个链接以分析受众和活动绩效，以及隐藏关联的原始URL等】，短网址生成服务孕育而生（weibo这类对用户发帖长度有限制的站点尤为常见），其实原理也很简单：用户提供long url长网址，有专门的服务用特定的算法把long url转换short url！当用户访问short url时，转换服务会根据short url把long url找到，然后返回给client，并提示client需要301 redirect！过程图示如下：

　　设计这种长、短网址转换有两个最核心的点:

　server端的URL table的schema该怎么设计? 换句话说：长、短网址该怎么存储？存储的形式直接决定了读写的效率，也就是QPS！
long url怎么转成short url了？转换的算法间接决定了服务的效率！
short URL的长度多少合适了？short url取值是0-9、a-z、A-Z，一共62个字符；如果short url长度是5个字符，那么可以得到总的url数量就是62^5 = 9亿；依次类推: 62^6 = 570亿；62^7=35000亿；很明显：5位太少了，7位又太多了，6位刚好合适！当然，考虑到未来的扩展性，也可以选择7位的short url（毕竟有之前的IPV4经验教训，考虑远点也是对的）！每个url多一个字符，额外也耗费不了多少存储空间，对效率的影响并不明显；

　（2）先来看看转换的算法，业界主要有两种：随机生成和进制转换！

　（2.1）随机转换：从逻辑上讲，long url和short url并无直接的关联关系，怎么匹配完全可以开发人员自己确定，所以最直接、简单、粗暴的方法是随机生成一个字符串就能做为short url返回到client！注意：因为short url是随机生成的，返回给client前肯定要去重，所以理论上讲：short url生成的越多，去重的耗时越长，整个系统的效率就越低！

（2.2）进制转换：上面第一种生成随机数的方法越往后效率越低，核心原因就是short url多了以后去重很耗时，怎么改进这个了？既然生成的随机数不可控，那改成可控的自增数(auto increment sequential ID)的是不是就能解决去重耗时的这个问题了？显然是可行的！唯一的问题就是怎么把自增数转成0-9、a-z、A-Z组成的url了？本质上是个62进制转换的问题了！计算过程说明如下：

　　先确定映射表，比如这样的：char map[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789".toCharArray();
　　假如id= 12345，那么：
- 　　最后一个字符的offset就是12345%62=7，map[7]=h；
- 到数第二个字符：123456/62=199， 199%62=13，map[13]=n
- 到数第三个字符：199/62=3， 3%62=3，map[3]=d

所以12345转成short url的结果就是dnh（当然不足6位的可以用0补齐）！代码如下：

// Java program to generate short url from integer id and
// integer id back from short url.
import java.util.*;
import java.lang.*;
import java.io.*;

class GFG
{
    // Function to generate a short url from integer ID
    static String idToShortURL(int n)
    {
        // Map to store 62 possible characters
        char map[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789".toCharArray();
    
        StringBuffer shorturl = new StringBuffer();
    
        // Convert given integer id to a base 62 number
        while (n > 0)
        {
            // use above map to store actual character
            // in short url
            shorturl.append(map[n % 62]);
            n = n / 62;
        }
    
        // Reverse shortURL to complete base conversion
        return shorturl.reverse().toString();
    }
    
    // Function to get integer ID back from a short url
    static int shortURLtoID(String shortURL)
    {
        int id = 0; // initialize result
    
        // A simple base conversion logic
        for (int i = 0; i < shortURL.length(); i++)
        {
            if ('a' <= shortURL.charAt(i) &&
                    shortURL.charAt(i) <= 'z')
            id = id * 62 + shortURL.charAt(i) - 'a';
            if ('A' <= shortURL.charAt(i) &&
                    shortURL.charAt(i) <= 'Z')
            id = id * 62 + shortURL.charAt(i) - 'A' + 26;
            if ('0' <= shortURL.charAt(i) &&
                    shortURL.charAt(i) <= '9')
            id = id * 62 + shortURL.charAt(i) - '0' + 52;
        }
        return id;
    }
    
    // Driver Code
    public static void main (String[] args) throws IOException
    {
        int n = 12345;
        String shorturl = idToShortURL(n);
        System.out.println("Generated short url is " + shorturl);
        System.out.println("Id from url is " +
                            shortURLtoID(shorturl));
    }
}

// This code is contributed by shubham96301

　（3）因为要建立long url和short url的映射关系（方便查询），并且要持久化存储在磁盘，所以肯定是要使用数据库的！sql和NoSql怎么选了？挨个分析一下需求：

不需要transaction，Nosql+1
不需要复杂的sql查询，Nosql+1
对于QPS的要求：假设每天有10 milion的long url需要转成short url，那么：
- 　　average write QPS = 10million/86400= 115；考虑到白天可能有峰值，所以peak write QPS = 115*2=230；要求并不高，sql和NoSql都是可以的！
- 理论上讲：read的需求远比write的需求大，这里按照10~20倍估算，也就是average read QPS = 115*10=1150； peak read QPS = 115*20=2300，按照每条206byte计算，peak也才460KB，机械硬盘都能满足；sql和Nosql也是可以的！
对于磁盘的容量的要求：还是按照每天10million的需求计算：short url只有6byte，long url平均有200byte，那么存储一条记录需要206byte，每天需要消耗2GB磁盘，每年也才730GB的数据！10年也就消耗不到8TB的磁盘！

综上所述：存放的数据并不多，并且QPS也不高，配置稍微高点的单机服务器（cpu>=24core、内存>=256G、SSD>=12T等）都能满足需求！为了提高QPS，还可以在内存用hashMap缓存mapping关系！假设除去操作系统等必要的开销，还有200G的memory可用，理论上可在memory cache大约970million的mapping关系！由于内存的速度比硬盘快了好多数量级，TPS也能提升好多倍！

如果选用sql型数据库，比如mysql，那么表单schema的设计如下：

当然也可以是short url和long url：

因为sql型数据库可以根据不同的列建索引，所以上面两种schema二选一即可！但是如果用Nosql数据库，由于无法对不同的列建索引，所以可能需要两张表，这里以 Cassandra 为例子：

　第一张表：根据 Long 查询 Short，row_key=longURL, column_key=ShortURL, value=null or timestamp

　第二张表：根据 Short 查询 Long，row_key=shortURL, column_key=LongURL, value=null or timestamp

还有，由于Nosql数据库没有auto increment sequential ID，代码中需要额外考虑生成全局自增ID。由于自增ID只有在write的时候才需要，并且peak write QPS也才230，通过AtomicLong生成自增ID的压力也不大，完全能满足需求！

参考：

1、https://github.com/anjia0532/unidbg-boot-server unidbg+springboot多线程

2、https://cloud.tencent.com/developer/article/1872330 url短链接设计

3、https://www.geeksforgeeks.org/how-to-design-a-tiny-url-or-url-shortener/ 转换代码

posted @ 2022-08-16 20:47 第七子007 阅读(770) 评论(0) 编辑收藏举报

刷新页面返回顶部

第七子007

system desing 系统设计(四)：网站API和短网址short url的生成

公告