云服务器端口不能使用本人在部署短链接过程中，所以需要开启某个端口，遇到以下两种端口情况，希望能帮助到你！ 1.首先需要去阿里云服务器中开放端口安全组中： 2.除了上述端口开启完，你还需要让这个端口在终端可以使用！12# 使用这个命令查看，端口开放的情况，是否由于该端口已被占用ss -tuln | grep :80 若上述没有查找到指定端口被占用，并且端口也没有开放，则使用如下命令，因为阿里云服

两种常见的合并方式是 merge 和 rebase，它们各有优缺点，选择哪种方式需要根据具体情况来决定。 Merge 和 Rebase 的区别Mergemerge 是将两个分支的历史记录合并在一起，产生一个新的提交（merge commit）。它的好处是保留了完整的历史记录，所有的提交顺序和分支点都清晰可见。 示例： 12345# 切换到目标分支git checkout main# 合并 feat

背景当我们修改了短链接分组时，需要获取写锁；当我们自增短链接监控记录全局访问 PV、UV、UIP 时，获取读锁。 为什么需要读写锁？因为如果 Gid 变更后，新增短链接监控获取的是旧的 Gid，自增监控记录就会统计错误问题。 例子我们假设没有读写锁，流程如下： 线程 A 将短链接分组从 6688ja 变更为 8866ja。注意，这个是准备要修改，还没有执行成功； 同时记录短链接监控线程 B 获取

方案介绍 我们对比上面讨论的 6 种方案： 1.先写 Redis，再写 MySQL 这种方案，我肯定不会用，万一 DB 挂了，你把数据写到缓存，DB 无数据，这个是灾难性的； 我之前也见同学这么用过，如果写 DB 失败，对 Redis 进行逆操作，那如果逆操作失败呢，是不是还要搞个重试？ 2.先写 MySQL，再写 Redis 对于并发量、一致性要求不高的项目，很多就是这么用的，我之前也

什么是分片键用于将数据库（表）水平拆分的数据库字段。 例：将订单表中的订单主键的尾数取模分片。 简单来说，我们将短链接表拆分了 16 张分表，那用户新增短链接，怎么知道短链接记录应该放到哪张表里？这就需要用到分片键了，通过分片键进行一定规则（短链接表 t_link 使用的 HASH_MOD 方式）的运算，最终得到一个下标，这也就是我们要插入的分表位置。 得到一个下标指的是从 0-15 获取个值，

看代码时很多细节不记得了，所以用图帮助回忆项目的主要部分。 抽奖规则使用模板模式、责任链模式、组合模式定义抽奖规则，详情请见设计模式一节内容。 抽奖流程(draw)逻辑流程 与代码结合 签到返利（calendarSignRebate）日常的返利会根据用户所完成的行为动作来触达，这包括；打卡、签到、连签、支付、开户、交易、信贷、拉新等各类的动作。 我们以签到为例子： 逻辑流程 与代码结合 积分兑换

短链接跳转业务大多短链接系统短链接跳转逻辑应该是这样的：用户通过浏览器输入短链接访问，通过短链接获取到原始链接并进行跳转。 问题缓存击穿缓存击穿指在高并发的系统中，一个热点数据缓存过期或者在缓存中不存在，导致大量并发请求直接访问数据库，从而给数据库造成巨大压力，甚至可能引起宕机。 具体来说，当某个热点数据在缓存中过期时，如果此时有大量并发请求同时访问这个数据，由于缓存中不存在，所有请求都会直接访问

使用的什么方式生成短链接？通过 Hash 算法将原始连接转换成一个 Hash 码，使用了 Google 出品的 MurmurHash 算法。因为生成的 Hash 码是十进制的，整体较长不利于短链接传播。为此，我们将十进制转换为 62 进制，也就是咱们最终的短链接。 1. MurmurHash 算法对于选择哈希函数，有很多人可能会提到使用 MD5、SHA 等加密算法。其实我们并不关心反向解密的难度，

检查用户名是否存在使用布隆过滤器 用户注册如何防止用户名重复？通过布隆过滤器把所有用户名进行加载。这样该功能就能完全隔离数据库。 数据库层面添加唯一索引。 如何防止恶意请求毫秒级触发大量请求去一个未注册的用户名？因为用户名没注册，所以布隆过滤器不存在，代表着可以触发注册流程插入数据库。但是如果恶意请求短时间海量请求，这些请求都会落到数据库，造成数据库访问压力。这里通过分布式锁，锁定用户名进行串行

抽奖算法有不少，我们考虑稍微简单的两种。 我们的考量一、时间换空间可以抽奖的时候生成一个随机值，之后和概率范围for循环比对。这样的场景适合那种需要，非常大的空间存放抽奖概率，不划算的时候，可以考虑这种。 二、空间换时间提前计算好抽奖概率分布，用本地内存 guava 或者 redis 存储，最后抽奖的时候通过生成的随机值，在空间内定位即可，复杂度为O(1)。 计算公式： 找到范围内最小的概率