《系统设计访谈：内幕指南》08设计 URL 缩短器

# CHAPTER 7: DESIGN A UNIQUE ID GENERATOR IN DISTRIBUTED SYSTEMS

```
In this chapter, you are asked to design a unique ID generator in distributed systems. Your
first thought might be to use a primary key with the auto_increment attribute in a traditional
database. However, auto_increment does not work in a distributed environment because a
single database server is not large enough and generating unique IDs across multiple
databases with minimal delay is challenging.
Here are a few examples of unique IDs:

在本章中，您将被要求在分布式系统中设计一个唯一的 ID 生成器。

你首先想到的可能是在传统数据库中使用具有 auto_increment 属性的主键。但是，auto_increment在分布式环境中不起作用，因为单个数据库服务器不够大，并且跨多个数据库服务器生成唯一 ID

延迟最小的数据库具有挑战性。
以下是唯一 ID 的几个示例：
```



![image.png](/static/img/257d594df19977cd2836ea1f8aae1653.image.png)

## Step 1 - Understand the problem and establish design scope 第 1 步 - 了解问题并建立设计范围
```
Asking clarification questions is the first step to tackle any system design interview question.
Here is an example of candidate-interviewer interaction:
Candidate: What are the characteristics of unique IDs?
Interviewer: IDs must be unique and sortable.
Candidate: For each new record, does ID increment by 1?
Interviewer: The ID increments by time but not necessarily only increments by 1. IDs
created in the evening are larger than those created in the morning on the same day.
Candidate: Do IDs only contain numerical values?
Interviewer: Yes, that is correct.
Candidate: What is the ID length requirement?
Interviewer: IDs should fit into 64-bit.
Candidate: What is the scale of the system?
Interviewer: The system should be able to generate 10,000 IDs per second.

提出澄清问题是解决任何系统设计面试问题的第一步。
以下是候选人与面试官互动的示例：

应聘者：唯一 ID 有哪些特征？
面试官：ID 必须唯一且可排序。
应聘者：对于每条新记录，ID 是否递增 1？
面试官：ID 按时间递增，但不一定只递增 1。id晚上创建的比同一天早上创建的要大。
应聘者：ID 是否仅包含数值？
采访者：是的，没错。
应聘者：id长度要求是什么？
采访者：ID 应适合 64 位。
应聘者：系统的规模有多大？
采访者：系统应该每秒能够生成 10，000 个 ID。

```


```
Above are some of the sample questions that you can ask your interviewer. It is important to
understand the requirements and clarify ambiguities. For this interview question, the
requirements are listed as follows:
• IDs must be unique.
• IDs are numerical values only.
• IDs fit into 64-bit.
• IDs are ordered by date.
• Ability to generate over 10,000 unique IDs per second.

以上是您可以向面试官提出的一些示例问题。重要的是
了解要求并澄清歧义。对于这个面试问题，
要求如下：
• ID 必须是唯一的。
• ID 仅为数值。
• ID 适合 64 位。
• ID 按日期排序。
• 每秒能够生成超过10，000个唯一ID。
```

## Step 2 - Propose high-level design and get buy-in  第 2 步 - 提出高级设计并获得支持

```

Multiple options can be used to generate unique IDs in distributed systems. The options we
considered are:
• Multi-master replication
• Universally unique identifier (UUID)
• Ticket server
• Twitter snowflake approach
Let us look at each of them, how they work, and the pros/cons of each option.

可以使用多个选项在分布式系统中生成唯一 ID。我们的选项
考虑的是：
• 多主复制
• 通用唯一标识符 （UUID）
• 票务服务器
• 推特雪花方法
让我们看看它们中的每一个，它们是如何工作的，以及每个选项的优缺点。
```
### Multi-master replication  多主机复制
```
As shown in Figure 7-2, the first approach is multi-master replication
```

![image.png](/static/img/e40a8932dff49a5afd78edc5d51341db.image.png)

```
This approach uses the databases’ auto_increment feature. Instead of increasing the next ID
by 1, we increase it by k, where k is the number of database servers in use. As illustrated in
Figure 7-2, next ID to be generated is equal to the previous ID in the same server plus 2. This
solves some scalability issues because IDs can scale with the number of database servers.
However, this strategy has some major drawbacks:
• Hard to scale with multiple data centers
• IDs do not go up with time across multiple servers.
• It does not scale well when a server is added or removed.

此方法使用数据库的auto_increment功能。而不是增加下一个 ID
乘以 1，我们将其增加 k，其中 k 是正在使用的数据库服务器数。如
图 7-2，要生成的下一个 ID 等于同一服务器中的前一个 ID 加 2。这
解决了某些可伸缩性问题，因为 ID 可以随数据库服务器的数量而扩展。
但是，这种策略有一些主要缺点：
• 难以通过多个数据中心进行扩展
• ID 不会随着多个服务器的时间而增加。
• 添加或删除服务器时，它不能很好地扩展。
```

### UUID

```
A UUID is another easy way to obtain unique IDs. UUID is a 128-bit number used to identify
information in computer systems. UUID has a very low probability of getting collusion.
Quoted from Wikipedia, “after generating 1 billion UUIDs every second for approximately
100 years would the probability of creating a single duplicate reach 50%” [1].
Here is an example of UUID: 09c93e62-50b4-468d-bf8a-c07e1040bfb2. UUIDs can be
generated independently without coordination between servers. Figure 7-3 presents the
UUIDs design.

UUID 是获取唯一 ID 的另一种简单方法。UUID 是一个 128 位数字，用于识别
计算机系统中的信息。UUID获得勾结的可能性非常低。
引自维基百科，“在每秒生成 10 亿个 UUID 大约
100年后，创建单个副本的概率将达到50%“ [1]。
下面是 UUID 的示例：09c93e62-50b4-468d-bf8a-c07e1040bfb2。UUID 可以是
独立生成，无需服务器之间的协调。图 7-3 显示了
UUID 设计。

```

![image.png](/static/img/31daa93f2082d310340a9dc4effbf0a3.image.png)

```
In this design, each web server contains an ID generator, and a web server is responsible for
generating IDs independently.
Pros:
• Generating UUID is simple. No coordination between servers is needed so there will not
be any synchronization issues.
• The system is easy to scale because each web server is responsible for generating IDs
they consume. ID generator can easily scale with web servers.
Cons:
• IDs are 128 bits long, but our requirement is 64 bits.
• IDs do not go up with time.
• IDs could be non-numeric.


在此设计中，每个 Web 服务器都包含一个 ID 生成器，Web 服务器负责
独立生成 ID。
优点：
• 生成 UUID 非常简单。服务器之间不需要协调，因此不会
是任何同步问题。
• 系统易于扩展，因为每个 Web 服务器负责生成 ID
他们消费。ID生成器可以轻松地与Web服务器一起扩展。
缺点：
• ID 长度为 128 位，但我们的要求是 64 位。
• ID 不会随时间而增加。
• ID 可以是非数字。
```

### Ticket Server
```
Ticket servers are another interesting way to generate unique IDs. Flicker developed ticket
servers to generate distributed primary keys [2]. It is worth mentioning how the system
works.

票务服务器是生成唯一ID的另一种有趣方式。闪烁开发票
用于生成分布式主键 [2] 的服务器。值得一提的是系统如何
工程。
```

![image.png](/static/img/f8c24e8f323b8be3b0362065b3256b6f.image.png)

```
The idea is to use a centralized auto_increment feature in a single database server (Ticket
Server). To learn more about this, refer to flicker’s engineering blog article [2].
Pros:
• Numeric IDs.
• It is easy to implement, and it works for small to medium-scale applications.
Cons:
• Single point of failure. Single ticket server means if the ticket server goes down, all
systems that depend on it will face issues. To avoid a single point of failure, we can set up
multiple ticket servers. However, this will introduce new challenges such as data
synchronization.


这个想法是在单个数据库服务器中使用集中式auto_increment功能（票证服务器）。要了解更多信息，请参阅 flinker 的工程博客文章 [2]。
优点：
• 数字 ID。
• 它易于实施，适用于中小型应用。
缺点：
• 单点故障。单个票证服务器意味着如果票务服务器出现故障，则所有
依赖它的系统将面临问题。为了避免单点故障，我们可以设置
多个票务服务器。但是，这将带来新的挑战，例如数据同步。
```

### Twitter snowflake approach
```
Approaches mentioned above give us some ideas about how different ID generation systems
work. However, none of them meet our specific requirements; thus, we need another
approach. Twitter’s unique ID generation system called “snowflake” [3] is inspiring and can
satisfy our requirements.
Divide and conquer is our friend. Instead of generating an ID directly, we divide an ID into
different sections. Figure 7-5 shows the layout of a 64-bit ID.

上面提到的方法为我们提供了一些关于不同ID生成系统如何工作的想法。
但是，它们都不符合我们的特定要求;因此，我们需要另一个
方法。Twitter独特的ID生成系统称为“雪花”[3]，令人鼓舞，可以
满足我们的要求。
分而治之是我们的朋友。我们不是直接生成 ID，而是将 ID 划分为
不同的部分。图 7-5 显示了 64 位 ID 的布局。
```

![image.png](/static/img/9815dfa77fbef60c8aece9e5455beda9.image.png)

```

Each section is explained below.
• Sign bit: 1 bit. It will always be 0. This is reserved for future uses. It can potentially be
used to distinguish between signed and unsigned numbers.
• Timestamp: 41 bits. Milliseconds since the epoch or custom epoch. We use Twitter
snowflake default epoch 1288834974657, equivalent to Nov 04, 2010, 01:42:54 UTC.
• Datacenter ID: 5 bits, which gives us 2 ^ 5 = 32 datacenters.
• Machine ID: 5 bits, which gives us 2 ^ 5 = 32 machines per datacenter.
• Sequence number: 12 bits. For every ID generated on that machine/process, the sequence
number is incremented by 1. The number is reset to 0 every millisecond.

下面对每个部分进行说明。
• 符号位：1 位。它将始终为 0。这是保留供将来使用的。它可能是用于区分有符号和无符号数字。
• 时间戳：41 位。自纪元或自定义纪元以来的毫秒数。我们使用推特
雪花默认纪元1288834974657，相当于 2010 年 11 月 4 日 01：42：54 UTC。
• 数据中心 ID：5 位，这给了我们 2 ^ 5 = 32 个数据中心。
• 计算机 ID：5 位，每个数据中心有 2 ^ 5 = 32 台计算机。
• 序列号：12 位。对于在该计算机/进程上生成的每个 ID，序列
数字递增 1。该数字每毫秒重置为 0。
```

## Step 3 - Design deep dive
```
In the high-level design, we discussed various options to design a unique ID generator in
distributed systems. We settle on an approach that is based on the Twitter snowflake ID
generator. Let us dive deep into the design. To refresh our memory, the design diagram is
relisted below.






在高级设计中，我们讨论了在
分布式系统。我们确定了一种基于Twitter雪花ID的方法
发电机。让我们深入了解设计。为了刷新我们的记忆，设计图是
下面重新列出。
```

![image.png](/static/img/7bb1298aa40f7e12152736783d08ebb3.image.png)

```
Datacenter IDs and machine IDs are chosen at the startup time, generally fixed once the
system is up running. Any changes in datacenter IDs and machine IDs require careful review
since an accidental change in those values can lead to ID conflicts. Timestamp and sequence
numbers are generated when the ID generator is running.

数据中心 ID 和计算机 ID 在启动时选择，通常在
系统已启动运行。数据中心 ID 和计算机 ID 中的任何更改都需要仔细检查
因为这些值的意外更改可能会导致 ID 冲突。时间戳和顺序
数字是在 ID 生成器运行时生成的。
```


### Timestamp
```
The most important 41 bits make up the timestamp section. As timestamps grow with time,
IDs are sortable by time. Figure 7-7 shows an example of how binary representation is
converted to UTC. You can also convert UTC back to binary representation using a similar
method.

最重要的 41 位构成了时间戳部分。随着时间戳随着时间的推移而增长，
ID 可按时间排序。图 7-7 显示了二进制表示方式的示例
转换为 UTC。您还可以使用类似的方法将 UTC 转换回二进制表示形式
方法。
```



![image.png](/static/img/a68cf00bbae6d7bf71717ea278102498.image.png)
```
The maximum timestamp that can be represented in 41 bits is
2 ^ 41 - 1 = 2199023255551 milliseconds (ms), which gives us: ~ 69 years =
2199023255551 ms / 1000 seconds / 365 days / 24 hours/ 3600 seconds. This means the ID
generator will work for 69 years and having a custom epoch time close to today’s date delays
the overflow time. After 69 years, we will need a new epoch time or adopt other techniques
to migrate IDs.

可以用 41 位表示的最大时间戳为
2 ^ 41 - 1 = 2199023255551毫秒 （ms），它给我们：~ 69 年 =
2199023255551 毫秒 / 1000 秒 / 365 天 / 24 小时/ 3600 秒。这意味着 ID
生成器将工作 69 年，并具有接近今天的日期延迟的自定义纪元时间
溢出时间。69年后，我们将需要一个新的时代或采用其他技术
以迁移 ID。

```
### Sequence number
```
Sequence number is 12 bits, which give us 2 ^ 12 = 4096 combinations. This field is 0 unless
more than one ID is generated in a millisecond on the same server. In theory, a machine can
support a maximum of 4096 new IDs per millisecond.

序列号为 12 位，这给了我们 2 ^ 12 = 4096 种组合。此字段为 0，除非
在同一服务器上，一毫秒内生成多个 ID。从理论上讲，机器可以
每毫秒最多支持 4096 个新 ID。
```
## Step 4 - Wrap up
```
In this chapter, we discussed different approaches to design a unique ID generator: multimaster replication, UUID, ticket server, and Twitter snowflake-like unique ID generator. We
settle on snowflake as it supports all our use cases and is scalable in a distributed
environment.
If there is extra time at the end of the interview, here are a few additional talking points:
• Clock synchronization. In our design, we assume ID generation servers have the same
clock. This assumption might not be true when a server is running on multiple cores. The
same challenge exists in multi-machine scenarios. Solutions to clock synchronization are
out of the scope of this book; however, it is important to understand the problem exists.
Network Time Protocol is the most popular solution to this problem. For interested
readers, refer to the reference material [4].
• Section length tuning. For example, fewer sequence numbers but more timestamp bits
are effective for low concurrency and long-term applications.
• High availability. Since an ID generator is a mission-critical system, it must be highly
available.
Congratulations on getting this far! Now give yourself a pat on the back. Good job!

在本章中，我们讨论了设计唯一 ID 生成器的不同方法：多主复制、UUID、票务服务器和类似 Twitter 雪花的唯一 ID 生成器。我们
选择雪花，因为它支持我们所有的用例，并且可以在分布式中扩展
环境。
如果在面试结束时有额外的时间，这里有一些额外的谈话要点：
• 时钟同步。在我们的设计中，我们假设 ID 生成服务器具有相同的
时钟。当服务器在多个内核上运行时，此假设可能不正确。这
在多计算机方案中也存在相同的挑战。时钟同步的解决方案是
超出本书的范围;但是，了解问题存在很重要。
网络时间协议是此问题的最流行的解决方案。对于感兴趣的
读者请参考参考资料[4]。
• 节长调整。例如，更少的序列号，但更多的时间戳位
对低并发和长期应用程序有效。
• 高可用性。由于 ID 生成器是关键任务系统，因此它必须高度
可用。
恭喜你走到了这一步！现在拍拍自己的背。干得好！
```


## Reference materials

- [1] Universally unique identifier: https://en.wikipedia.org/wiki/Universally_unique_identifier
- [2] Ticket Servers: Distributed Unique Primary Keys on the Cheap:
https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-thecheap/
[3] Announcing Snowflake: https://blog.twitter.com/engineering/en_us/a/2010/announcingsnowflake.html
[4] Network time protocol: https://en.wikipedia.org/wiki/Network_Time_Protocol

《系统设计访谈：内幕指南》07 在分布式系统中设计唯一 ID 生成器

## 前言

正常情况下，Redis集群中数据都是均匀分配到每个节点，请求也会均匀的分布到每个分片上，但在一些特殊场景中，比如外部爬虫、攻击、热点商品等，最典型的就是明星在微博上宣布离婚，吃瓜群众纷纷涌入路演，导致微博评论功能崩溃，这种短时间内某些key访问量过于大，对于这种相同的key会请求到同一台数据分片上，导致该分片负责较高成为瓶颈问题，导致雪崩等一些问题。



## redis数据热点引起原因？
案例回答：

关于热点数据问题我有话要说，这个问题我早在刚刚学习使用 Redis 时就从已经意识到了，所以在使用时会刻意避免，坚决不会给自己挖坑，热点数据最大的问题会造成 Reids 集群负载不均衡（也就是数据倾斜）导致的故障，这些问题对于 Redis 集群都是致命打击。

先说说造成 Reids 集群负载不均衡故障的主要原因：

1. 高访问量的 Key，也就是热 key，根据过去的维护经验一个 key 访问的 QPS 超过 1000 就要高度关注了，比如热门商品，热门话题等。
2. 大 Value，有些 key 访问 QPS 虽然不高，但是由于 value 很大，造成网卡负载较大，网卡流量被打满，单台机器可能出现千兆 / 秒，IO 故障。
3. 热点 Key + 大 Value 同时存在，服务器杀手。


那么热点 key 或大 Value 会造成哪些故障呢：

1. 数据倾斜问题：大 Value 会导致集群不同节点数据分布不均匀，造成数据倾斜问题，大量读写比例非常高的请求都会落到同一个 redis server 上，该 redis 的负载就会严重升高，容易打挂。
2. QPS 倾斜：分片上的 QPS 不均。
3. 大 Value 会导致 Redis 服务器缓冲区不足，造成 get 超时。
3. 由于 Value 过大，导致机房网卡流量不足。
4. Redis 缓存失效导致数据库层被击穿的连锁反应。


> reds缓存穿透

理解重在穿透吧，也就是访问透过redis直接经过mysql，通常是一个不存在的key,在数据库查询为null。每次请求落在数据库、并且高并发。数据库扛不住会挂掉。

解决方案：
1. 可以将查到的null设为该key的缓存对象
2. 可以根据明显错误的key在逻辑层就就行验证。
3. 可以分析用户行为，是否为故意请求或者爬虫、攻击者。针对用户访问做限制。
4. 用布隆过滤器(超大型hashmap)先过滤。


> redis缓存雪崩

理解雪崩，就是某东西蜂拥而至的意思，像雪崩一样。在这里，就是redis缓存集体大规模集体失效，在高并发情况下突然使得key大规模访问mysql，使得数据库崩掉。可以想象下国家人口老年化。以后那天人集中在70-80岁，就没人干活了。国家劳动力就造成压力。

解决方案：
1. 将key的过期时间后面加上一个随机数，让key均匀的失效。
2. 考虑用队列或者锁让程序执行在压力范围之内，当然这种方案可能会影响并发量。
3. 热点数据可以考虑不失效

> redis缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，好像蛮力击穿一样。

**缓存和击穿的不同**
1. 穿透的意思是想法绕过redis去使得数据库崩掉。
2. 而击穿你可以理解为正面刚击穿,这种通常为大量并发对一个key进行大规模的读写操作。这个key在缓存失效期间大量请求数据库，对数据库造成太大压力使得数据库崩掉。就比如在秒杀场景下10000块钱的mac和100块的mac这个100块的那个订单肯定会被抢到爆，不断的请求(当然具体秒杀有自己处理方式这里只是举个例子)。
3. 所以缓存击穿就是针对某个常用key大量请求导致数据库崩溃。


解决方案：
1. 可以使用互斥锁避免大量请求同时落到db。
2. 布隆过滤器，判断某个容器是否在集合中
3. 可以将缓存设置永不过期(适合部分情况)
4. 做好熔断、降级，防止系统崩溃。


## 真实项目中，热点数据问题如何准确定位的呢？


案例回答：
>这个问题的解决办法比较宽泛，要具体看不同业务场景，比如公司组织促销活动，那参加促销的商品肯定是有办法提前统计的，这种场景就可以通过预估法。对于突发事件，不确定因素，Redis 会自己监控热点数据。大概归纳下：

1. 提前获知法：根据业务，人肉统计 or 系统统计可能会成为热点的数据，如，促销活动商品，热门话题，节假日话题，纪念日活动等。
2. redis客户端收集法，调用端通过计数的方式统计 key 的请求次数，但是无法预知 key 的个数，代码侵入性强。
3. redis集群代理层统计。像 Twemproxy，codis 这些基于代理的 Redis 分布式架构，统一的入口，可以在 Proxy 层做收集上报，但是缺点很明显，并非所有的 Redis 集群架构都有 proxy。


![image.png](/static/img/104361c3ef3c4a4f2cd6e76dcd1cc9cf.image.png)

4. redis服务端收集。监控 Redis 单个分片的 QPS，发现 QPS 倾斜到一定程度的节点进行 monitor，获取热点 key， Redis 提供了 monitor 命令，可以统计出一段时间内的某 Redis 节点上的所有命令，分析热点 key，在高并发条件下，会存在内存暴涨和 Redis 性能的隐患，所以此种方法适合在短时间内使用；同样只能统计一个 Redis 节点的热点 key，对于集群需要汇总统计，业务角度讲稍微麻烦一点。

![image.png](/static/img/d7c38bc0bd6e2e643da6f732e2e11fd6.image.png)
5. 修改redis源码。我发现 Redis4.0 为我们带来了许多新特性，其中便包括基于 LFU 的热点 key 发现机制，有了这个新特性，我们就可以在此基础上实现热点 key 的统计，这个只是我的个人思路。


## 如何解决热点数据问题
案例回答：
> 关于如何治理热点数据问题，解决这个问题主要从两个方面考虑，第一是数据分片，让压力均摊到集群的多个分片上，防止单个机器打挂，第二是迁移隔离

概括总结：
1. key拆分。如果当前 key 的类型是一个二级数据结构，例如哈希类型。如果该哈希元素个数较多，可以考虑将当前 hash 进行拆分，这样该热点 key 可以拆分为若干个新的 key 分布到不同 Redis 节点上，从而减轻压力
2. 迁移热点key。以 Redis Cluster 为例，可以将热点 key 所在的 slot 单独迁移到一个新的 Redis 节点上，这样这个热点 key 即使 QPS 很高，也不会影响到整个集群的其他业务，还可以定制化开发，热点 key 自动迁移到独立节点上，这种方案也较多副本。
3. 热点key限流。对于读命令我们可以通过迁移热点 key 然后添加从节点来解决，对于写命令我们可以通过单独针对这个热点 key 来限流。
4. 增加本地缓存。对于数据一致性不是那么高的业务，可以将热点 key 缓存到业务机器的本地缓存中，因为是业务端的本地内存中，省去了一次远程的 IO 调用。但是当数据更新时，可能会造成业务和 Redis 数据不一致。

## redis支持丰富的数据类型，这些数据类型存储的大Value如何解决，线上有遇到这种情况吗？

案例回答：
> 相比热点 key 大概念，大 Value 的概念比好好理解，由于 Redis 是单线程运行的，如果一次操作的 value 很大会对整个 redis 的响应时间造成负面影响，因为 Redis 是 Key - Value 结构数据库，大 value 就是单个 value 占用内存较大，对 Redis 集群造成最直接的影响就是数据倾斜。

先说说多大的 Value 算大，根据公司基础架构给出的经验值可做以下划分：

* 大：string 类型 value > 10K，set、list、hash、zset 等集合数据类型中的元素个数 > 1000。
* 超大： string 类型 value > 100K，set、list、hash、zset 等集合数据类型中的元素个数 > 10000。


由于 Redis 是单线程运行的，如果一次操作的 value 很大会对整个 redis 的响应时间造成负面影响，所以，业务上能拆则拆，下面举几个典型的分拆方案：

1. 一个较大的 key-value 拆分成几个 key-value ，将操作压力平摊到多个 redis 实例中，降低对单个 redis 的 IO 影响
2. 将分拆后的几个 key-value 存储在一个 hash 中，每个 field 代表一个具体的属性，使用 hget,hmget 来获取部分的 value，使用 hset，hmset 来更新部分属性。
3. hash、set、zset、list 中存储过多的元素

类似于场景一中的第一个做法，可以将这些元素分拆。
以 hash 为例，原先的正常存取流程是:
```
hget(hashKey,field)
hset(hashKey,field,value)
```
现在，固定一个桶的数量，比如 10000，每次存取的时候，先在本地计算 field 的 hash 值，模除 10000，确定该 field 落在哪个 key 上，核心思想就是将 value 打散，每次只 get 你需要的。
```
newHashKey = hashKey +(hash(field)%10000)
hset(newHashKey,field,value)
hget(newHashKey,field)
```

redis热点数据问题解决方案

# 为什么不推荐使用物理外键

之前在设计数据库的时候，有思考过这个问题，到底应该在什么情况下使用外键，什么情况不使用外键？



## 1. 外键的介绍
> 什么是外键？

一个表中的foreign key指向另一个表中的primary key

用外键的好处：
* 外键的约束为我们保证了数据主从关系和产生的先后关系，保证数据的完整性和一致性
* 级联操作为update和delete带来了不少方便
* 能够增加ER图的可读性



建键的原则：
* 为关联字段创建外键
* 所有的键都必须唯一
* 避免使用复合键（复合键：表中两个或两个以上列的组合，它允许我们唯一标识表的每一行。）
* 外键总是关联唯一的键字段

[外键的好处](https://blog.csdn.net/yaochongchong/article/details/44308659)


用外键的成本你可以参考以下内容：

## 2. 外键的性能问题

为何说外键有性能问题？
1. 数据库需要维护外键的内部管理；

2. 外键等于把数据的一致性事务实现，全部交给数据库服务器完成；

3. 有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；

4. 外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

所以，如果项目的服务并发量（增加、删除操作），建议不用外键，大量的这些操作会对数据库服务器有成本消耗。如果查询比较多的，可以使用。

## 3. myql的外键设计问题（对SQl标准的背离）
虽然很多人都不推荐你在关系型数据库使用外键。 但你更多听到的是mysql的，而不是SQLserver或者其他。比较公认的是，他的外键设计得的确不是很好，限制多功能不强大等。（同样的，讨论是不是该用存储过程也存在这种思考）

这里贴上一些从博客园看到的，比较严重的问题。

* 所有tables必须是InnoDB型，它们不能说临时表
* 不支持对外键列的索引前缀。样的后果之一是BLOB和TEXT列不被包括在一个外键中，这是因为对这些列的索引必须总是包含一个前缀长度
* nnoDB不对那些外键或包含NULL列的被引用键值检查外键约束

关于对SQL标准的背离（这里只贴其中一个点）


默认的行为应被延迟检查（即约束仅在整个SQL语句被处理之后才被检查）

类似一般的MySQL，在一个插入，删除或更新许多行的SQL语句内，InnoDB逐行检查UNIQUE和FOREIGN KEY约束。

直到InnoDB实现延迟的约束检查之前，一些事情是不可能的，比如删除一个通过外键参考到自身的记录。

[详细参考](http://www.cnblogs.com/discuss/articles/1862244.html)

## 4. 不使用外键我们也有好的解决方案
外键是个好东西，他为选择了关系型数据库的我们做了约束和级联做了保障。但不使用物理外键的我们也有方案去实现我们的逻辑外键，并保证他正确运行。

数据库上的一个策略：可以选择大多数情况下我们只更新不删除，也就是逻辑删，不再使用的历史数据定期归档来减少压力。

代码上的各种设计和限制：对表范围的操作权限，开启事务去处理逻辑，有需要进行异步操作来提高性能的我们设计补偿机制去弥补，等等。

## 5. 外键对扩展性的限制和影响

在我的实际项目中，就靠这一点，直接放弃使用外键。如果表的扩展性需求很高，尽量远离外键。

计划赶不上变化，外键的主从关系是定的，然后你会因为这个做很多事情，但是万一哪天主键所在表就见鬼去了呢？万一哪天你发现外键表不是非得跟人家的主键挂上关系呢？就我经历过的来看，这种情况并不少见，尤其是数据库设计者水平不够高的情况下。

 

另一个看法比较主观，就是你让数据库去帮你管外键了，你平时写程序的时候就真的很思路清晰吗？因为某些原因（比如你想要的关系数据库不支持，mysql经常），有些地方你就不能设计外键了，到时候一有级联更新的需要时，一部分你靠物理外键，一部分你还得靠自己，我觉得还不如全靠代码逻辑去保证。即使你对业务理解深刻，对外键也掌握的透彻，你也不太希望老是你管一部分他管一部分吧？

## 6. 反对的声音
最后再来说说一些坚持用外键的思考

有人问：原本在物理外键的开销，在程序上不也有开销吗？的确，但是这样我们对优化性能的方式也灵活了，刚刚说的异步处理就是一种。视具体情况而定，如果设计的好，有时候某些无用数据你不是非得立刻删除他，甚至不是非得删除他。

[参考](http://www.justabug.net/think-in-mysql-foreign-key/)

为什么不推荐使用外键

## 1.docker-compose 安装
[官方文档](https://docs.docker.com/compose/install/)



核心命令：
```
# 下载并安装docker-compose命令
 sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# 修改文件权限为可执行
 sudo chmod +x /usr/local/bin/docker-compose
# 创建软链接， 让命令支持全局调用
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose 
# 验证命令是否安装成功
 docker-compose --version

```

## 2. 使用docker-compose 安装RabbitMq
### 2.1 设置rabbitMq数据存放目录 
首先创建RabbitMq目录文件在/usr/local/software/RabbitMq，这个路径可以自定义
```
mkdir /usr/local/software/RabbitMQ

cd /usr/local/software/RabbitMQ

```
### 2.2 创建RabbitMq的dockerfile.yml
在/usr/loacl/software/RabbitMq下创建dockerfile.yml文件

```
version: "3.8"
services:
  rabbitmq:
    image: daocloud.io/library/rabbitmq:3.8.7
    container_name: rabbitmq
    restart: always
    volumes:
      - ./data/:/var/lib/rabbitmq/
    ports:
      - 5672:5672
      - 15672:15672

```

### 2.3 安装
通过docker-compose 安装rabbitMq
```
docker-compose up -d
```
## 3. 验证RabbitMq是否安装成功
```
curl localhost:5672 --output run.log |cat run.log

```

## 4. 开启图形化管理
### 4.1 进入容器内部
```
docker exec -it rabbitmq /bin/bash
```
### 4.2 进入rabbitmq默认安装目录
```
# 进入rabbitmq的可执行命令目录
cd /opt/rabbitmq/sbin
```

### 4.3 开启图形化管理
```
./rabbitmq-plugins enable rabbitmq_management
```

开启成功如下图：

![image.png](/static/img/1e4956e0e79e436b0dcbcdfb329172cd.image.png)





### 4.4 防火墙跟安全组

如果在本地虚拟机，只需要关闭防火墙即可。
如果是云服务器，需要在安全组配置准入规则，开放15672端口，如果防火墙开启了，需要在防火墙的配置15672端口放行，重启防火墙才可以。

之后可以通过Ip:15672端口访问图形化界面，

默认账号：guest
默认密码：guest

![image.png](/static/img/7fbd17fa8ee40350924f4b68f7a6ff2e.image.png)

CHAPTER 8: DESIGN A URL SHORTENER

CHAPTER 7: DESIGN A UNIQUE ID GENERATOR IN DISTRIBUTED SYSTEMS

前言

为什么不推荐使用物理外键

1.docker-compose 安装