Lecture 16 Cache Consistency Memcached at Facebook.srt

1
00:00:01,520 --> 00:00:10,920
好的，大家好，我今天要谈论这篇文章
all right hello everyone I'm today going
to talk about this paper about how

2
00:00:10,920 --> 00:00:19,109
 Facebook使用Memcache是​​为了处理巨大的负载
Facebook uses memcache I'm in order to
handle enormous load the reason we're

3
00:00:19,109 --> 00:00:23,750
阅读本文是因为这是一份经验论文，实际上没有任何内容
reading this paper is that it's an
experience paper there's not really any

4
00:00:23,750 --> 00:00:32,510
这里有新的概念，想法或技术，但这有点像是真实的生活
new concepts or ideas or techniques here
but it's kind of what a real live

5
00:00:32,840 --> 00:00:38,460
公司在尝试建立非常高的容量时遇到了麻烦
company ran into when they were trying
to build very high capacity

6
00:00:38,460 --> 00:00:44,160
基础设施您可以通过多种方式阅读它，一种是
infrastructure there's a couple of ways
you could read it one is a sort of

7
00:00:44,160 --> 00:00:49,800
关于如果您不认真对待一致性会出问题的警告性故事
cautionary tale about what goes wrong if
you don't take consistency seriously

8
00:00:49,800 --> 00:00:55,199
从一开始，另一种阅读方式就是关于这
from the start another way to read it is
that it's an impressive story about how

9
00:00:55,199 --> 00:01:02,300
通过使用大多数现成的软件获得极高的容量
to get extremely high capacity from
using mostly off-the-shelf software

10
00:01:03,019 --> 00:01:08,250
另一种阅读方式是它是一种说明或基本
another way to read it is that it's a
kind of illustration or the fundamental

11
00:01:08,250 --> 00:01:13,470
在试图变得很高之间，很多设置都面临着挣扎
struggle that a lot of setups face
between trying to get very high

12
00:01:13,470 --> 00:01:18,299
通过复制等方法以及如何保持一致性来实现的性能
performance which you do by things like
replication and how to give consistency

13
00:01:18,299 --> 00:01:24,180
像复制这样的技术真的是敌人，所以你知道我们
for which techniques like replication
are really the enemy and so you know we

14
00:01:24,180 --> 00:01:28,770
可以争论我们是否喜欢他们的设计，还是认为它是优雅的还是
can argue about whether we like their
design or we think it's elegant or a

15
00:01:28,770 --> 00:01:35,850
很好的解决方案，但我们不能真正与他们取得的成功争论不休，因此
good solution but we can't really argue
with how successful they've been so we

16
00:01:35,850 --> 00:01:40,020
确实需要认真对待它们，对我来说，实际上我首先
do need to take them seriously and for
me actually this paper which I first

17
00:01:40,020 --> 00:01:45,659
读了很多年前，我一直在想这件事， 
read quite a few years ago it's been I
thought about it a lot and it's been

18
00:01:45,659 --> 00:01:55,170
各种各样的想法和对问题的理解的来源
sort of a source of sort of ideas and
understanding about problems at many

19
00:01:55,170 --> 00:01:57,380
点数
points

20
00:01:57,890 --> 00:02:03,240
好的，所以在适当谈论Facebook之前，您知道他们是
all right so before talking about
Facebook proper you know they're an

21
00:02:03,240 --> 00:02:07,619
您经常看到或有很多人拥有的模式示例
example of a pattern that you see fairly
often or that many people have

22
00:02:07,619 --> 00:02:11,068
他们尝试建立网站来做某事的经验丰富，而您
experienced in which they're trying to
build a website to do something and you

23
00:02:11,068 --> 00:02:15,000
通常知道建立网站的人对建立高级网站不感兴趣
know typically people who build websites
are not interested in building high

24
00:02:15,000 --> 00:02:22,200
您知道的高性能高性能存储基础架构
performance you know high performance
storage infrastructure they're

25
00:02:22,200 --> 00:02:26,940
对构建使用户满意或出售的功能感兴趣
interested in building features that
will make their users happy or selling

26
00:02:26,940 --> 00:02:31,290
更多广告或您所知道的东西，所以它们不会以
more advertisements or something you
know so they they're not gonna start by

27
00:02:31,290 --> 00:02:35,400
花大量的时间或大量的时间来建立自己的风格
spending a main year of effort or a
whole lot of time building cool

28
00:02:35,400 --> 00:02:38,340
他们将首先构建基础设施，然后对其进行排序
infrastructure they're gonna start by
building features in that they'll sort

29
00:02:38,340 --> 00:02:42,989
仅在他们真正必须做到的范围内使基础设施更好
of make infrastructure better only to
the extent that they really have to

30
00:02:42,989 --> 00:02:47,910
因为你知道那是他们时间的最佳利用，所以这是一个典型的开始
because you know that's the best use of
their time alright so a typical starting

31
00:02:47,910 --> 00:02:54,180
一个网站很小的情况下的场景，您知道没有
scenario in a ways when a some website
is very small is you know there's no

32
00:02:54,180 --> 00:02:57,569
不仅可以从一台机器开始，还可以
point in starting with anything more
than just a single machine right you

33
00:02:57,569 --> 00:03:01,980
知道也许您刚开始时只有几个用户坐在他们前面
know maybe you started you only have a
couple users sitting in front of their

34
00:03:01,980 --> 00:03:07,260
浏览器，您知道他们在这里与您的单机通过Internet进行通信
browsers and you know they talk over the
internet here with your single machine

35
00:03:07,260 --> 00:03:16,170
您的单台计算机可能现在要运行Apache Web服务器，也许您
your single machine is gonna maybe run
the Apache web server now maybe you

36
00:03:16,170 --> 00:03:23,970
使用PHP或Python或其他一些语言编写用于生成网页的脚本
write the scripts that produce web pages
using PHP or Python or some other

37
00:03:23,970 --> 00:03:29,340
方便，易于编程的脚本风格语言和Facebook 
convenient easy to program sort of
scripting style language and Facebook

38
00:03:29,340 --> 00:03:36,000
使用PHP，您需要将数据存储在某个地方，也可以下载排序
uses PHP you need to store your data
somewhere or you can just download sort

39
00:03:36,000 --> 00:03:42,630
的标准数据库和Facebook碰巧使用了我的续集，我的学校很好
of standard database and Facebook happen
to use my sequel my school is a good

40
00:03:42,630 --> 00:03:49,079
选择，因为它实现了续集查询语言，功能非常强大且功能强大
choice because it implements the sequel
query language is very powerful and acid

41
00:03:49,079 --> 00:03:54,930
事务提供了持久的存储，所以这就像一个非常好的设置
transactions provides durable storage so
this is like a very very nice set up I

42
00:03:54,930 --> 00:04:00,450
其实我会带你走很长一段路，但是假设你成功了
am will take you a long way actually but
supposing supposing you get successful

43
00:04:00,450 --> 00:04:04,350
您获得越来越多的用户，您知道您将获得越来越多的负载
you get more and more users you know
you're gonna get more and more load more

44
00:04:04,350 --> 00:04:09,900
越来越多的人将浏览您的网站并运行任何PHP东西
and more people gonna be viewing your
website and running whatever PHP stuff

45
00:04:09,900 --> 00:04:14,970
您可以使用网站提供的内容，因此在某些时候
you're with
site provides and so at some point

46
00:04:14,970 --> 00:04:19,290
几乎可以肯定，第一个出错的地方是PHP 
almost certainly the first thing that's
going to go wrong is that the PHP

47
00:04:19,290 --> 00:04:25,650
脚本会占用过多的CPU时间，这通常是第一个瓶颈
scripts are gonna take up too much CPU
time that's usually the first bottleneck

48
00:04:25,650 --> 00:04:29,850
如果他们从单个服务器开始，人们就会遇到，所以您需要的是一些
people encounter if they start with a
single server so what you need is some

49
00:04:29,850 --> 00:04:33,840
为您的PHP脚本获得更多功能的方法，这使我们能够
way to get more horsepower for your PHP
scripts and so that takes us to kind of

50
00:04:33,840 --> 00:04:40,470
您知道其中有很多网站的网站的第二架构
architecture number two for websites in
which you know you have lots and lots of

51
00:04:40,470 --> 00:04:47,400
比以前需要更多CPU功能的用户数量更多的用户
users right or more users than before
you need more CPU power for your PHP

52
00:04:47,400 --> 00:04:53,520
脚本，因此您可以运行一堆前端服务器，其唯一的工作就是运行Web 
scripts so you run a bunch of front end
servers whose only job is to run the web

53
00:04:53,520 --> 00:05:00,479
用户浏览器与之通信的服务器，这些服务器称为前端服务器，因此
servers that users browsers talk to and
these are called front end servers so

54
00:05:00,479 --> 00:05:03,860
这些都将运行补丁
these are going to run a patch either

55
00:05:04,650 --> 00:05:10,560
网络服务器和PHP脚本现在您知道用户将要与之交谈
webserver and the PHP scripts now you
know you users are going to talk to

56
00:05:10,560 --> 00:05:14,610
在不同时间使用不同的服务器，也许您的用户将彼此正交
different servers at different times
maybe your users Quadra each other they

57
00:05:14,610 --> 00:05:17,460
互相发消息，他们需要对方的信息或其他内容
message each other they need to see each
other's posts or something

58
00:05:17,460 --> 00:05:22,699
因此所有这些前端服务器都需要查看相同的后端数据
so all these front-end servers are going
to need to see the same back-end data

59
00:05:23,210 --> 00:05:28,889
为了做到这一点，您可能至少只能坚持一会儿
and in order to do that you probably
can't just stick at least for a while

60
00:05:28,889 --> 00:05:31,500
您可以只使用一个数据库服务器，这样您就可以拥有一个
you can just stick with one database
server so you gonna have a single

61
00:05:31,500 --> 00:05:37,770
机器已经是我处理所有数据库所有查询的续集，并且
machine already my sequel that handles
all of the database all queries and

62
00:05:37,770 --> 00:05:43,199
更新从前端服务器读取和写入，如果可以的话， 
updates reads and writes from the front
end servers and if you possibly can it's

63
00:05:43,199 --> 00:05:46,560
明智的做法是在这里使用一台服务器，因为一旦您使用两台服务器， 
wise to use a single server here because
as soon as you go with two servers and

64
00:05:46,560 --> 00:05:51,620
以某种方式，您在多个数据库服务器上的数据变得更加复杂
somehow your data over multiple database
servers like gets much more complicated

65
00:05:51,620 --> 00:05:56,550
您需要担心是否需要分布式交易或
and you need to worry about things like
do you need distributed transactions or

66
00:05:56,550 --> 00:06:01,590
它如何使用PHP脚本决定与哪个数据库服务器进行通讯，等等
how it has the PHP scripts decide which
database server to talk to and so again

67
00:06:01,590 --> 00:06:05,699
使用第二种架构，您可以获得很长的路要走
you can get a long way with this second
architecture you have as much CPU power

68
00:06:05,699 --> 00:06:11,880
您可以根据需要添加更多前端服务器，最多可以添加一个
as you like by adding more front end
servers and up to a point a single

69
00:06:11,880 --> 00:06:16,020
数据库服务器实际上将能够吸收许多前端的原因权限
database server will actually be able to
absorb the reason rights of many front

70
00:06:16,020 --> 00:06:22,610
结束，但您知道您可能会非常成功，您会获得更多用户，并且
ends but you know maybe you're very
successful you get even more users and

71
00:06:22,610 --> 00:06:27,599
所以问题是接下来会出什么问题，通常接下来会出什么问题
so the question is what's gonna go wrong
next and typically what goes wrong next

72
00:06:27,599 --> 00:06:33,169
是数据库服务器，因为您总是可以添加更多CPU和更多Web服务器
is that the database server since you
can always add more CPU more web servers

73
00:06:33,169 --> 00:06:37,620
您知道不可避免的错误是数据库服务器过了一段时间
you know what inevitably goes wrong is
that after a while the database server

74
00:06:37,620 --> 00:06:49,380
用完了好吧，这是网络的下一个架构是什么
runs out of steam okay so what's the
next architecture this is web

75
00:06:49,380 --> 00:06:55,080
建筑3和大型网站的标准演变方式
architecture 3 and the kind of standard
evolution of big websites here we have

76
00:06:55,080 --> 00:07:01,500
如果您现在知道成千上万的用户，而且很多
the same if you know now thousands and
thousands of users lots and lots of

77
00:07:01,500 --> 00:07:07,909
前端，现在我们基本上我们知道我们将不得不拥有多个
front ends and now we basically we know
we're gonna have to have multiple

78
00:07:07,909 --> 00:07:14,159
数据库服务器，所以现在在前端后面，我们拥有一整套数据库
database servers so now behind the front
ends we have a whole rack of database

79
00:07:14,159 --> 00:07:18,280
服务器每个人再次运行我的续集
servers each one of them running my
sequel again

80
00:07:18,280 --> 00:07:22,960
但是我们将分片现在驱动的数据以分片数据
but we're going to shard the data
we're driven now to sharding the data

81
00:07:22,960 --> 00:07:27,130
通过数据库服务器，所以您可能知道第一个拥有您知道的密钥
over the database server so you know
maybe the first one holds keys you know

82
00:07:27,130 --> 00:07:34,660
 a到G＆G到第二个，按住G到Q，你知道
a through G & G through second one holds
keys G through Q and you know whatever

83
00:07:34,660 --> 00:07:38,680
图表恰好是现在，您知道要教的前端
the charting happens to be and now the
front-end you know you have to teach

84
00:07:38,680 --> 00:07:42,250
您的PHP脚本在这里查看它们所需的数据并尝试找出
your PHP scripts here to look at the
data they need and try to figure out

85
00:07:42,250 --> 00:07:45,100
他们将在不同时间与之交谈的数据库服务器
which database server they're going to
talk to it you know in different times

86
00:07:45,100 --> 00:07:50,250
对于不同的数据，他们将与不同的服务器通信，因此这是分片的
for different data they're going to talk
to different servers so this is sharding

87
00:07:51,030 --> 00:07:57,460
当然，之所以能为您带来帮助，是因为现在所有的工作
and of course the reason why this gives
you a boost is that now the all the work

88
00:07:57,460 --> 00:08:01,360
阅读和写作的分裂，希望可以平均地分裂
of reading and writing has split up
hopefully hopefully evenly split up

89
00:08:01,360 --> 00:08:05,830
在这些服务器之间，因为它们保存不同的数据，所以现在可以复制评级字
between these servers since they hold
different data now replicas rating word

90
00:08:05,830 --> 00:08:09,960
绘制数据图表，它们可以并行执行并具有很大的并行度
charting the data and they can execute
in parallel and have big parallel

91
00:08:09,960 --> 00:08:17,110
读取和写入数据的能力，PHP代码必须要痛苦一些
capacity to read and write data it's a
little bit painful the PHP code has to

92
00:08:17,110 --> 00:08:21,460
如果更改了以下数据库服务器的设置，则了解分片
know about the sharding if you change
the setup of the database servers that

93
00:08:21,460 --> 00:08:25,330
您添加了新的数据库服务器，或者您意识到需要拆分密钥
you add a new database server or you
realize you need to split up the keys

94
00:08:25,330 --> 00:08:29,320
不同的是，您知道现在需要一个软件，您将不得不修改该软件
differently you know now you need a
you're gonna have to modify the software

95
00:08:29,320 --> 00:08:33,370
运行在前端或其他东西上，以便他们了解
running on the front ends or something
in order for them to understand about

96
00:08:33,370 --> 00:08:37,750
如何切换到新的分片所以这里有些痛
how to cut over to the new sharding so
there's some there's some pain here

97
00:08:37,750 --> 00:08:42,760
还有是否需要交易，如果您知道很多人会使用它们
there's also if you need transactions
and you know many people use them if you

98
00:08:42,760 --> 00:08:47,140
需要交易，但单笔交易中涉及的数据超过
need transactions but the data involved
in a single transaction is on more than

99
00:08:47,140 --> 00:08:51,730
一台数据库服务器，您可能需要两阶段提交或一些
one database server you're probably
going to need two-phase commit or some

100
00:08:51,730 --> 00:08:59,040
其他分布式交易方案也很痛苦，也很慢
other distributed transaction scheme
it's also a pain and slow all right well

101
00:08:59,040 --> 00:09:07,089
您可以通过这种安排走得很远，但是这很昂贵
you can you can get fairly far with this
arrangement however it's quite expensive

102
00:09:07,089 --> 00:09:12,520
我的续集或你们中的一些人知道功能全面的数据库服务器，例如人
my sequel or sort of you know fully
featured database servers like people

103
00:09:12,520 --> 00:09:18,130
喜欢使用它不是特别快，它可能可以
like to use it's not particularly fast
it can probably

104
00:09:18,130 --> 00:09:24,340
每秒执行数十万次读取，权限大大减少，您
perform a couple hundred thousand reads
per second and far fewer rights and you

105
00:09:24,340 --> 00:09:32,200
知道网站的阅读往往很繁琐，所以很可能您会耗尽
know web sites tend to be read heavy so
it's likely that you're gonna run out of

106
00:09:32,200 --> 00:09:38,410
写入之前先进行读取，流量将是我们在网络上加载的流量
steam for reads before writes that
traffic will be that we load on the web

107
00:09:38,410 --> 00:09:43,660
服务器将由读取为主，因此一段时间后，您就可以切片
servers will be dominated by reads and
so after a while you know you can slice

108
00:09:43,660 --> 00:09:49,210
越来越多的服务器上的数据越来越稀薄，但是有两件事出错了
the data more and more thinly over more
and more servers but two things go wrong

109
00:09:49,210 --> 00:09:54,430
与那个是一些有时你是你有特定的关键是
with that one is that the some sometimes
you're you have specific keys that are

110
00:09:54,430 --> 00:09:59,080
经常使用的热食，没有多少切片的确有帮助，因为每个
hot that are used a lot and no amount of
slicing really helps there because each

111
00:09:59,080 --> 00:10:03,550
密钥仅在单个服务器上，因此非常流行，服务器可以
key is only on a single server so that
keeps very popular that servers can be

112
00:10:03,550 --> 00:10:09,160
无论您对数据进行了多少分区或分片， 
overloaded no matter how much you
partition or shard the data and the

113
00:10:09,160 --> 00:10:13,060
添加的另一个问题是缩短添加很多续集
other problem with adding was shorting
adding lots and lots of my sequel

114
00:10:13,060 --> 00:10:20,080
用于分片的数据库服务器的确是一种昂贵的方式
database servers for sharding is that
it's really an expensive way to go as it

115
00:10:20,080 --> 00:10:23,440
事实证明，经过一点之后，您将开始思考得很好
turns out and after a point you're gonna
you're going to start to think that well

116
00:10:23,440 --> 00:10:27,760
而不是花很多钱来添加另一个运行我的数据库服务器
instead of spending a lot of money to
add another database server running my

117
00:10:27,760 --> 00:10:32,920
续集我可以让同一台服务器在它上面运行得更快
sequel I could take the same server run
something much faster on it like as it

118
00:10:32,920 --> 00:10:37,420
发生Memcache D，并且每秒获得更多读取
happens memcache D and get a lot more
reads per second out of the same

119
00:10:37,420 --> 00:10:45,640
使用缓存而不是使用数据库的硬件，因此下一个架构和
Hardware using caching than using
databases so the next architecture and

120
00:10:45,640 --> 00:10:51,940
现在开始与Facebook正在使用的下一个架构相似
this is now starting to resemble what
Facebook is using the next architecture

121
00:10:51,940 --> 00:10:59,950
仍然需要用户，我们仍然有一堆运行Web服务器的前端服务器
still need users we still have a bunch
of front end servers running web servers

122
00:10:59,950 --> 00:11:05,110
在PHP中，到目前为止，也许还有大量的前端服务器， 
in PHP and by now maybe a vast number of
front end servers we still have our

123
00:11:05,110 --> 00:11:11,020
数据库服务器，因为您知道我们需要一个可以存储数据的系统
database servers because you know we
need us a system that will store data

124
00:11:11,020 --> 00:11:17,860
为我们安全地存储在磁盘上，我们将为我们提供诸如交易之类的信息
safely on disk for us and we'll provide
things like transactions for us and so

125
00:11:17,860 --> 00:11:21,940
你知道可能想要一个数据库，但是在这两者之间
you know probably want a database for
that but in between we're gonna have a

126
00:11:21,940 --> 00:11:26,160
缓存层就是memcache D进入的地方
caching layer that's this is where
memcache D comes in

127
00:11:26,160 --> 00:11:29,940
当然还有其他可以使用的内容，但memcache 
and of course there's other things you
could use that the memcache but memcache

128
00:11:29,940 --> 00:11:34,230
 D碰巧是一种非常流行的缓存方案，现在的想法是
D happens to be an extremely popular
caching scheme the idea now is you have

129
00:11:34,230 --> 00:11:41,759
一大堆这些Memcache服务器，以及前端需要读取一些内容时
a whole bunch of these memcache servers
and when a front-end needs to read some

130
00:11:41,759 --> 00:11:47,850
数据首先要做的是询问其中一个Memcache服务器，看您是否拥有
data the first thing it does is ask one
of the memcache servers look do you have

131
00:11:47,850 --> 00:11:50,819
我需要的数据，它将与一些数据一起发送获取请求
the data I need
so it'll send a get request with some

132
00:11:50,819 --> 00:11:56,279
到其中一个Memcache服务器的密钥，Memcache服务器将检查它是否已获得
key to one of the memcache servers and
the memcache server will check it's got

133
00:11:56,279 --> 00:12:00,689
只是内存中的一个表，实际上memcache非常简单，远
just a table in memory it's in fact
memcache is extremely simple it's far

134
00:12:00,689 --> 00:12:07,529
例如，它远比您的实验室3简单得多，但在
far simpler than your lab 3 for example
it just has just as a big hash table on

135
00:12:07,529 --> 00:12:11,040
它使用哈希表中的键检查它是否返回的内存
memory it checks with that keys in the
hash table if it is it sends back the

136
00:12:11,040 --> 00:12:15,180
数据说，是的，这是我兑现的价值，如果我们
data saying oh yeah here's the value
I've cashed for that and if we if the

137
00:12:15,180 --> 00:12:19,319
在此Memcache服务器中的前端命中率很高，然后我可以生成该网页
front end hits in this memcache server
great I can then produce the webpage

138
00:12:19,319 --> 00:12:23,839
如果前端服务器必须在网络服务器中丢失数据，则在其中添加数据
with that data in it if it misses in the
webserver though the front-end has to

139
00:12:23,839 --> 00:12:30,689
然后后方无关的马术数据库服务器，数据库服务器会说
then rear equesticle irrelevant database
server and the database server will say

140
00:12:30,689 --> 00:12:36,779
哦，您知道这是您需要的数据，这时为了
oh you know here's the here's the data
you need and at that point in order to

141
00:12:36,779 --> 00:12:42,540
兑现用于需要它的下一个前端，我们将发送看跌期权
cash it in for the next front-end that
needs it the front end we'll send a put

142
00:12:42,540 --> 00:12:48,300
将数据与数据库一起存储到该Memcache服务器中，因为
with the data it fashion the database
into that memcache server and because

143
00:12:48,300 --> 00:12:52,740
 memcache的运行速度至少提高了10倍，也许快了10倍以上
memcache runs at least 10 and maybe
maybe more than 10 times faster for

144
00:12:52,740 --> 00:12:58,079
对于给定的硬件数量，它确实比数据库具有优势
weeds than the database for a given
amount of hardware it really pays off to

145
00:12:58,079 --> 00:13:02,189
对内存缓存和数据库使用相当数量的某些硬件
use a fair amount some of that hardware
for memcache as well as for the database

146
00:13:02,189 --> 00:13:06,420
服务器，所以人们经常使用这种安排，这只会节省它们
servers so people people use this
arrangement a lot and it just saves them

147
00:13:06,420 --> 00:13:12,029
钱是因为内存缓存对于杂草来说要比数据库服务器快得多
money because memcache is so much faster
for weeds than a database server still

148
00:13:12,029 --> 00:13:15,990
需要向数据库发送写操作，因为您希望有权更新
need to send writes to the database
because you want right to an updates to

149
00:13:15,990 --> 00:13:22,379
持久存储在数据库中，因为如果存在
be stored durably on the database as
this can still be there if there's a

150
00:13:22,379 --> 00:13:28,019
崩溃或其他问题，但是您可以将Reese发送到缓存中的次数更多
crash or something but you can send the
Reese to the cache very much more

151
00:13:28,019 --> 00:13:32,639
很快好了，所以我们有一个问题，问题是为什么内存缓存不会
quickly ok so we have a question the
question is why wouldn't the memcache

152
00:13:32,639 --> 00:13:36,329
服务器实际上代表前端命中了put并缓存了响应
server actually hit the put on behalf of
the front-end and cache the response

153
00:13:36,329 --> 00:13:39,209
在响应前端之前，这是一个很好的问题
before responding the front-end so
that's a great question

154
00:13:39,209 --> 00:13:43,439
您可以想象一个缓存层，您将向其发送获取信息，它将
you could imagine a caching layer that
you would send a get to it and it would

155
00:13:43,439 --> 00:13:48,569
如果它错过了memcache层，则会将请求转发给
if it missed the memcache layer would
would forward the request to the

156
00:13:48,569 --> 00:13:52,699
数据库婴儿响应memcache memcache会将数据添加到其
database babies respond the memcache
memcache would add the data to its

157
00:13:52,699 --> 00:13:59,339
表，然后响应，其原因是内存缓存就像一个
tables and then respond and the reason
for this is that memcache is like a

158
00:13:59,339 --> 00:14:02,880
完全不知道的完全独立的软件
completely separate piece of software
that it doesn't know anything about

159
00:14:02,880 --> 00:14:06,509
数据库，实际上甚至不必使用和组合
databases and it's actually not even
necessarily used and combined in

160
00:14:06,509 --> 00:14:12,240
与数据库结合，尽管通常如此，所以我们无法烘烤
conjunction with the database although
it often is so we can't bake in

161
00:14:12,240 --> 00:14:18,480
将数据库存储到内存缓存中的知识以及更深层次的原因是
knowledge of the database into memcache
and sort of deeper reason is that the

162
00:14:18,480 --> 00:14:25,160
前端通常不是真正地在内存缓存中一对一存储数据库记录
front ends are often not really storing
one for one database records in memcache

163
00:14:25,160 --> 00:14:30,899
几乎总是或非常频繁发生的事情是前端
almost always or very frequently what's
going on is that the front-end will

164
00:14:30,899 --> 00:14:35,189
向数据库发出一些请求，然后以某种方式处理结果
issue some requests to the database and
then process the results somewhat you

165
00:14:35,189 --> 00:14:42,949
知道也许要采取一些步骤将其转换为HTML或将其收集在一起
know maybe take a few steps to turning
it into HTML or sort of collect together

166
00:14:42,949 --> 00:14:47,910
您知道数据库中多行上的多个职业的结果， 
you know results from multiple careers
on multiple rows in the database and

167
00:14:47,910 --> 00:14:51,120
将部分处理的信息缓存在内存缓存中
cached partially processed information
in memcache

168
00:14:51,120 --> 00:14:56,279
只是为了避免下一个阅读器不必进行相同的处理，为此
just to save the next reader from having
to do the same processing and for that

169
00:14:56,279 --> 00:15:01,410
原因Memcache并不真正不了解之间的关系
reason memcache it doesn't really does
not understand the relationship between

170
00:15:01,410 --> 00:15:06,089
朋友希望看到的内容是缓存的，以及您如何使用这些数据
what the friends would like to see see
cached and how did you ride that data

171
00:15:06,089 --> 00:15:09,480
从数据库中得知，知识实际上仅在前端的PHP代码中
from the database that knowledge is
really only in the PHP code on the front

172
00:15:09,480 --> 00:15:14,850
因此，即使我们可以构筑一个好主意，我们也无法拥有
end so therefore even though we could be
architectural a good idea we can't have

173
00:15:14,850 --> 00:15:20,279
这种整合是memcache和
this integration here sort of direct
contact between memcache and the

174
00:15:20,279 --> 00:15:25,380
数据库，尽管它可能使缓存一致性的故事变得更多
database although it might make the
cache consistency story much more

175
00:15:25,380 --> 00:15:31,440
直截了当，是的，就是这样，然后回答下一个
straightforward and yes
this is it's this and answer the next

176
00:15:31,440 --> 00:15:37,100
问题是备用现金和现金透视之间的区别
question that is the difference between
a lookaside cash and a look through cash

177
00:15:37,100 --> 00:15:42,150
后备业务的事实是，前端看起来
the fact the lookaside business is that
the front end sort of looks asides to

178
00:15:42,150 --> 00:15:45,930
现金以查看数据是否存在，是否存在数据
the cash to see if the data is there and
if it's not it makes its own

179
00:15:45,930 --> 00:15:51,000
安排让您事半功倍的经历，您可以通过现金了解一下
arrangements for getting the deed on
amiss you know a look through cash my

180
00:15:51,000 --> 00:15:57,270
转发数据库的请求并直接处理并立即处理响应
forward request of the database and
directly and handle the response now

181
00:15:57,270 --> 00:16:01,770
 Memcache受欢迎的部分原因是它是后备
part of the reason for the popularity in
memcache is that it is it is a lookaside

182
00:16:01,770 --> 00:16:07,170
现金对于是否存在数据库或存有什么是完全中立的
cash that is completely neutral about
whether there's a database or what's in

183
00:16:07,170 --> 00:16:11,520
数据库或内存缓存中的内容与最终内容之间的关系
the database or the relationship between
stuff in memcache and what's in the end

184
00:16:11,520 --> 00:16:18,840
数据库中的项目都可以，所以这是非常流行的安排
items in the database all right so this
is very popular arrangement very widely

185
00:16:18,840 --> 00:16:23,310
使用它具有成本效益，因为memcache在
used it's cost effective because
memcache is so much faster in the

186
00:16:23,310 --> 00:16:29,370
数据库，每个网站都会使您变得很认真，因此有点复杂
database it's a bit complex every
website that makes serious you so this

187
00:16:29,370 --> 00:16:35,190
面临的问题是，如果您不执行任何操作，则存储在
faces the problem that if you don't do
something the data that's stored in the

188
00:16:35,190 --> 00:16:40,050
缓存将与数据库中的数据不同步，因此每个人
caches will get out of sync with the
data in the database and so everybody

189
00:16:40,050 --> 00:16:43,800
必须有一个故事，说明如何确保在您修改
has to have a story for how to make sure
that when you modify something in the

190
00:16:43,800 --> 00:16:50,640
数据库，您可以对内存缓存执行某些操作，请注意以下事实： 
database you do something to memcache to
you know take care of the fact that

191
00:16:50,640 --> 00:16:54,750
然后，内存缓存可能会存储不反映更新的过时数据，并且
memcache may then be storing stale data
that doesn't reflect the updates and a

192
00:16:54,750 --> 00:16:58,620
尽管有其他人，但本文中有很多关于Facebook的故事是什么
lot of this papers about what Facebook
story is for that although other people

193
00:16:58,620 --> 00:17:08,040
有其他计划，这种安排也可能会有点脆弱，它允许您
had other plans this arrangements also
potentially a bit fragile it allows you

194
00:17:08,040 --> 00:17:13,440
扩展到更多的用户，那么您本可以只使用数据库
to scale up to far more users then you
could have gone with databases alone

195
00:17:13,440 --> 00:17:17,700
因为内存缓存是如此之快，但这意味着您将要结束
because memcache is so fast but what
that means is that you're gonna end up

196
00:17:17,700 --> 00:17:24,060
系统承受的负载要高得多，您知道
with the system that's sustaining a load
that's far far higher you know orders of

197
00:17:24,060 --> 00:17:29,340
数量级高于数据库可以处理的数量，因此，如果发生任何事情
magnitude higher than what the databases
could handle and thus if anything goes

198
00:17:29,340 --> 00:17:34,250
例如，如果您的一台内存缓存服务器发生故障，并且
wrong for example if one of your
memcache servers were to fail and

199
00:17:34,250 --> 00:17:37,710
意味着前端现在必须联系数据库，因为
meaning that the front ends would now
have to contact the database because

200
00:17:37,710 --> 00:17:41,220
他们没有击中，他们不能使用它来存储数据
they didn't hit they couldn't use this
to store data

201
00:17:41,220 --> 00:17:45,450
您将大大增加数据库的负载，因为
you're gonna be increasing a load in the
databases dramatically right because

202
00:17:45,450 --> 00:17:50,309
您知道内存缓存的命中率为99％还是
memcache do you know supposing it has a
you know hit rate of 99 percent or

203
00:17:50,309 --> 00:17:55,049
无论碰巧是什么，您都知道Memcache将几乎吸收
whatever it happens to be you know
memcache is gonna be absorbing almost

204
00:17:55,049 --> 00:18:00,450
所有读取数据库后端的操作只会看到百分之几的
all the reads the database backends only
going to be seeing a few percent of the

205
00:18:00,450 --> 00:18:06,179
读取总数，因此这里的任何失败都会增加读取的百分之几
total reads so any failure here is gonna
increase that few percent of the reads

206
00:18:06,179 --> 00:18:09,840
也许您知道我不知道50％的读数或其他
to maybe you know I don't know 50
percent of the reads or whatever which

207
00:18:09,840 --> 00:18:16,320
是一个巨大的数量级增加，就像Facebook一旦完成
is a huge huge order of magnitude
increase so as Facebook does once you've

208
00:18:16,320 --> 00:18:24,299
必须依靠此缓存层，因此您需要认真设置
got to rely on this caching layer you
need to be set up pretty serious

209
00:18:24,299 --> 00:18:30,440
措施，以确保您永远不会暴露数据库层的全部内容
measures to make sure that you never
expose the database layer to the full

210
00:18:30,440 --> 00:18:37,289
像缓存层看到的满负荷之类的东西，您知道
anything like the full load that the
caching layer is seeing and you know you

211
00:18:37,289 --> 00:18:43,350
在Facebook上看到他们有很多想法来确保
see in facebook they have quite a bit of
thought put into making sure the

212
00:18:43,350 --> 00:18:48,860
数据库再也看不到满负荷了
databases don't ever see anything like
the full load okay

213
00:18:48,860 --> 00:18:58,230
到目前为止，这是通用的，我现在想切换到什么
so far this is generic now I want to
sort of switch to a big picture of what

214
00:18:58,230 --> 00:19:04,020
 Facebook在论文中描述了它们的整体架构
Facebook describes in the paper for
their overall architecture of course

215
00:19:04,020 --> 00:19:08,640
他们有很多用户，每个用户都是无友，状态和帖子以及
they have lots of users every user as a
friendless and status and posts and

216
00:19:08,640 --> 00:19:16,650
喜欢和喜欢的照片，但Facebook非常容易或试图将数据显示给
likes and photos but Facebook's very
easy or e nted towards showing data to

217
00:19:16,650 --> 00:19:24,740
用户，其中最重要的一点是，新数据不是
users and a super important aspect of
that is that fresh data is not

218
00:19:24,740 --> 00:19:31,260
在这种情况下，您绝对认为应该读
absolutely necessary in that
circumstance you know suppose the reads

219
00:19:31,260 --> 00:19:36,120
您是否知道由于缓存而需要读取几秒钟的产量数据
are you know due to caching supposed to
reads yield data that's a few seconds

220
00:19:36,120 --> 00:19:40,110
过时的数据，因此您要向用户显示的不是最新数据，而是
out of date so you're showing your users
data not the very latest data but the

221
00:19:40,110 --> 00:19:45,000
几秒钟前的数据，您知道用户极不可能
data from a few seconds ago you know
what the users are extremely unlikely to

222
00:19:45,000 --> 00:19:50,159
注意，除非在特殊情况下，否则如果我正在查看今天的新闻提要
notice except in special cases right if
I'm looking at a news feed of today's

223
00:19:50,159 --> 00:19:54,419
你知道今天的新闻你知道我是否从几个新闻中看到
you know today's news you know if I see
the news from a few

224
00:19:54,419 --> 00:20:00,210
以前与现在的新闻相比，没有人会注意到没有人
times ago versus the news from now a big
deal nobody's gonna notice nobody's

225
00:20:00,210 --> 00:20:03,809
会抱怨你知道，并非所有数据都适用，但很多情况下
gonna complain you know that's not
always true for all data but for a lot a

226
00:20:03,809 --> 00:20:07,590
他们必须处理的许多数据都是最新的
lot of the data that they have to deal
with sort of super up-to-date

227
00:20:07,590 --> 00:20:11,549
像线性化能力意义上的一致性实际上不是
consistency in the sense of like
linearise ability is not actually

228
00:20:11,549 --> 00:20:17,850
重要的是重要的是您不会无限期地缓存过时的数据
important what is important is that you
don't cache stale data indefinitely you

229
00:20:17,850 --> 00:20:22,200
知道他们做不到的是错误地拥有了一些正在显示的数据
know what they can't do is by mistake
have some data that they're showing

230
00:20:22,200 --> 00:20:28,590
昨天，上周甚至一个小时前的用户
users that's from yesterday or last week
or even an hour ago those users really

231
00:20:28,590 --> 00:20:34,889
会开始注意到，所以他们不在乎一致性，例如
will start to notice that so they don't
care about consistency like

232
00:20:34,889 --> 00:20:41,789
一秒一秒，但他们很在乎不在不在不能咀嚼
second-by-second but they care a lot
about not not being in cannot chewing

233
00:20:41,789 --> 00:20:47,669
过时的数据来自不止一阵子
stale data from more than well more than
a little while ago the other situation

234
00:20:47,669 --> 00:20:51,149
他们需要提供一致性的是用户是否更新了他们的
in which they need to provide
consistency is if a user updates their

235
00:20:51,149 --> 00:20:56,970
拥有数据，或者用户更新几乎所有数据，然后读取与
own data or if a user updates almost any
data and then reads that same data that

236
00:20:56,970 --> 00:21:02,489
人类知道他们只是更新了，这给用户带来极大的困惑
the human knows that they just updated
it's extremely confusing for the user to

237
00:21:02,489 --> 00:21:07,619
查看过时的数据（如果他们知道他们刚刚进行了更改），因此在特定情况下
see stale data if they know they just
changed it and so in that specific case

238
00:21:07,619 --> 00:21:14,549
 Facebook的设计还应谨慎确保用户是否更改了数据
the Facebook design is also careful to
make sure that if a user changes data

239
00:21:14,549 --> 00:21:18,529
该用户将看到更改数据
that that user will see the change data

240
00:21:19,220 --> 00:21:27,899
好的，所以Facebook有多个数据中心，他们称其为区域，我认为
ok so Facebook has multiple data centers
which they call regions and I think at

241
00:21:27,899 --> 00:21:33,859
在撰写本文时，他们有两个区域是主要区域
the time this paper was written they had
two regions their sort of primary region

242
00:21:33,859 --> 00:21:40,109
在加利福尼亚的西海岸，他们的次要地区在
was on the west coast California and
their sort of secondary region was in

243
00:21:40,109 --> 00:21:51,480
东海岸和两个数据中心看起来非常相似
the East Coast and the two data centers
look pretty similar you

244
00:21:51,480 --> 00:21:56,520
运行我的续集的数据库服务器集
set of database servers running my
sequel the sharted date over these my

245
00:21:56,520 --> 00:21:59,570
续集数据库服务器
sequel database servers

246
00:21:59,820 --> 00:22:05,710
他们有一堆memcache D服务器，我们将看到它们实际上是
they had a bunch of memcache D servers
which we'll see they are actually

247
00:22:05,710 --> 00:22:09,630
排列成独立的集群，然后它们有一堆前端
arranged in independent clusters and
then they had a bunch of front ends

248
00:22:09,630 --> 00:22:20,230
在每个数据中心中又有一个单独的安排，有几个
again sort of a separate arrangement in
each data center and there's a couple

249
00:22:20,230 --> 00:22:24,370
造成这种情况的原因是，他们的客户分散在各地
reasons for this one is that their
customers were scattered all over the

250
00:22:24,370 --> 00:22:28,300
国家，这对于东方人的表演是一件好事
country and it's nice just for a
performance that people on the East

251
00:22:28,300 --> 00:22:31,750
海岸可以与附近的数据中心对话，西海岸的人也可以
Coast can talk to a nearby data center
and people on the west coast can also

252
00:22:31,750 --> 00:22:42,310
与附近的赤字交谈只会使互联网延迟现在减少
talk to a nearby deficit it just makes
internet delays less now the the data

253
00:22:42,310 --> 00:22:46,000
中心不对称，每个中心都拥有所有数据的完整副本
centers were not symmetric each of them
held a complete copy of all the data

254
00:22:46,000 --> 00:22:50,590
他们没有将数据分片到整个数据中心，所以西方
they didn't sort of shard the data
across the data centers so the West

255
00:22:50,590 --> 00:22:55,930
我认为Coast是主要的，它具有数据的真实副本和
Coast I think was a primary and it sort
of had the real copy of the data and the

256
00:22:55,930 --> 00:23:01,930
东海岸是次要的，真正的意思是所有权利都必须
East Coast was a secondary and what that
really means is that all rights had to

257
00:23:01,930 --> 00:23:08,200
被发送到相关数据库，而第一天将成为中心，因此您知道
be sent to the relevant database and the
primary day to be Center so you know any

258
00:23:08,200 --> 00:23:15,340
正确发送给您，您在这里知道，他们使用他们服务的我的续集的功能
right gets sent you know here and they
use a feature of my sequel they serve

259
00:23:15,340 --> 00:23:21,360
异步日志复制方案，以使每个数据库都位于主区域中
asynchronous log replication scheme to
have each database in the primary region

260
00:23:21,360 --> 00:23:26,380
将每个更新发送到辅助区域中的相应数据库，以便
send every update to the corresponding
database in secondary region so that

261
00:23:26,380 --> 00:23:31,720
这些数据库服务器可能会有几秒钟的延迟
with a lag of maybe even a few seconds
these database servers would have

262
00:23:31,720 --> 00:23:35,710
相同的内容，辅助数据库服务器将具有与以下内容相同的内容
identical content the secondary database
servers would have identical content to

263
00:23:35,710 --> 00:23:39,430
小学读尽管我们是本地的，所以这些前端在他们需要
the primaries reads though we're local
so these front ends when they need to

264
00:23:39,430 --> 00:23:44,590
找到一些我通常会与该数据中心内的memcache memcache对话的数据
find some data I'm in general would talk
to memcache memcache in that data center

265
00:23:44,590 --> 00:23:48,640
如果他们错过了内存缓存，那么他们会与他们从
and if they missed in memcache they
talked to the they'd read from the

266
00:23:48,640 --> 00:23:56,880
在同一数据数据中心再次建立数据库
database in that same data data center
um again though the databases are

267
00:23:56,880 --> 00:24:03,540
在这两个区域中的这两个区域上完整复制所有数据
complete replicas all the data's on both
of these these in both of these regions

268
00:24:04,180 --> 00:24:11,990
这是整体情况，我接下来要谈的是几件事
that's the overall picture the next
thing I want to talk about is a few

269
00:24:11,990 --> 00:24:21,020
有关如何使用它们的详细信息，您知道这种白细胞缓存
details about how they how they use you
know with this leukocyte caching

270
00:24:21,020 --> 00:24:28,550
实际上看起来像这样，确实有读写功能，这是
actually looks like so there's really
there's reads and writes and this is

271
00:24:28,550 --> 00:24:33,640
读图二所示
just what's shown in Figure two for a
read

272
00:24:33,640 --> 00:24:39,340
如果您读取任何数据，那么在前端执行的第一件事
which is executing on a front-end the
first thing if you read any data that

273
00:24:39,340 --> 00:24:43,420
可能会缓存前端代码的第一件事是
might be cached the first thing that
code in the front-end does is makes this

274
00:24:43,420 --> 00:24:48,370
使用所需数据的键进行库调用，并生成一个
get library call with the key of the
data they want and get just generates an

275
00:24:48,370 --> 00:24:56,050
 RPC到相关的Memcache服务器，因此他们在该库例程哈希值上哈希
RPC to the relevant memcache server so
they hash this library routine hashes on

276
00:24:56,050 --> 00:25:01,420
客户端通过哈希键选择内存缓存服务器，然后向该服务器发送RPC 
the client hashes the key to pick the
memcache server and sends an RPC to that

277
00:25:01,420 --> 00:25:06,670
 mcat服务器，他们随随便便回答是的，这是您的数据，或者也许它将指向
mcat server them casually reply yes
here's your data or or maybe it'll point

278
00:25:06,670 --> 00:25:18,910
 nil表示我没有该数据，因此不进行缓存，因此如果V为nil，则
nil saying I don't have that data it's
not cached so if if V is nil then the

279
00:25:18,910 --> 00:25:27,510
前端将发出从中获取数据所需的任何续集查询
front-end will issue whatever sequel
query is required to fetch the data from

280
00:25:27,510 --> 00:25:34,920
数据库，然后进行另一个RPC调用
the database and then make another RPC
call

281
00:25:36,980 --> 00:25:41,760
 -memk2相关的memcache服务器以将获取数据安装在memcache中
- memk2 the relevant memcache server to
install the fetch data in the memcache

282
00:25:41,760 --> 00:25:45,680
服务器，所以这只是我之前讨论过的例程
server so this is just the routine I
talked through before

283
00:25:45,680 --> 00:25:51,710
这就是后备缓存的作用，正确的
it's kind of what lookaside caching does
and for right

284
00:25:55,540 --> 00:26:01,930
你知道V是写作，我们有一个键和一个值，没有林蛙权利，所以图书馆
you know V is the writing we have a key
and a value no Rana right and so library

285
00:26:01,930 --> 00:26:11,110
每个前端的例程，我们将把新数据发送到数据库
routine on an each front end we're gonna
send the the new data to the database

286
00:26:11,110 --> 00:26:16,240
而且您知道我在Keene之前提到的价值可能会有点
and you know I as I mentioned before the
Keene the value may be a little bit

287
00:26:16,240 --> 00:26:19,570
不同，您知道数据库中存储的内容通常在某种程度上
different you know what's stored in the
database is often in a somewhat

288
00:26:19,570 --> 00:26:23,680
与存储在内存缓存中的形式不同，请看一下，但我们现在可以想象
different form from what's stored in
memcache see but we'll imagine for now

289
00:26:23,680 --> 00:26:29,230
相同，一旦数据库具有新数据，则正确的库例程
the same and once the database has the
new data then the right library routine

290
00:26:29,230 --> 00:26:38,230
发送RPC到memcache，详细说明它看起来像您必须删除此键，所以我
sends an RPC to memcache detailing it
look you got to delete this key so I

291
00:26:38,230 --> 00:26:43,780
想要写作者使内存缓存中的密钥无效吗？ 
want to write the writer is invalidating
the key in memcache do you know what

292
00:26:43,780 --> 00:26:49,000
这意味着下一个尝试从中读取该密钥的前端
that means is that the next front-end
that tries to read that key from

293
00:26:49,000 --> 00:26:54,130
 memcache D将会归零，因为它不再被缓存并且将获取
memcache D is gonna get nil back because
it's no longer cached and will fetch the

294
00:26:54,130 --> 00:27:01,570
更新数据库中的值并将其安装到内存缓存中，这样
updated value from the database and
install it into memcache all right so

295
00:27:01,570 --> 00:27:06,490
特别是这是无效的，不是您无法想象一个方案
this is an invalidation in particular
it's not you could imagine a scheme that

296
00:27:06,490 --> 00:27:10,000
会在此时将新数据发送到memcache T，但实际上并没有
would send the new data to memcache T at
this point but it doesn't actually do

297
00:27:10,000 --> 00:27:17,830
这而不是gliese它，实际上在facebook计划的上下文中
that instead of gliese it and actually
in the context of facebook scheme the

298
00:27:17,830 --> 00:27:24,330
需要删除的真正原因是
real reason why this delete is needed is
so that

299
00:27:24,330 --> 00:27:29,940
我们将看到他们的权利，因为实际上在他们的计划中，记忆猫是我的
we'll see their own rights because in
fact in their scheme the mem cat the my

300
00:27:29,940 --> 00:27:35,460
续集服务器数据库服务器也发送删除您和前台之一
sequel server the database servers also
send deletes one of you and the front

301
00:27:35,460 --> 00:27:39,809
端使用混合尖叫机制在数据库中写一些东西
end writes something in the database the
database with the mix squeal mechanism

302
00:27:39,809 --> 00:27:44,730
该论文提到将相关删除内容发送到内存缓存服务器
the paper mentions well send the
relevant deletes to the memcache servers

303
00:27:44,730 --> 00:27:49,350
可能拥有此键的数据，因此数据库服务器将实际
that that might hold this key so the
data the database servers will actually

304
00:27:49,350 --> 00:27:54,539
逐步使内存缓存中的内容失效可能会花费一些时间，但是因为
invalidate stuff in memcache by-and-bye
may take them a while um but because

305
00:27:54,539 --> 00:27:58,980
可能要花一些时间才能删除前端的密钥
that might take a while the front ends
also delete the key said that a front

306
00:27:58,980 --> 00:28:14,659
端不会看到刚刚更新的数据的过时值
end won't see a stale value for data
that it just updated okay

307
00:28:16,590 --> 00:28:23,520
这几乎是每个人都使用memcache的背景
all sort of the background of this is
pretty much how everybody uses memcache

308
00:28:23,520 --> 00:28:28,980
 G现在这里还没有什么特别特别的东西，最终您知道了
G there's nothing yet really very
special here now eventually you know the

309
00:28:28,980 --> 00:28:34,020
纸上的所有内容都是关于解决一致性问题的， 
paper is all about on the surface all
about solving consistency problems and

310
00:28:34,020 --> 00:28:39,059
确实，这些很重要，但是它们之所以会遇到的原因
indeed those are important but the
reason why they got where they ran into

311
00:28:39,059 --> 00:28:46,380
这些一致性问题主要是因为您知道他们修改了
those consistency problems is in large
part because they you know modify the

312
00:28:46,380 --> 00:28:49,289
设计或建立具有极高性能的设计，因为它们
design or set up a design that had
extremely high performance because they

313
00:28:49,289 --> 00:28:54,029
有极高的负载，并说他们迫切希望获得性能， 
had extremely high load and say they
were desperate to get performance and

314
00:28:54,029 --> 00:28:59,840
为了改善性能而进行了一些努力
kind of struggled along behind the
performance improvements in order to

315
00:28:59,840 --> 00:29:04,110
保持合理的一致性水平，并且因为性能来了
retain a reasonable level of consistency
and because the performance kind of came

316
00:29:04,110 --> 00:29:07,590
首先对他们来说，我实际上要谈论
first for them I'm actually going to
talk about

317
00:29:07,590 --> 00:29:14,210
他们的绩效架构，然后再讨论如何解决
their performance architecture before
talking about how they fix the

318
00:29:14,210 --> 00:29:21,330
一致性好不好意思，这里有很多问题我还没有
consistency okay sorry there's been a
bunch of questions here that I haven't

319
00:29:21,330 --> 00:29:30,029
看到让我偷看好吧，一个问题，这意味着复制
seen let me take a peek okay so one
question this means that the replicated

320
00:29:30,029 --> 00:29:34,500
从主要我的续集数据库到次要数据库的更新也必须
updates from the primary my sequel
database to the secondary must also

321
00:29:34,500 --> 00:29:40,860
问题已删除-是的，所以我认为这是对以前版本的引用或
issue deletes - yeah so this is I think
a reference to the previous or

322
00:29:40,860 --> 00:29:47,100
架构幻灯片观察到的是，确实是当前端发送一个
architecture slide the observation is
that yes indeed when a front-end sends a

323
00:29:47,100 --> 00:29:53,039
今天写入数据库服务器，每个服务器都会更新其磁盘上的数据， 
write to the database server today every
server updates its data on disk and it

324
00:29:53,039 --> 00:29:58,260
会将无效删除信息发送到其中的任何Memcache服务器
will send an invalidate a delete to
whatever memcache server there is in the

325
00:29:58,260 --> 00:30:02,460
本地区域可能具有仅密钥的本地数据中心
local region the local data center that
might have had the key that was just

326
00:30:02,460 --> 00:30:07,950
更新后，数据库服务器还会将更新的一种表示形式发送到
updated the database server also sends a
sort of representation of the update to

327
00:30:07,950 --> 00:30:11,940
相应的数据库在其应用的其他区域中服务
the corresponding database serve in the
other region which process it applies

328
00:30:11,940 --> 00:30:18,779
磁盘上磁盘数据的权利还可以使用它们原谅
the right to its disk data on disk it
also using them excuse sort of log

329
00:30:18,779 --> 00:30:25,169
读取设备找出哪个内存缓存服务器可能持有该密钥
reading apparatus figures out which
memcache server might hold the key that

330
00:30:25,169 --> 00:30:32,340
刚刚更新，并将其删除也发送到该Memcache服务器，以便
was just updated and sends it delete
also to that memcache server so that the

331
00:30:32,340 --> 00:30:40,049
如果是关键，则在两个数据中心中的缓存均无效，所以另一个
if it's the key is cache is invalidated
in in both data centers okay so another

332
00:30:40,049 --> 00:30:45,210
问题，如果我们先在右侧删除然后发送到
question what would happen if we delete
first in the right and then send to the

333
00:30:45,210 --> 00:30:47,630
数据库
database

334
00:30:48,260 --> 00:30:53,190
因此，如果我们对
so that's or with reference to this
thing here would what if we did to the

335
00:30:53,190 --> 00:31:01,289
首先，如果您确实要删除，那么您会增加机会
feet first you know if you do delete
first then you're increasing the chances

336
00:31:01,289 --> 00:31:11,100
其他一些客户端（假设您删除了该客户端，然后将其发送到数据库） 
that some other clients so supposing you
delete and then send to database right

337
00:31:11,100 --> 00:31:14,880
在这里，如果另一个客户读到相同的密钥，他们会在这里错过
in here if another client reads that
same key they're gonna miss at this

338
00:31:14,880 --> 00:31:20,460
他们将要从数据库中获取旧数据，然后
point they're gonna fetch the old data
from the database and they're gonna then

339
00:31:20,460 --> 00:31:22,980
插入现金，然后您将对其进行更新
insert it
cash and then you're going to update it

340
00:31:22,980 --> 00:31:28,740
至少将过时的数据与Memcache保持一会儿，然后如果这
leaving memcache for a while at least
with stale data and then if this the

341
00:31:28,740 --> 00:31:31,440
编写客户端再次读取它，即使它只是
writing client reads it again it may see
the stale data even though it just

342
00:31:31,440 --> 00:31:37,290
更新它进行第二次删除，您知道这些可能性
updated it doing the delete second um
you know these over the possibility that

343
00:31:37,290 --> 00:31:43,350
有人会在这段时间内阅读并看到窃取数据，但他们没有
somebody will read during this period of
time and see steal data but they're not

344
00:31:43,350 --> 00:31:47,130
总的来说，他们担心过时的数据，他们真的最担心
worried about stale data in general
they're really most worried in this

345
00:31:47,130 --> 00:31:52,950
关于客户阅读自己的权利的上下文，因此即使存在
context about clients reading their own
rights so on balance even though there's

346
00:31:52,950 --> 00:32:00,240
我执行删除操作时出现的一致性问题可确保
a consistency problem by the way I'm
doing the delete second ensures that

347
00:32:00,240 --> 00:32:06,450
无论哪种情况，客户最终都将拥有自己的权利，最终数据库
clients will be their own rights in
either case eventually the database

348
00:32:06,450 --> 00:32:13,190
我刚才提到的服务器将发送删除的书面密钥
server as I'm just mentioned will send a
delete for the written keys

349
00:32:19,510 --> 00:32:24,670
我对如何编写新值显示过时的数据感到困惑的另一个问题
another question I'm confused on how
writing the new value shows stale data

350
00:32:24,670 --> 00:32:42,500
但是删除并不能让我看到我不确定该问题在问什么
but deleting doesn't let me see I'm not
really sure what the question is asking

351
00:32:42,500 --> 00:32:53,090
如果它是参考此代码的，一旦写入完成就可以了
the if it's with reference to this code
once the writes done okay maybe the

352
00:32:53,090 --> 00:32:59,060
问题是，实际上我们根本没有删除，因此当客户
question is it's really we didn't do
delete at all so that when a client a

353
00:32:59,060 --> 00:33:03,350
前端网络做了一个或想要更新他David只会告诉
front web for an end did or wanted to
update him David would just tell the

354
00:33:03,350 --> 00:33:10,420
数据库，但未从memcache显式删除数据
database but not explicitly delete the
data from memcache the problem with this

355
00:33:10,420 --> 00:33:19,430
就是如果客户端将此写入发送到数据库，然后立即读取
is that if the client sent this write to
the database and then immediately read

356
00:33:19,430 --> 00:33:24,830
读取的相同数据将从memcache中输出，因为memcache 
the same data that read would come out
of the memcache and because memcache

357
00:33:24,830 --> 00:33:27,590
仍然有旧数据，您知道内存缓存尚未正确显示
still has the old data
you know memcache hasn't seen this right

358
00:33:27,590 --> 00:33:32,900
客户端更新了一些数据，然后读取它，您知道在
yet a client that updated some data and
then read it you know updates it in the

359
00:33:32,900 --> 00:33:36,320
数据库，但如果过时的数据是从memcache中读取的，则它将读取数据，然后
database but it reads the data if the
stale data from memcache and then a

360
00:33:36,320 --> 00:33:41,570
客户端可能会更新一些数据，但仍会看到旧数据，如果您将其删除， 
client might update some data but still
see the old data and if you delete it

361
00:33:41,570 --> 00:33:46,640
从memcache中删除，那么如果您这样做的话，那么一个客户端要比写入的客户端
from memcache then if a client if you do
do this delete than a client that writes

362
00:33:46,640 --> 00:33:51,800
一些数据，并将其从内存缓存中删除，然后再次读取，它将丢失
some data and deletes it from memcache
and then reads it again it'll miss in

363
00:33:51,800 --> 00:33:55,100
内存缓存是因为删除而不必去数据库
memcache because of the delete and they
don't have to go to the database and

364
00:33:55,100 --> 00:34:03,560
读取数据，数据库将为它提供新鲜的数据，所以问题是
read the data and the database will give
it fresh data okay so the question is

365
00:34:03,560 --> 00:34:10,730
为什么我们为什么要在这里删除天哪，为什么我们不只是这个呢
how come why do we delete here
gosh why don't we just instead of this

366
00:34:10,730 --> 00:34:18,260
直接删除客户端，因为它知道新数据就发送一个
delete have the client just directly
since it knows the new data just send a

367
00:34:18,260 --> 00:34:24,949
设置RPC-memcache T，这是一个好问题
set RPC - memcache T and this is a this
is a good question

368
00:34:24,949 --> 00:34:29,089
所以在这里，我们正在做一个无效方案，这通常是

369
00:34:29,090 --> 00:34:37,370
称为更新方案，让我尝试制作一个示例，该示例显示
called an update scheme and let me try
to cook up an example that shows that

370
00:34:37,370 --> 00:34:44,980
虽然可以使它适用于此更新方案，但它不起作用
while this could probably be made to
work this update scheme it doesn't work

371
00:34:45,130 --> 00:34:48,800
它开箱即用，您不需要小心
it doesn't work out of the box and you
wouldn't you need to do some careful

372
00:34:48,800 --> 00:34:51,889
为了使其能够工作而设计，所以现在客户不想要摆姿势
design in order to make it work so this
wasn't client wants posing up now we

373
00:34:51,889 --> 00:34:54,819
有两个客户
have two clients

374
00:34:57,220 --> 00:35:05,760
读和写相同的密钥交错，所以假设客户一个
reading and writing the same key
interleaved so let's say client one

375
00:35:05,760 --> 00:35:15,130
告诉数据库，您知道将X加号发送给数据库
tells the database you know sends X plus
plus to the database right just

376
00:35:15,130 --> 00:35:22,990
递增X，然后当然还是让我说它将从
incrementing X and then of course or let
me say it's going to increment X from

377
00:35:22,990 --> 00:35:30,490
零到一，因此将X设置为一，然后在该客户之后将呼叫
zero to one so set X to one and then
after that client one is going to call

378
00:35:30,490 --> 00:35:40,050
我们的键集X和值1并将其写入内存缓存D 
set of our key which is X and the value
one and write that at the memcache D

379
00:35:40,050 --> 00:35:46,150
假设同时客户2也想增加X，所以它将
supposing meanwhile client two also
wants to increment X so it's going to

380
00:35:46,150 --> 00:35:50,700
读取数据库中的最新值，几乎可以肯定，这些实际上是
read this latest value in the database
and almost certainly these are in fact

381
00:35:50,700 --> 00:35:55,450
交易，所以如果我们要增加客户该怎么办？ 
transactions so what if we were doing
increment what client won't won't be

382
00:35:55,450 --> 00:35:58,810
发送将是数据库上某种增量交易，用于
sending would be some sort of increment
transaction on the database for

383
00:35:58,810 --> 00:36:02,710
正确性，因为该数据库确实支持事务处理，因此我们将
correctness because the database does
support transactions so we're going to

384
00:36:02,710 --> 00:36:07,839
假设客户将x的值递增到，以将该增量发送到
imagine the client to increments the
value of x to to sends that increment to

385
00:36:07,839 --> 00:36:12,070
数据库和客户端两个也将执行此设置，因此它将
the database and client two also is
going to do this set so it's going to

386
00:36:12,070 --> 00:36:19,690
将X设置为2，但现在剩下的是内存缓存D中1的值
set X to be two but now what we're left
with is the value of one in memcache D

387
00:36:19,690 --> 00:36:25,540
即使正确的值和要说的数据库
even though the correct values and the
databases to which is to say if we do

388
00:36:25,540 --> 00:36:29,560
设置了此更新，即使它确实为我们节省了一些时间，因为现在
this update was set even though it does
save us some time right cuz now we're

389
00:36:29,560 --> 00:36:33,099
避免将来有人错过，因为我们直接说而不是
saving somebody a miss in the future
because we directly said instead of

390
00:36:33,099 --> 00:36:39,040
如果它是留下陈旧数据的流行数据，则删除也有风险
delete we also run the risk if the if
it's popular data of leaving stale data

391
00:36:39,040 --> 00:36:45,849
在数据库中不是不是您无法以某种方式使它工作，而是
in the database it's not that you
couldn't get this to work somehow but it

392
00:36:45,849 --> 00:36:55,599
确实需要仔细考虑才能解决此问题，所以这就是为什么
does require some careful thought to fix
this problem all right so that was why

393
00:36:55,599 --> 00:37:03,109
他们使用了invalidate而不是更新，所以我打算
they use invalidate and instead of
update okay so I was going to

394
00:37:03,109 --> 00:37:09,789
关于绩效，他们如何获得绩效的这种途径是
about performance they this sort of
route of how they get performance is

395
00:37:09,789 --> 00:37:16,279
通过并行并行化并行执行并用于存储
through parallel parallelization
parallel execution and for a storage

396
00:37:16,279 --> 00:37:21,499
系统只是一个高层次上，实际上有两种方法可以使您获得良好的
system just at a high level there's
really two ways that you can get a good

397
00:37:21,499 --> 00:37:27,400
性能之一是通过分区进行分片
performance
one is by partition which is sharding

398
00:37:27,400 --> 00:37:32,450
那就是你拿走你的数据，然后把它分成十个部分
that is you take your data and you split
it up over you know into ten pieces over

399
00:37:32,450 --> 00:37:37,190
十台服务器，那十台服务器可以独立运行
ten servers and those ten servers can
run independently hopefully the other

400
00:37:37,190 --> 00:37:42,579
复制时可以使用额外硬件获得更高性能的方法
way you can use extra hardware to get
higher performance despite replication

401
00:37:42,579 --> 00:37:51,109
在拥有一个以上的数据副本，而您对于给定的数量
at is have more than one copy of the
data and you kind of for a given amount

402
00:37:51,109 --> 00:37:55,670
硬件类型，您可以选择是否对数据进行分区或
of hardware you can kind of choose
whether to partition your data or

403
00:37:55,670 --> 00:38:04,519
复制它以使用该硬件，您从中了解到
replicate it in order to use that
hardware and there's you know from

404
00:38:04,519 --> 00:38:09,529
 memcache，看看我们在这里谈论的是通过
memcache see what we're talking about
here is is splitting the data over the

405
00:38:09,529 --> 00:38:14,509
通过散列密钥来使用可用的Memcache服务器，从而使每种密钥都能生存
available memcache servers by hashing
the key so that every key sort of lives

406
00:38:14,509 --> 00:38:18,789
在一个内存缓存服务器上，从内存缓存中，我们在这里谈论的是
on one memcache server and from memcache
what we would be talking about here is

407
00:38:18,789 --> 00:38:23,839
让每个前端仅与单个Memcache服务器对话并发送其所有
having each front-end just talk to a
single memcache server and send all its

408
00:38:23,839 --> 00:38:29,029
请求在那里，以便每个内存缓存服务器仅服务前端的一个子集
requests there so that each memcache
server serves only a subset of the front

409
00:38:29,029 --> 00:38:35,599
结束并满足他们的所有需求，Facebook实际上使用了一种组合
ends and sort of serves all their needs
and Facebook actually uses a combination

410
00:38:35,599 --> 00:38:41,390
分区和复制都可以对分区中的事物进行分区
of both partition and replication for
partition the things that are in its

411
00:38:41,390 --> 00:38:48,220
支持一个原因是它的存储效率很高，因为您只存储一个副本
favor one is that it's memory efficient
because you only store a single copy of

412
00:38:48,220 --> 00:38:52,519
复制中的每个项目Abita您将存储每个数据
each item Abita where's in replication
you're gonna store every piece of data

413
00:38:52,519 --> 00:39:03,290
也许在每个分区上的服务器上，只要
maybe on every server on the sort of
partition is that it's as long as your

414
00:39:03,290 --> 00:39:07,970
钥匙在某种程度上同样受欢迎，但是效果很好，但是如果有
keys are sort of equally roughly equally
popular works pretty well but if there's

415
00:39:07,970 --> 00:39:12,140
一些热键，热键分区对您的帮助并不大
some hot a few hot keys partition
doesn't really help you much once you

416
00:39:12,140 --> 00:39:17,690
获得足够的分区，以使这些热键位于不同的服务器上
get those partition enough that those
hot keys are on different servers you

417
00:39:17,690 --> 00:39:20,690
一次知道是否有一个热键，例如没有
know once the if there's a single hot
key for example no amount of

418
00:39:20,690 --> 00:39:25,220
分区可以为您提供帮助，因为无论您对该热键进行多少分区
partitioning helps you because no matter
of how much you partition that hot key

419
00:39:25,220 --> 00:39:30,550
仍然坐在一台服务器上
is still sitting on just one server

420
00:39:34,100 --> 00:39:40,890
问题分区是，这并不意味着前端需要前端
the problem partition is that it doesn't
mean that the front if front ends need

421
00:39:40,890 --> 00:39:44,970
要使用大量不同键的数据，这意味着最后每个前端
to use lots of data lots of different
keys it means in the end each front-end

422
00:39:44,970 --> 00:39:51,060
可能会与许多分区进行通信，至少如果您使用
is probably going to talk to lots of
partitions and at least if you use

423
00:39:51,060 --> 00:39:58,530
像TCP这样的保持状态的协议会给您带来巨大的开销
protocols like TCP that keep state
there's significant overhead to as you

424
00:39:58,530 --> 00:40:09,480
为复制添加越来越多的N平方通信
add more and more sort of N squared
communication for a replication it's

425
00:40:09,480 --> 00:40:17,160
如果您的问题是一些键很受欢迎，那太棒了，因为现在您
fantastic if if your problem is that a
few keys are popular because now you

426
00:40:17,160 --> 00:40:20,369
知道您正在复制这些热键，并且可以为每个热键服务
know you're making replicas of those
those hotkeys and you can serve each

427
00:40:20,369 --> 00:40:26,490
并行复制相同的密钥，这很好，因为它的数量更少
replica the same key in parallel it's
good because there's fewer this there's

428
00:40:26,490 --> 00:40:30,270
每个前端可能只与一个人通话，而不是平方通信
not n squared communication each
front-end maybe only talks to one

429
00:40:30,270 --> 00:40:40,220
内存缓存服务器，但坏的地方是每个服务器中都有一个数据副本
memcache server but the bad thing is
it's there's a copy of data in every

430
00:40:40,220 --> 00:40:47,600
在服务器上，您可以通过复制然后通过以下方式缓存更少的独特数据项
server you can cache far fewer distinct
data items with replication then with

431
00:40:47,600 --> 00:40:57,140
分区，因此可以存储的总数据更少，所以这些只是通用的
partition so there's less total data can
be stored so these are just generic for

432
00:40:57,140 --> 00:41:02,990
这两种使用额外硬件来提高性能的主要方法的利弊
pros and cons of these two main ways of
using extra hardware to get higher

433
00:41:02,990 --> 00:41:11,150
性能还不错，所以我想谈一谈这种情况
performance alright so I want to talk a
bit about there when one sort of context

434
00:41:11,150 --> 00:41:15,620
他们使用分区和复制的级别是不同的
in which they use partition and
replication is at the level of different

435
00:41:15,620 --> 00:41:26,110
地区，所以我只想说说为什么他们决定要
regions so I just want to talk through
why it is that they decided to have

436
00:41:26,110 --> 00:41:30,560
单独的区域和种类完整的数据中心，其中包含所有数据
separate regions and kind of separate
complete data center with all the data

437
00:41:30,560 --> 00:41:35,990
在每个地区，所以在我这样做之前，我有一个问题，为什么我们不能
in each of the regions so I before I do
that there's a question why can't we

438
00:41:35,990 --> 00:41:42,170
可以通过复制缓存相同数量的数据，所以假设您有10个
cache the same amount of data with
replication ok so supposing you have 10

439
00:41:42,170 --> 00:41:48,380
每台计算机都有1 GB的RAM，您可以将这10台计算机分别用于
machines each with a gigabyte of RAM and
you can use these 10 machines each with

440
00:41:48,380 --> 00:41:53,960
一个GB的RAM，用于复制或分区方案（如果您使用
a gigabyte of RAM for either replication
or in a partitioning scheme if you use a

441
00:41:53,960 --> 00:41:58,310
每个服务器存储彼此不同数据的分区方案
partitioning scheme where each server
stores different data from the other

442
00:41:58,310 --> 00:42:04,250
服务器上，您总共可以存储10 GB的不同数据对象
servers that you can store a total of 10
gigabytes of distinct data objects on

443
00:42:04,250 --> 00:42:09,680
您的10台服务器各有1 GB的RAM，因此对于分区，您知道每个字节
your 10 servers each with a gigabyte of
RAM so with partition you know each byte

444
00:42:09,680 --> 00:42:12,470
的ram用于不同的数据，因此您可以查看您的RAM总量
of ram is used for different data so you
can look at the total amount of RAM you

445
00:42:12,470 --> 00:42:16,940
这就是您知道可以存储多少不同数据的不同数据
have that's how much distinct data you
know different data items you can store

446
00:42:16,940 --> 00:42:22,400
通过复制，您知道您的用户或多或少都在关注
with replication you know assuming your
users are more or less looking at the

447
00:42:22,400 --> 00:42:32,240
每个副本每个缓存相同的东西最终将大致存储
same stuff each each replicas each cache
replicas will end up storing roughly the

448
00:42:32,240 --> 00:42:38,060
与所有其他缓存相同的东西，所以您的10个拥有10 GB的RAM 
same stuff as all the other caches so
your 10 you have 10 gigabytes of RAM

449
00:42:38,060 --> 00:42:42,920
仍然他们和您的10台机器，但其中每台机器大致存储
still they and your 10 machines but each
of those machines stores roughly the

450
00:42:42,920 --> 00:42:48,460
相同的数据，那么您最终会得到这10个相同千兆字节项目的副本吗？ 
same data so would you end up with this
10 copies of the same gigabyte of items

451
00:42:48,460 --> 00:42:52,090
因此在这个特定示例中，如果您使用复制， 
so in a can this particular example if
you use replication you

452
00:42:52,090 --> 00:42:57,010
打attempt尝试许多不同的数据项，您知道实际上可能是
snoring attempt as many distinct data
items and you know that may actually be

453
00:42:57,010 --> 00:43:04,480
一个好主意取决于您了解数据的某种方式，但它确实
a good idea depending on you know sort
of way your data is like but it does

454
00:43:04,480 --> 00:43:09,490
意味着复制使您缓存的总数据更少，您知道
mean that replication gives you less
total data that's cached and you know

455
00:43:09,490 --> 00:43:14,530
您可以看到纸质字词中提到了这种张力
you can see there's points in the paper
word that they mention this tension

456
00:43:14,530 --> 00:43:19,150
名义上，它们不会落在另一侧，因为它们同时使用
nominally they don't come down on one
side of the other because they use both

457
00:43:19,150 --> 00:43:30,100
复制和制图好吧好吧，所以它们处于最高级别
replication and charting okay okay so
the highest level at which they're

458
00:43:30,100 --> 00:43:36,730
玩此游戏是在区域之间进行的，因此在每个区域的较高级别上
playing this game is between regions and
so it at this high level each region has

459
00:43:36,730 --> 00:43:41,200
所有数据的完整副本，它们具有每个区域的完整信息
a complete replica of all the data right
they have a each region as a complete

460
00:43:41,200 --> 00:43:45,340
数据库服务器集每个数据库数据库对应的数据库服务器
set of database servers each database
database corresponding database servers

461
00:43:45,340 --> 00:43:49,150
对于相同的数据并假设用户正在或多或少地看到相同的东西
for the same data and assuming users are
looking at more or less the same stuff

462
00:43:49,150 --> 00:43:55,030
这意味着不同区域的内存缓存服务器也存储着更多
that means the memcache servers in the
different regions are also storing more

463
00:43:55,030 --> 00:43:59,350
或基本上没有复制，我们在两个地方都复制了您的
or less basically replicating where we
have yours replicating in both the

464
00:43:59,350 --> 00:44:04,330
数据库服务器和内存缓存服务器，还有一点是
database servers and the memcache
servers and the point again one point is

465
00:44:04,330 --> 00:44:11,590
您想要一个完整的网站副本，该副本与
to you want a complete copy of the site
that's close to West Coast users in the

466
00:44:11,590 --> 00:44:16,030
互联网初期的互联网负载和完整网站的另一个副本
internet load early in the internet and
another copy of the complete website

467
00:44:16,030 --> 00:44:22,240
这个靠近东海岸的用户再次关闭了互联网， 
this close to users on the East Coast
close on the internet again and the

468
00:44:22,240 --> 00:44:27,460
互联网非常快，但是您知道50毫秒还是
Internet's pretty fast but coast to
coast is you know 50 milliseconds or

469
00:44:27,460 --> 00:44:31,770
如果用户必须等待太多50毫秒，该怎么办
something which if you do if users have
to wait too many 50 millisecond

470
00:44:31,770 --> 00:44:36,880
他们会开始注意到间隔时间的另一个原因是
intervals they'll start to notice that
amount of time another reason is that

471
00:44:36,880 --> 00:44:44,930
您想在两者之间应用数据的理由
the you wanna a reason to
applicate the data between the two

472
00:44:44,930 --> 00:44:50,740
这些前端甚至可以为用户创建一个网页
regions is that these front ends to even
create a single web page for user

473
00:44:50,740 --> 00:44:55,880
通常从缓存中请求数十个或数百个不同的数据项
requests often dozens or hundreds of
distinct data items from the cache or

474
00:44:55,880 --> 00:45:00,920
数据库，因此速度加快了延迟，前端延迟了
the databases and so the speed the
latency the delay at which a front-end

475
00:45:00,920 --> 00:45:05,420
可以从memcache键的外观中获取这数百个项目
can fetch these hundreds of items from
that from the look from the memcache key

476
00:45:05,420 --> 00:45:10,610
非常重要，因此拥有前台
is quite important and so it's extremely
important to have the front and only

477
00:45:10,610 --> 00:45:17,960
交谈只读取本地内存缓存服务器和本地数据库，以便您可以
talk to only read local memcache servers
and local databases so that you can do

478
00:45:17,960 --> 00:45:21,350
它需要非常快速地对网页执行数百个查询，因此如果我们
the hundreds of queries it needs to do
for a web page very rapidly so if we

479
00:45:21,350 --> 00:45:27,110
已经在两个区域之间对数据进行了分区，那么前端您是否知道
have partitioned the data between the
two regions then a front-end you know if

480
00:45:27,110 --> 00:45:29,990
我正在看我的朋友，有些朋友在东海岸，有些在
I'm looking at my friends and some of my
friends are on the East Coast and some

481
00:45:29,990 --> 00:45:33,860
在西海岸，这意味着如果我们进行分区，可能需要
on the west coast that means if we
partitioned that would might require the

482
00:45:33,860 --> 00:45:39,820
前端实际上发出了许多您知道每个50毫秒的请求
front ends to actually make many
requests you know 50 milliseconds each

483
00:45:39,820 --> 00:45:49,280
到另一个数据中心，用户会看到这种延迟， 
to the other data center and users would
users would see this kind of latency and

484
00:45:49,280 --> 00:45:53,720
很难过，所以复制的另一个原因是保持
be very upset so so the reason to
another reason to replicate is to keep

485
00:45:53,720 --> 00:46:00,140
前端总是靠近数据，而他们需要的所有数据
the front ends always close to the data
to all the data they need of course this

486
00:46:00,140 --> 00:46:03,500
使写入操作更加昂贵，因为现在如果前端和次要区域
makes writes more expensive because now
if a front-end and the secondary region

487
00:46:03,500 --> 00:46:07,940
需要写estest整个互联网上发送数据的方式
needs to write in estes send the data
all the way across the internet the

488
00:46:07,940 --> 00:46:13,850
读取的频率远远高于正确的读取频率，因此尽管这是一个不错的权衡
reads are far far more frequent than
right so it's a good trade-off although

489
00:46:13,850 --> 00:46:18,200
该论文没有提及可能是另一个原因
the paper doesn't mention it it's
possible that another reason for

490
00:46:18,200 --> 00:46:23,720
两个站点之间的完全复制是这样，如果主站点
complete replication between the two
sites is so that if the primary site

491
00:46:23,720 --> 00:46:27,560
掉下来，也许他们可以将整个操作切换到辅助站点
goes down perhaps they could switch the
whole operation to the secondary site

492
00:46:27,560 --> 00:46:31,570
但我不知道他们是否想到了
but I don't know if they had that in
mind

493
00:46:34,890 --> 00:46:40,359
好的，这是摄政人之间的故事，基本上是
okay so this is the story between
Regents is basically a story of

494
00:46:40,359 --> 00:46:45,359
两个数据中心之间的复制
replication between the two data centers

495
00:46:48,150 --> 00:47:00,269
现在在一个区域内的数据中心内，因此在每个区域内
all right now within a data center
within a region so in each region

496
00:47:00,269 --> 00:47:06,239
只有一组数据库服务器
there's a single set of database servers

497
00:47:07,620 --> 00:47:14,910
因此，在数据库级别，数据被绘制成图表，而不是在每个数据库内部复制
so at the database level the data is
charted and not replicated inside each

498
00:47:14,910 --> 00:47:21,060
但是在内存缓存级别，他们实际上使用复制以及
region however at the memcache level
they actually use replication as well as

499
00:47:21,060 --> 00:47:26,190
绘制图表，因此他们具有聚类的概念，因此实际上是给定区域
charting so they had this notion of
clusters so a given regions actually

500
00:47:26,190 --> 00:47:31,680
支持前端和数据库服务器的多个集群，所以我在这里
supports multiple clusters of front-ends
and database servers so here I'm going

501
00:47:31,680 --> 00:47:35,670
在这个区域有两个集群，这个集群有一个你知道的前面
to have two clusters in this region this
cluster has a you know a bunch of front

502
00:47:35,670 --> 00:47:45,690
末端和一堆内存缓存服务器，它们几乎完全独立
ends and a bunch of memcache servers and
these are completely independent almost

503
00:47:45,690 --> 00:47:49,440
完全独立，因此前端和集群可以发送其所有信息
completely independent so that a
front-end and cluster one sends all its

504
00:47:49,440 --> 00:47:54,300
读取到本地内存缓存服务器，但错过了它需要转到一台
reads to the local memcache servers and
misses it needs to go to the one instead

505
00:47:54,300 --> 00:48:01,340
数据库服务器以及该集群中的每个前端的数量
of database servers and similarly each
front-end in this cluster

506
00:48:02,680 --> 00:48:11,480
只与同一个集群中的Memcache服务器通信，为什么它们具有此功能
talks only to memcache servers in the
same cluster so why do they have this

507
00:48:11,480 --> 00:48:16,580
多个群集为什么不只是本质上知道一个群集
multiple clusters why not just have you
know essentially a single cluster a

508
00:48:16,580 --> 00:48:20,690
共享一组前端服务器和一组内存缓存服务器
single set of front end servers and a
single set of memcache server is shared

509
00:48:20,690 --> 00:48:26,180
所有这些前端之一就是，如果您这样做了，那将意味着您
by all those front ends one is that if
you did that and and that would mean you

510
00:48:26,180 --> 00:48:29,360
知道是否需要扩大容量，您会增加更多
know if you need to scale up capacity
you sort of be adding more and more

511
00:48:29,360 --> 00:48:36,230
前端的Memcache服务器与您无法获得任何胜利的同一群集
memcache servers in front ends to the
same cluster you don't get any win

512
00:48:36,230 --> 00:48:43,100
因此，您可以了解流行键的性能，因此
therefore in performance for popular
Keys you know so there the data sort of

513
00:48:43,100 --> 00:48:46,400
此内存缓存服务是某种混合，您知道大多数可能仅用于
this memcache service is sort of a mix
you know most of it is maybe only used

514
00:48:46,400 --> 00:48:49,790
由少数用户提供，但其中有些东西很多
by a small number of users but there's
some stuff there that lots and lots of

515
00:48:49,790 --> 00:48:55,370
用户需要查看并通过使用复制以及分片来获得
users need to look at and by using
replication as well as sharding they get

516
00:48:55,370 --> 00:49:00,800
您知道非常受欢迎的密钥的多个副本，因此它们得到了排序
you know multiple copies of the very
popular keys and therefore they get sort

517
00:49:00,800 --> 00:49:07,880
这些键在不同群集之间的并行服务
of parallel serving of those keys
between the different clusters another

518
00:49:07,880 --> 00:49:13,340
也不想增加群集大小的原因
reason to not want to increase the size
of the cluster individual cluster too

519
00:49:13,340 --> 00:49:19,550
大部分是集群中的所有数据分布在分区上
much is that all the data within a
cluster is spread over partitioned over

520
00:49:19,550 --> 00:49:23,780
所有的内存缓存服务器和任何一个前端通常实际上都将
all the memcache servers and any one
front end is typically actually going to

521
00:49:23,780 --> 00:49:30,650
最终可能需要从每个内存缓存服务器中获取数据，所以这
need data from probably every single
memcache server eventually and so this

522
00:49:30,650 --> 00:49:33,380
表示您在前端之间有一种n平方的交流模式
means you have a sort of n-squared
communication pattern between the front

523
00:49:33,380 --> 00:49:39,590
终端和内存缓存服务器，并在一定程度上使用了TCP 
ends and the memcache servers and to the
extent that they're using TCP for the

524
00:49:39,590 --> 00:49:44,180
涉及大量开销，大量连接的通信
communication that involves a lot of
overhead a lot of sort of connection

525
00:49:44,180 --> 00:49:50,120
状态为所有不同的TCP，所以他们想限制，所以你知道这是N 
state for all the different TCP so they
wanted to limit so you know this is N

526
00:49:50,120 --> 00:49:57,440
他们想限制中共的平方，这样做的方法是
squared CCP's they want to limit the
growth of this and the way to do that is

527
00:49:57,440 --> 00:50:01,640
确保没有一个簇变得太大，所以这个N平方不会
to make sure that no one cluster gets to
be too big so this N squared doesn't get

528
00:50:01,640 --> 00:50:03,970
太大了
too large

529
00:50:09,010 --> 00:50:14,740
与此相关的是，他们在种姓拥挤行业中
and well related to that is this in
caste congestion business they're

530
00:50:14,740 --> 00:50:20,530
谈论如果主持人需要来自许多Memcache服务器的数据， 
talking about the if a frontman needs
data from lots of memcache servers it's

531
00:50:20,530 --> 00:50:23,290
实际上它将或多或少全部发出请求
actually it's gonna send out the
requests more or less all at the same

532
00:50:23,290 --> 00:50:26,860
时间，这意味着该前端将获得所有
time and that means this front-end is
gonna get the responses from all the

533
00:50:26,860 --> 00:50:30,520
记忆快取伺服器或多或少会在同一时间查询
memcache servers to query it more or
less the same side time and that may

534
00:50:30,520 --> 00:50:34,630
意味着数十或数百个数据包同时全部到达此处
mean dozens or hundreds of packets
arriving here all at the same time which

535
00:50:34,630 --> 00:50:41,890
如果您不小心，将导致种姓拥塞和
if you're not careful we'll cause packet
losses that's in caste congestion and in

536
00:50:41,890 --> 00:50:44,740
为了限制那是多么糟糕，你有他们谈论的一堆技术
order to limit how bad that was that you
had a bunch of techniques they talked

537
00:50:44,740 --> 00:50:49,150
大约一个，但其中一个并没有使群集太大，因此
about but one of them was not making the
clusters too large so that the number of

538
00:50:49,150 --> 00:50:53,650
 memcache使前端倾向于与之对话，并且他们可能在做出贡献
memcache has given front-end tend to
talk to and they might be contributing

539
00:50:53,650 --> 00:50:59,650
同一种姓永远不会太大，这也是论文的最终原因
to the same caste never got to be too
large and a final reason the paper

540
00:50:59,650 --> 00:51:04,990
提到的是它的背后或背后是数据中心中的大型网络， 
mentions is that it's or behind this is
is a big network in the data center and

541
00:51:04,990 --> 00:51:11,860
很难建立既像每秒许多位又快的网络
it's hard to build networks that are
both fast like many bits per second and

542
00:51:11,860 --> 00:51:16,480
可以与很多不同的计算机通话，并且可以拆分数据
can talk to lots and lots of different
computers and by splitting the data

543
00:51:16,480 --> 00:51:20,800
集中到这些集群中，并使大多数通信持续进行
center up into these clusters and having
most of the communication go on just

544
00:51:20,800 --> 00:51:25,210
在每个集群中，这意味着他们需要较小的，他们需要一个中等的人
within each cluster that means they need
a smaller they need you know a modest

545
00:51:25,210 --> 00:51:29,050
快速设置此群集的网络，并且您知道的适度大小也相当快
size fast Network for this cluster and a
modest size you know reasonably fast

546
00:51:29,050 --> 00:51:32,050
该群集的网络，但他们不必建立一个可以
network for this cluster but they don't
have to build a single network that can

547
00:51:32,050 --> 00:51:37,090
可以处理所有计算机之间的所有流量
sort of handle all of the traffic
between among all the computers of the

548
00:51:37,090 --> 00:51:44,620
巨型集群，因此它限制了基础网络的昂贵程度
giant cluster so it limits how expensive
underlying network is on the other hand

549
00:51:44,620 --> 00:51:50,020
当然，他们正在复制数据和两个群集，并复制那些
of course they're replicating the data
and the two clusters and for items that

550
00:51:50,020 --> 00:51:53,500
不是很受欢迎，也不会从性能中真正受益
aren't very popular and aren't really
going to benefit from the performance

551
00:51:53,500 --> 00:52:00,370
拥有多份副本的胜利，这会浪费在所有RAM上，而您
win of having multiple copies this it's
wasteful to sit on all this RAM and you

552
00:52:00,370 --> 00:52:03,700
知道我们在谈论数百或数千台服务器，因此
know we're talking about hundreds or
thousands of servers so the amount of

553
00:52:03,700 --> 00:52:10,540
他们花在RAM上用于内存缓存服务的钱不是开玩笑，所以除了
money they spent on RAM for the memcache
services is no joke so in addition to

554
00:52:10,540 --> 00:52:17,220
每个群集中的Memcache服务器池还有一个区域池
the pool of memcache servers inside each
cluster there's also this regional pool

555
00:52:17,220 --> 00:52:23,109
区域中所有群集共享的内存缓存服务器的数量
of memcache servers that's
shared by all the clusters in a region

556
00:52:23,109 --> 00:52:30,609
然后进入该区域池，然后在前端修改软件，以便
and into this regional pool they then
modify the software on the front end so

557
00:52:30,609 --> 00:52:32,890
前端软件知道啊
that the software on the front end knows
aha

558
00:52:32,890 --> 00:52:38,290
这个钥匙这个滑雪板的数据实际上并不经常使用而不是存储它
this key the data for this skis actually
not use that often instead of storing it

559
00:52:38,290 --> 00:52:43,300
在我自己的集群的Memcache服务器上，我将存储这个不是很受欢迎的密钥
on a memcache server my own cluster I'm
going to store this not very popular key

560
00:52:43,300 --> 00:52:53,339
在区域池的相应Memcache服务器中，所以这是
in the appropriate memcache server of
the regional pool so this is

561
00:52:55,480 --> 00:53:02,339
区域池，这只是一些数据不是
the regional pool and this is just sort
of an admission that some data is not

562
00:53:02,339 --> 00:53:06,670
受欢迎到足以拥有很多复制品，他们可以通过
popular enough to want to have lots of
replicas of it they can save money by

563
00:53:06,670 --> 00:53:15,520
只能兑现一份副本，这样他们就可以得到这种
only cashing a single copy all right so
that's how they get that's this kind of

564
00:53:15,520 --> 00:53:22,599
他们在每个内部使用的Carol复制与分区策略
Carol replication versus partitioning
strategy they use inside each inside

565
00:53:22,599 --> 00:53:28,770
他们讨论的每个地区都有一个困难，就是他们想
each region a difficulty they had that
they discuss is that when they want to

566
00:53:28,770 --> 00:53:34,510
在数据中心中创建一个新集群，它们实际上具有某种临时性
create a new cluster in a data center
they actually have a sort of temporary

567
00:53:34,510 --> 00:53:38,920
性能问题，因为他们正在使群集运行，所以您知道
performance problem as they're getting
that cluster going so you know supposing

568
00:53:38,920 --> 00:53:42,970
他们决定安装您知道的几百台机器成为新集群
they decide to install you know couple
hundred machines to be a new cluster

569
00:53:42,970 --> 00:53:47,829
与前端新前端新的内存缓存错误，然后将其启动
with the front end new front ends new
memcache errors and then they fire it up

570
00:53:47,829 --> 00:53:52,630
而且您可能会导致一半的用户开始使用新集群
and you know maybe cause half the users
to start using the new cluster I'm gonna

571
00:53:52,630 --> 00:53:56,710
一开始必须很好地使用旧集群
have to use the old cluster well in the
beginning there's nothing in these

572
00:53:56,710 --> 00:54:00,220
内存缓存服务器和所有前端服务器都将在内存缓存中丢失
memcache servers and all the front end
servers are gonna miss on the memcache

573
00:54:00,220 --> 00:54:06,730
服务器，并且至少要从头开始直到
servers and have to go to the databases
and at least at the beginning until

574
00:54:06,730 --> 00:54:10,660
这些记忆快取服务会填入所有
these memcache service gets populated
with all the sort of data that's used a

575
00:54:10,660 --> 00:54:15,010
很多这会绝对增加数据库服务器上的负载
lot this is gonna increase the load on
the database servers absolutely enormous

576
00:54:15,010 --> 00:54:19,869
飞跃是因为在我们添加新集群之前，也许只有数据库服务器
leap because before we added the new
clusters maybe the database servers only

577
00:54:19,869 --> 00:54:24,280
看到了百分之一的读取，因为也许这些内存缓存服务器受到了打击
saw one percent of the reads because
maybe these memcache servers have a hit

578
00:54:24,280 --> 00:54:28,420
比如说99％的阅读率仅意味着
rate of say 99 percent for reads the
only one percent of all that means go to

579
00:54:28,420 --> 00:54:33,520
如果我们添加新集群，则在添加新集群之前，数据库服务器
the database servers before we added the
new cluster if we add a new cluster with

580
00:54:33,520 --> 00:54:37,510
内存缓存服务器中没有任何内容，并将一半的流量发送给它，它将获得
nothing in the memcache servers and send
half the traffic to it it's gonna get a

581
00:54:37,510 --> 00:54:44,500
最初的百分百未命中率正确，所以这意味着您知道我们
hundred percent miss rate initially
right and so that'll mean you know we

582
00:54:44,500 --> 00:54:48,490
消失了，因此总体未命中写入现在将为50％，所以我们走了
gone from and so the overall miss write
will now be 50 percent so we've gone

583
00:54:48,490 --> 00:54:54,460
从这些数据库服务器中为读取的百分之一提供服务，而这些服务器则为50 
from these database servers serving one
percent of the reads to them serving 50

584
00:54:54,460 --> 00:54:58,530
阅读次数的百分比，因此至少在这个虚构的示例中， 
percent of the reads so at least in this
imaginary example we've been quite

585
00:54:58,530 --> 00:55:02,559
启动这个新集群，我们可能会将数据库的负载增加一个
firing up this new cluster we may
increase the load on the databases by a

586
00:55:02,559 --> 00:55:07,329
系数是50，数据库服务器可能正在运行
factor of 50 and chances are the
database servers were running you know

587
00:55:07,329 --> 00:55:12,009
合理的海岸的能力，当然不是50/50 
reasonably Coast's the capacity and
certainly not a factor of 50/50 under

588
00:55:12,009 --> 00:55:17,710
能力，所以如果他们只是这将是世界的绝对终结
capacity and so this would be the
absolute end of the world if they just

589
00:55:17,710 --> 00:55:26,650
像这样启动了一个新集群，所以他们有了这个冷启动想法
fired up a new cluster like that and so
instead they have this cold start idea

590
00:55:26,650 --> 00:55:33,690
在这个新集群中，某处用某种标记来标记该集群
in which a new cluster is sort of marked
by some flag somewhere as being in this

591
00:55:33,690 --> 00:55:40,599
冷启动状态，在这种情况下，前端和新群集
cold start state and in that situation
when a front end and the new cluster

592
00:55:40,599 --> 00:55:48,369
首先错过了它首先拥有的本地内存缓存
misses that actually first first it has
its own local memcache if that says no I

593
00:55:48,369 --> 00:55:51,910
没有数据，那么前端我们将询问相应的内存缓存
don't have the data then the front end
we'll ask the corresponding memcache in

594
00:55:51,910 --> 00:55:56,410
一些暖群集中的另一个群集，该群集已经具有该数据的数据
another cluster in some warm cluster
that already has the data for the data

595
00:55:56,410 --> 00:56:01,569
如果它是流行的数据机会，它将被缓存到我的朋友那里，并将得到它
if it's popular data chances are it'll
be cached my friend and will get its

596
00:56:01,569 --> 00:56:08,680
数据，然后将其安装在本地内存缓存中
data and then it will install it in the
local memcache and it's only if both

597
00:56:08,680 --> 00:56:13,180
本地内存缓存和热内存缓存没有前面的数据
local memcache and the warm memcache
don't have the data that this is front

598
00:56:13,180 --> 00:56:20,680
结束，新集群将从数据库服务器读取，就这样
end and the new cluster will read from
the database servers and so this is it

599
00:56:20,680 --> 00:56:24,490
所以他们在这种冷模式下运行了一段时间
and so they run in this kind of cold
mode for a little while the paper I

600
00:56:24,490 --> 00:56:28,180
 think提到了几个小时，直到内存缓存服务器源和新的
think mentions a couple hours until the
memcache servers source and the new

601
00:56:28,180 --> 00:56:32,650
群集开始拥有所有流行数据，然后可以将其关闭
clusters start to have all the popular
data and then they can turn off this

602
00:56:32,650 --> 00:56:42,660
冷功能，仅使用本地群集内存缓存就可以了
cold feature and just use the local
cluster memcache alone it's alright

603
00:56:42,660 --> 00:56:49,630
因此，本文讨论的另一个负载问题是是否遇到了
so another another load problem that the
paper talks about if they ran into and

604
00:56:49,630 --> 00:56:55,980
这又是由这种外观缓存引起的负载问题
this is a load problem again deriving
from this kind of look aside caching

605
00:56:55,980 --> 00:57:06,490
策略被称为雷群和情景
strategies is called the thundering herd
and the the scenario

606
00:57:06,490 --> 00:57:12,310
是假设我们有一些数据，有很多Memcache服务器，但是
is that supposing we have some piece of
data there's lotsa memcache servers but

607
00:57:12,310 --> 00:57:16,600
在此Memcache服务器上存储了一些数据
there's some piece of data stored on
this memcache server there's a whole

608
00:57:16,600 --> 00:57:23,560
一堆通常读的很流行的前端
bunch of front ends that are ordinarily
reading that one piece of very popular

609
00:57:23,560 --> 00:57:27,369
数据，因此他们都在不断发送有关该数据的获取请求， 
data so they're all sending constantly
sending get requests for that data the

610
00:57:27,369 --> 00:57:31,450
 memcache服务器将其存储在缓存中，它会回答他们，您知道他们的memcache 
memcache server has it in the cache it
answers them and you know their memcache

611
00:57:31,450 --> 00:57:36,100
服务器每秒可保存约数百万至数百万个请求，因此我们
server is conserve like millions to
million requests per second so we're

612
00:57:36,100 --> 00:57:40,540
做得很好，当然这里还有一些数据库服务器
doing pretty good and of course there's
some database server sitting back here

613
00:57:40,540 --> 00:57:43,420
拥有该数据的真实副本，但我们不会打扰它，因为它是
that has the real copy of that data but
we're not bothering it because it is

614
00:57:43,420 --> 00:57:49,570
很好地缓存，假设有一些前端出现并修改了这个非常流行的
cached well suppose some front-end comes
along and modifies this very popular

615
00:57:49,570 --> 00:57:53,080
数据，因此它将使用新数据向数据库发送写操作，然后
data so it's going to send a write to
the database with the new data and then

616
00:57:53,080 --> 00:57:58,570
它会将删除内容发送到内存缓存服务器，因为这是权限的方式
it's gonna send a delete to the memcache
server because that's the way rights

617
00:57:58,570 --> 00:58:02,800
工作，所以现在我们已经删除了这些非常受欢迎的数据，我们拥有了所有这些
work so now we've just deleted this
extremely popular data we have all these

618
00:58:02,800 --> 00:58:08,320
前端不断发送数据获取信息，他们都会在这里错过一切
front ends constantly sending gets for
that data they're all gonna miss all at

619
00:58:08,320 --> 00:58:17,410
同时他们都想念的同时将读取请求发送给
the same time they're all gonna now
having missed send a read request to the

620
00:58:17,410 --> 00:58:22,090
前端数据库都在同一时间，所以现在这个前端数据库是
front end database all at the same time
and so now this front-end database is

621
00:58:22,090 --> 00:58:25,660
可能同时面对数十或数百个此数据的请求，因此
faced with maybe dozens or hundreds of
simultaneous requests for this data so

622
00:58:25,660 --> 00:58:30,580
这里的洛斯人会很高，尤其令人失望
the Loews here is gonna be pretty high
and it's particularly disappointing

623
00:58:30,580 --> 00:58:35,380
因为我们知道所有这些请求都是针对同一密钥的，所以数据库是
because we know that all these requests
are for the same key so the database is

624
00:58:35,380 --> 00:58:39,190
一遍又一遍地做同样的工作，以最新的书面回应
going to do the same work over and over
again to respond with the latest written

625
00:58:39,190 --> 00:58:48,460
该密钥的副本，直到最终前端解决了安装新密钥的问题
copy of that key until finally the front
ends get around to installing the new

626
00:58:48,460 --> 00:58:53,109
键入memcache，然后人们开始再次点击，所以这是
key in memcache and then people start
hitting again and so this is the

627
00:58:53,109 --> 00:58:58,810
雷鸣伤害了我们真正想要的是一个单身，您知道如果错过了
Thundering hurt what we'd really like is
a single you know if a miss if there's a

628
00:58:58,810 --> 00:59:03,550
正确，线索和未命中发生在内存缓存中，我们希望我们想要的是
right and the leads and a miss happens
in memcache we'd like what we'd like is

629
00:59:03,550 --> 00:59:07,390
对于错过获取数据并安装数据的第一个前端， 
the for the first front end that misses
to fetch the data and install it and for

630
00:59:07,390 --> 00:59:11,710
其他前端就像深呼吸，然后等到新数据
the other front ends just like take a
deep breath then wait until the new data

631
00:59:11,710 --> 00:59:17,029
被缓存，这就是他们的设计
is cached and that's
just what their design does if you look

632
00:59:17,029 --> 00:59:26,119
如果使用了与作品不同的叫做Elise的东西
at the if this thing called Elise which
is different from the pieces were used

633
00:59:26,119 --> 00:59:33,339
到，但他们叫Elise，我们再次从场景开始
to but they call Elise and we start from
scratch in the scenario again let's see

634
00:59:33,339 --> 00:59:40,640
所以现在假设我们在第一个前端询问了一个流行的数据
so now suppose we have a popular piece
of data the first front end that asks

635
00:59:40,640 --> 00:59:46,039
对于缺少memcache的数据，Devo将发回错误，说不
for a data that's missing memcache Devo
will send back an error saying oh no I

636
00:59:46,039 --> 00:59:51,529
我的缓存中没有数据，但是它将安装Elise，这有点独特
don't have the data in my cache but it
will install Elise which is a bit unique

637
00:59:51,529 --> 00:59:57,470
编号，它将选择最少的编号安装在表中并发送此租约
number it'll pick a least number install
it in a table and the send this lease

638
00:59:57,470 --> 01:00:03,079
令牌返回到前端，然后进入其他前端并询问
token back to the front end and then
other front ends that come in and ask

639
01:00:03,079 --> 01:00:10,849
对于相同的基思，他们只会得到一个只是被要求等待，你知道一个季度
for the same Keith they'll simply get a
just be asked to wait you know a quarter

640
01:00:10,849 --> 01:00:13,789
快取记忆体D花费一秒或任何合理的时间，因为
of a second or whatever some reasonable
amount of time by the memcache D because

641
01:00:13,789 --> 01:00:16,880
 memcache密钥会看到哈哈，我已经为该密钥发布了租约
the memcache key will see a haha I've
already issued the lease for that key

642
01:00:16,880 --> 01:00:21,529
现在至少有一个潜在的V Sparky服务器会注意到
now there's at least potentially a V
Sparky the server will notice it's

643
01:00:21,529 --> 01:00:26,259
已经发出的通知至少可以让这些等待，所以只有一个
already issued at least for the can tell
these ones to wait so only one of the

644
01:00:26,259 --> 01:00:33,230
服务器的猜测Elise然后该服务器在以下情况下从数据库中请求数据
server's guess Elise this server then
asks for the data from the database when

645
01:00:33,230 --> 01:00:39,730
反对回复妈妈，然后发送看跌期权以获取新数据
against the responds back mom
then it sends the put for the new data

646
01:00:40,210 --> 01:00:45,039
用一把钥匙和上帝的价值，最少的证明那是
with a key and the value of God and the
least proved that it was the one who was

647
01:00:45,039 --> 01:00:48,190
允许写数据memcache的人今天在寻找这些东西
allowed to write the data memcache
people looking for these today aha yeah

648
01:00:48,190 --> 01:00:52,960
您是被授予租赁权的人，它实际上会
you are the the person whose lease was
granted and it'll actually do the

649
01:00:52,960 --> 01:00:57,250
和其他的朋友安装，他们被告知等待将重新发布他们的
install by and by these other friends
who are told the wait will reissue their

650
01:00:57,250 --> 01:01:03,430
现在读到它将在那里，所以如果一切顺利，我们所有人都只能得到一个
reads now that it will be there and so
we all if all goes well get just one

651
01:01:03,430 --> 01:01:08,740
请求到数据库，而不是几十或数百，我认为这是
request to the database instead of
dozens or hundreds and I think it's the

652
01:01:08,740 --> 01:01:14,260
租约的意义在于前端是否在尴尬的时刻失败了， 
sense in which is the lease is if the
front-end fails at an awkward moment and

653
01:01:14,260 --> 01:01:17,650
实际上没有从数据库请求数据或没有解决它
doesn't actually request the data from
the database or doesn't get around it

654
01:01:17,650 --> 01:01:21,700
安装它memcache D最终memcache D将删除租约cuz 
installing it memcache D eventually
memcache D will delete the lease cuz it

655
01:01:21,700 --> 01:01:26,770
超时，下一个要问的前端将获得新的租约，并希望
times out and the next front end to ask
will get a new lease and will hope that

656
01:01:26,770 --> 01:01:32,319
它将与数据库对话并安装新数据，所以他们会回答问题
it will talk to the database and install
new data so yes they answer the question

657
01:01:32,319 --> 01:01:41,140
如果第一个前端出现故障，租约会超时，是的，是的，所以
the lease does up a time out in case the
first front end fails yes yes okay so

658
01:01:41,140 --> 01:01:48,130
这些租约是雷电群问题的解决方案。 
these leases are the their solution to
the Thundering Herd problem um another

659
01:01:48,130 --> 01:01:54,430
他们的问题是，如果这些Memcache服务器之一故障最多
problem they have is that if one of
these memcache servers fails the most

660
01:01:54,430 --> 01:01:58,059
您自然会知道，如果内存缓存服务器没有做任何特别的事情，该怎么办
natural you-know-whats if they don't do
anything special if the memcache server

661
01:01:58,059 --> 01:02:02,470
前端失败将发送请求，他们将获得超时和网络
fails the front ends will send a request
they'll get back a timeout and network

662
01:02:02,470 --> 01:02:05,819
会说jeez，您知道我无法与该主机联系，但从未收到回复
will say jeez that you know I couldn't
contact that host never got a response

663
01:02:05,819 --> 01:02:10,869
真正的I BRE软件所做的就是感觉到它
and what the real I BRE
software does is it then sense it

664
01:02:10,869 --> 01:02:14,980
请求数据库，以便如果Memcache服务器发生故障而我们什么也不做
requests the database so if a memcache
server fails and we don't do anything

665
01:02:14,980 --> 01:02:19,720
特殊的数据库现在将直接暴露给所有读取
special the database is now going to be
exposed directly to the reads all of

666
01:02:19,720 --> 01:02:22,779
这些礁石，我赶上服务器West，这是Memcache服务器可能
these reefs and I'm catch server West
serving this is the memcache server may

667
01:02:22,779 --> 01:02:26,770
一直在为您服务，您知道每秒一百万次读取可能意味着
well have been serving you know a
million reads per second that may mean

668
01:02:26,770 --> 01:02:30,339
这样数据库服务器将可以承受每百万次读取
that the database server would be then
exposed to those million reads per

669
01:02:30,339 --> 01:02:37,440
第二，那么现在还远远不够快，无法对付所有这些杂草
second then it's nowhere near fast
enough to deal with all those weeds now

670
01:02:37,440 --> 01:02:40,960
他们在论文中并未真正提及Facebook，但他们确实实现了自动化
Facebook they don't really talk about in
the paper but they do have automated

671
01:02:40,960 --> 01:02:48,010
机器来替换故障的memcache服务器，但是要花一些时间才能
machinery to replace a failed memcache
server but that takes a while to sort of

672
01:02:48,010 --> 01:02:53,850
设置新服务器，新的内存缓存服务器并重定向所有前端
set up a new server a new memcache
server and redirect all the front-end

673
01:02:53,850 --> 01:02:57,150
到新服务器而不是旧服务器，因此在此期间，他们需要一个
to the new server instead of the old
server so in the meantime they need a

674
01:02:57,150 --> 01:03:06,510
一种临时解决方案，这就是这个想法，所以我们说说瓢
sort of temporary solution and that's
this gutter idea so let's say the scoop

675
01:03:06,510 --> 01:03:13,890
是我们有前端，我们拥有一组普通的内存缓存
is that we have our front ends we have
the sort of ordinary set of memcache

676
01:03:13,890 --> 01:03:16,610
伺服器
servers

677
01:03:17,610 --> 01:03:23,500
数据库，其中一个内存缓存服务已失败，我们正在等待
the database the one of the memcache
service has failed we're kind of waiting

678
01:03:23,500 --> 01:03:27,970
直到自动Memcache服务器替换系统替换了此文件
until the automatic memcache server
replacement system replaces this

679
01:03:27,970 --> 01:03:32,980
在此期间，memcache服务器的朋友正在向其发送请求， 
memcache server in the meantime
friends are sending requests to it they

680
01:03:32,980 --> 01:03:38,800
得到一种服务器没有响应来自网络的错误，然后有
get a sort of server did not respond
error from the network and then there's

681
01:03:38,800 --> 01:03:45,540
一组很小的装订线服务器
a presumably small set of gutter servers

682
01:03:46,109 --> 01:03:55,960
他们唯一的目的就是要注视他们，他们必须闲置，除非真正的
whose only purpose in life is to eye
they must be idle except when a real

683
01:03:55,960 --> 01:04:00,190
 memcache服务器发生故障，并且当前端出现错误并返回时说get 
memcache server fails and when the front
end gets an error back saying that get

684
01:04:00,190 --> 01:04:05,140
无法联系内存缓存服务器，它会将相同的请求发送到其中之一
couldn't contact the memcache server
it'll send the same request to one of

685
01:04:05,140 --> 01:04:08,349
装订线服务器，尽管论文没有说我想像前端
the gutter servers and though the paper
doesn't say I imagine that the front end

686
01:04:08,349 --> 01:04:13,650
将再次对密钥进行哈希处理，以选择要与之通信的装订线服务器
will again hash the key in order to
choose which gutter server to talk to

687
01:04:13,800 --> 01:04:18,819
如果装订线服务器具有巨大的价值
and if the gutter server has the value
that's great

688
01:04:18,819 --> 01:04:22,630
否则，前端服务器将与数据库服务器联系以读取
otherwise the front end server will
contact the database server to read the

689
01:04:22,630 --> 01:04:27,339
值，然后将其安装在内存缓存服务器中，以防其他人
value and then install it in the
memcache server in case somebody else

690
01:04:27,339 --> 01:04:32,410
答案要求提供相同的数据，所以这意味着下水道
answer asks for the same data
so while this means down the gutter

691
01:04:32,410 --> 01:04:39,910
服务器将基本上处理其请求，因此它们将是您的理想选择
servers will handle basically handle its
request and so they'll be a miss you

692
01:04:39,910 --> 01:04:42,579
知道由租赁处理的雷霆牧群
know handled by lease leases the
Thundering Herd

693
01:04:42,579 --> 01:04:46,810
他们至少会是我每个项目上都需要通过的小姐
they'll be at least I need a Miss on
each of the items that was a no-fail

694
01:04:46,810 --> 01:04:50,319
 memcache服务器，因此数据库服务器中将有一些负载，但是
memcache server so there will be some
load in the database server but then

695
01:04:50,319 --> 01:04:54,460
希望很快，此内存缓存服务器可以让我获取所有侦听的数据
hopefully quickly this memcache server
will I get all the data that's listen

696
01:04:54,460 --> 01:05:01,540
使用并提供良好的服务，然后将被替换，然后
use and provide good service and then by
and by this will be replaced and then

697
01:05:01,540 --> 01:05:07,180
朋友会知道要与其他替换服务器通话，因为
the friends will know to talk to a
different replacement server and because

698
01:05:07,180 --> 01:05:13,150
他们没有，这是今天的问题，我认为他们不会将删除发送给
they don't and this is today's question
I think that they don't send deletes to

699
01:05:13,150 --> 01:05:16,569
这些装订线服务器，因为既然装订线服务器本来可以接管
these gutter servers because since a
gutter server could have taken over for

700
01:05:16,569 --> 01:05:22,119
任何人，甚至可能超过一种普通的内存缓存服务
anyone and maybe more than one of the
ordinary memcache service it could

701
01:05:22,119 --> 01:05:30,910
实际上有缓存任何键的缓存，这意味着并且可能
actually have cache the caching any key
so that would mean that and there may be

702
01:05:30,910 --> 01:05:35,290
您知道有朋友在谈论它，这意味着无论何时前端
you know friends talking to it that
would mean that whenever a front-end

703
01:05:35,290 --> 01:05:40,569
需要它从内存缓存中删除密钥或数据库中的尖叫声发送时
needs it to delete a key from memcache
or when the squeal on the database sends

704
01:05:40,569 --> 01:05:46,420
删除相关内存缓存服务器的任何密钥，是的，您知道
a delete for any key to the relevant
memcache server yeah you know the the

705
01:05:46,420 --> 01:05:51,609
自然的设计是它还会将删除的副本发送给每个
natural design would be that it would
also send a copy of that delete to every

706
01:05:51,609 --> 01:05:55,119
其中一个装订线服务器，以及用于删除数据的前端的装订线服务器
one of the gutter servers and the same
for front ends that are deleting data

707
01:05:55,119 --> 01:05:58,180
他们会从内存缓存存储中删除，但他们也必须离开
they would delete from the memcache
stores but they would also have to leave

708
01:05:58,180 --> 01:06:04,289
可能来自任何MCAD装订线服务器，它将使
potentially from any
MCAD gutter server that would double the

709
01:06:04,289 --> 01:06:06,839
即使在大多数情况下也必须发送的失败数量
amount of defeats that had to be sent
around even though most of the time

710
01:06:06,839 --> 01:06:09,690
这些装订线服务器什么也不做，也不缓存任何东西，它
these gutter servers aren't doing
anything and don't cache anything and it

711
01:06:09,690 --> 01:06:15,619
没关系，因此为了避免所有这些额外的删除，实际上
doesn't matter and so in order to avoid
all these extra deletes they actually

712
01:06:15,619 --> 01:06:22,619
修复装订线服务器，以便它们非常快速地删除密钥，而不是删除
fix the gutter servers so that they
delete Keys very rapidly instead of

713
01:06:22,619 --> 01:06:27,989
挂在他们身上，直到他们被明确删除为止
hanging on to them until they're
explicitly deleted that was answer to

714
01:06:27,989 --> 01:06:38,999
这个问题很好，所以我想一次讨论一下一致性
the question all right so I wanna talk a
bit about consistency all this at a

715
01:06:38,999 --> 01:06:45,210
超高水平，您知道一致性问题是，有很多
super high level you know the
consistency problem is that there's lots

716
01:06:45,210 --> 01:06:50,519
任何给定数据的数据副本的数量，您知道其中有一个副本
of copies of the data for any given
piece of data you know there's a copy in

717
01:06:50,519 --> 01:06:54,749
主数据库在对应的数据库服务器中有一个副本
the primary database there's a copy in
the corresponding database server of

718
01:06:54,749 --> 01:07:01,799
每个次要区域在每个本地集群中都有该密钥的副本
each of the secondary regions there's a
copy of that key in each local cluster

719
01:07:01,799 --> 01:07:06,359
在每个本地群集中的一个Memcache键中，可能存在
in one of the memcache keys in each
local cluster there may be copies of

720
01:07:06,359 --> 01:07:11,400
该密钥和装订线服务器，并且在其中可能有该密钥的副本
that key and the gutter servers and
there may be copies of the key in the

721
01:07:11,400 --> 01:07:14,849
内存缓存服务器和装订线内存缓存服务器位于彼此的其他区域，因此我们拥有
memcache servers and the gutter memcache
servers at each other region so we have

722
01:07:14,849 --> 01:07:19,259
写入时每条数据的大量副本
lots and lots of copies of every piece
of data running around when a write

723
01:07:19,259 --> 01:07:23,930
进来，你知道所有这些副本上都必须有东西
comes in you know the stuff has to
happen on all those copies and

724
01:07:23,930 --> 01:07:28,319
此外，写入可能来自多个来源，而相同的密钥可能是
furthermore the writes may come from
multiple sources the same key may be

725
01:07:28,319 --> 01:07:32,009
由多个前端同时写入，并且该区域可能是
written at the same time by multiple
front ends and this region may be by

726
01:07:32,009 --> 01:07:38,249
朋友和其他地区，也是这种并发和多重
friends and other regions too and so
it's this concurrency and multiple

727
01:07:38,249 --> 01:07:42,859
由于存在多个前端，因此可以复制和分类多个写入源
copies and sort of multiple sources of
writes since there's multiple front ends

728
01:07:42,859 --> 01:07:49,440
这不仅为陈旧的数据创造了很多机会，而且为
it creates a lot of opportunity for not
just for there to be stale data but for

729
01:07:49,440 --> 01:07:58,710
数据过时的数据要长时间留在系统中，所以我想
data stale data to be left in the system
for long periods of time and so I want

730
01:07:58,710 --> 01:08:03,450
我想从某种意义上说明实际上存在哪些问题
to I want to illustrate what are those
problems actually in a sense we've

731
01:08:03,450 --> 01:08:08,700
当有人问为什么前端不这样做时，我已经谈到了这一点
already talked a bit about this when
somebody asked why the front ends don't

732
01:08:08,700 --> 01:08:12,089
更新为什么删除而不是更新，所以这肯定是一个
update why do they delete instead of
updating so that's certainly one

733
01:08:12,089 --> 01:08:17,050
天气的一个实例多个数据源，所以我们有
instance of the kind of weather
multiple sources of data and so we have

734
01:08:17,050 --> 01:08:25,830
强制执行正确的顺序很麻烦，但这是比赛的另一个例子
trouble enforcing correct order but
here's another example of a race an

735
01:08:25,830 --> 01:08:30,420
更新竞赛，如果他们没有做任何事情，将会留下数据
update race that if they hadn't done
something about it would have left data

736
01:08:30,420 --> 01:08:35,370
无限期过时的数据，并且绝对在memcache中

737
01:08:36,540 --> 01:08:40,540
这将与前面的示例类似，所以假设
it's going to be a similar flavor to the
previous example so supposing we have

738
01:08:40,540 --> 01:08:51,760
客户端，他想读取一个密钥，但是memcache说它没有数据
client one he wants to read a key but
memcache says it doesn't have the data

739
01:08:51,760 --> 01:09:02,350
是小姐，所以C人要从数据库中读取数据，然后
it's a Miss so C one's gonna read the
data from from the database and let's

740
01:09:02,350 --> 01:09:09,590
说它可以收回您想要的一些价值
say it gets back some value that you
want

741
01:09:09,590 --> 01:09:18,510
同时，客户要更新此数据，以便它向您发送有关其汇率的信息
meanwhile client to wants to update this
data so it sends you know its rates he

742
01:09:18,510 --> 01:09:26,670
等于v2并将其发送到数据库，然后您知道写入规则
equals v2 and sends that to the database
and then you know the rule for writes

743
01:09:26,670 --> 01:09:29,729
我们看到的写入代码是，我们下一步要做的是将其从
the code for writes that we saw is that
the next thing we do is delete it from

744
01:09:29,729 --> 01:09:35,389
来自memcache dc c2的数据库将要删除

745
01:09:35,390 --> 01:09:41,450
啊，数据库中的密钥哦，这是星期五，您知道它实际上是c2 
ah the key from the database oh that's a
Friday you know it was actually c2

746
01:09:41,450 --> 01:09:44,359
真的不知道memcache d中有什么，但是领导总是存在
doesn't really know what's in memcache d
but the leading was ever there is always

747
01:09:44,359 --> 01:09:50,989
安全，因为肯定不会导致过期数据被删除不会导致

748
01:09:50,990 --> 01:09:55,310
她被寂静了Leena um，这就是报纸所声称的那种感觉
her to be stilled Leena um and this is
the sense that the paper claims that

749
01:09:55,310 --> 01:10:02,810
删除是幂等的，说删除对kabhi总是安全的，但是如果您还记得
delete is idempotent said delete it's
always safe to kabhi but if you recall

750
01:10:02,810 --> 01:10:07,550
如果您错过了读操作并从中读取数据的伪代码
the pseudocode for what a read does if
you miss and you read the data from the

751
01:10:07,550 --> 01:10:12,140
您应该将数据库插入到内存缓存中，因此客户端1 
database you're supposed to just insert
that data into memcache so client 1 you

752
01:10:12,140 --> 01:10:19,430
知道可能已经很慢了，最后终于解决了发送一组RPC两个内存缓存的问题
know may have been slow and finally gets
around to sending a set RPC two memcache

753
01:10:19,430 --> 01:10:23,870
 T，但它读取版本1并读取a，您现在知道什么是旧的过时版本
T but it read version 1 and read a you
know what is now an old outdated version

754
01:10:23,870 --> 01:10:29,620
数据库中的数据，但将其设置为
of the data from the database but it's
going to set that into

755
01:10:33,020 --> 01:10:36,980
将其设置为内存缓存，是的，您知道发生的另一件事是，我们
set this into memcache and yeah you know
one other thing that happened is that we

756
01:10:36,980 --> 01:10:40,730
知道数据库是每当你写一些东西时我就是发送的数据库
know the database is is whenever you
write something I'm database that sends

757
01:10:40,730 --> 01:10:44,270
删除到内存缓存D，所以当然在这一点上数据库也可能
deletes to memcache D so of course maybe
at this point the database will also

758
01:10:44,270 --> 01:10:51,060
已经为k2m种姓发送了删除，所以现在我们转到
have sent a delete
for k2m caste and so now we get to

759
01:10:51,060 --> 01:10:53,160
删除，但这些租约可能已经拥有并不重要
deletes but it doesn't really matter
right these lease may already have

760
01:10:53,160 --> 01:10:59,730
在客户端更新密钥时发生的情况，因此
happened by the time client one gets
around to updating this key and so at

761
01:10:59,730 --> 01:11:06,420
此时，memcache D将无限期地兑现的过时版本
this point indefinitely the memcache D
will be cashing a stale version of of

762
01:11:06,420 --> 01:11:11,820
这些数据，就没有任何机制了，如果系统
this data and there's just no mechanism
anymore or this is them if the system

763
01:11:11,820 --> 01:11:16,560
以这种方式工作，memcache D没有任何机制可以看到
worked in just this way there's no
mechanism for the memcache D to ever see

764
01:11:16,560 --> 01:11:23,670
以获得将要存储和提供过时数据的实际正确值
to ever get the actual correct value
it's gonna store and serve up stale data

765
01:11:23,670 --> 01:11:27,230
永远为K键
for key K forever

766
01:11:27,369 --> 01:11:32,690
他们是因为他们碰到了这一点，而在数据尚可的情况下
and they because they ran into this and
while they're okay with data being

767
01:11:32,690 --> 01:11:37,250
有点过时了，因为数据永远都过时了
somewhat out-of-date they're not okay
with data being out of date forever

768
01:11:37,250 --> 01:11:42,349
因为用户最终会发现他们正在查看古老的数据，因此
because users will eventually notice
that they're seeing ancient data and so

769
01:11:42,349 --> 01:11:49,239
他们必须解决此问题，必须确保不会发生这种情况
they had to solve this they had to make
sure that this scenario didn't happen

770
01:11:49,250 --> 01:11:54,920
他们实际上也通过租赁机制解决了这个问题
they actually solved this this problem
also with the lease mechanism at the

771
01:11:54,920 --> 01:11:58,550
尽管我们为雷霆宝藏描述了相同的租赁机制
same lease mechanism that we describe
for the Thundering hoard although

772
01:11:58,550 --> 01:12:04,159
租赁机制有一个扩展，可以使这项工作正常进行
there's an extension to the lease
mechanism that makes this work so what

773
01:12:04,159 --> 01:12:07,940
发生的情况是，当Memcache向下倾斜时，Miss指示会看到数据
happens is that when memcache descends
back a Miss indication seeing the data

774
01:12:07,940 --> 01:12:13,099
不在缓存中，它将授予租赁，所以我们得到了Miss指示以及
wasn't in the cache it's gonna grant the
lease so we get the Miss indication plus

775
01:12:13,099 --> 01:12:19,460
这个租约基本上只是一个很大的唯一数，而内存缓存服务器是
this lease which is basically just a big
unique number and the memcache server is

776
01:12:19,460 --> 01:12:23,840
会记住此租约与它知道的此密钥之间的关联
gonna remember that the association
between this lease and this key it knows

777
01:12:23,840 --> 01:12:31,340
有人用租约来更新此密钥，新规则是
that somebody out there with a lease to
update this key the new rule is that

778
01:12:31,340 --> 01:12:36,800
当Memcache服务器从另一个客户端或
when the when the memcache server gets a
delete from either another client or

779
01:12:36,800 --> 01:12:42,440
从数据库服务器中，内存缓存服务器将要删除
from the database server the memcache
server is gonna as well as deleting the

780
01:12:42,440 --> 01:12:46,849
项将使此租约失效，因此一旦这些删除出现
item is going to invalidate this lease
so as soon as either these deletes come

781
01:12:46,849 --> 01:12:52,460
假设Elyse首先到达，则内存缓存服务器将相信这一点
in assuming that Elyse arrived first the
memcache server is gonna believe this

782
01:12:52,460 --> 01:12:57,610
从其表中租赁有关此集合的租赁
lease from its table about leases this
set

783
01:12:59,679 --> 01:13:05,739
集合到达内存缓存服务器后，现在是从前端退回的租约
is the lease back from the front end now
when the set arrives the memcache server

784
01:13:05,739 --> 01:13:09,760
会看一下租约，说一会儿，我没有租约
will look at the lease and say wait a
minute I you don't have a lease for this

785
01:13:09,760 --> 01:13:14,980
如果所有这些都适合此键，则该键会失效，我将忽略此设置，因为
key all right invalid if these fit this
key I'm gonna ignore this set so because

786
01:13:14,980 --> 01:13:18,969
租约是因为这些删除之一是在其中之一之前出现的
the lease has been because one of these
if one of these deletes came in before

787
01:13:18,969 --> 01:13:24,040
无效的集合和内存缓存服务器
the set this sees to be invalid in
invalidated and the memcache server

788
01:13:24,040 --> 01:13:29,920
会忽略此设置，这意味着该键将只留下
would ignore this set and that would
mean that the key would note just stay

789
01:13:29,920 --> 01:13:34,900
从Memcache和下一个尝试读取该密钥的客户端中丢失
missing from memcache and the next
client that tried to read that key

790
01:13:34,900 --> 01:13:40,120
您会发现Miss会立即从数据库中读取新数据，并且会
you'll get a Miss would read the fresh
data now from the database and would

791
01:13:40,120 --> 01:13:43,900
将其安装在内存缓存中，大概是第二次安装
install it in memcache and presumably
the second time around

792
01:13:43,900 --> 01:13:49,900
第二个读者的租约将是有效的，嗯，实际上您应该问
the second readers lease would be valid
um you may and indeed you should ask

793
01:13:49,900 --> 01:13:53,969
顺序不同的原因是什么，所以假设这些删除
what happened that the order is
different so supposing these deletes

794
01:13:53,969 --> 01:13:59,489
而不是在集合之前发生这些删除，而是
instead of happening before the set
these deletes were instead to have

795
01:13:59,489 --> 01:14:05,860
我想确保该方案在设置之后仍然发生，然后如何
happen after the set I want to make sure
this scheme still works then and so how

796
01:14:05,860 --> 01:14:12,580
那么事情就会发生，因为如果这些Dilys迟到了， 
things would play out then is that since
if these Dilys were late happened after

797
01:14:12,580 --> 01:14:17,100
设置Memcache服务器不会将其从签证表中删除
the set the memcache server wouldn't
delete these from its table of visas

798
01:14:17,100 --> 01:14:22,150
当场景出现时，索利斯仍会在那里，是的，我们确实会那时
Solis would still be there when the set
came and yes indeed we would still then

799
01:14:22,150 --> 01:14:30,040
它会接受我们将键设置为陈旧值的设置，但我们
it would accept the setting we would be
setting key to a stale value but our

800
01:14:30,040 --> 01:14:33,250
假设是这次删除已延迟，这意味着
assumption was this time that the
deletes had been late and that means the

801
01:14:33,250 --> 01:14:37,300
 Dilys还没有到达，当它们删除时，它们会留下来
Dilys are yet to arrive and when they
when these deletes arrive then this stay

802
01:14:37,300 --> 01:14:41,380
 theta上的数据将被从缓存中删除，因此过时的日期将在
on theta will be knocked out of the
cache and so the stale date will be in

803
01:14:41,380 --> 01:14:45,760
缓存会更长一点，但是我们不会遇到过时的情况
the cache a little bit longer but we
won't have this situation where stale

804
01:14:45,760 --> 01:14:51,390
数据无限期地位于缓存中，并且永不删除
data is sitting in the cache
indefinitely and never deleted

805
01:14:52,260 --> 01:15:07,910
莉萨机械有任何问题，好的，请给您总结一下
any questions
lissa machinery okay um to wrap up you

806
01:15:07,910 --> 01:15:12,810
将这个系统视为很多复杂的系统当然是公平的
it's certainly fair to view this system
a lot of the complexity of the system as

807
01:15:12,810 --> 01:15:17,330
源于这样的事实，那就是它拼凑在一起， 
stemming from the fact that it was sort
of put together out of pieces that

808
01:15:17,330 --> 01:15:21,900
彼此不认识，例如memcached他会很好
didn't know about each other like it
would be nice for example memcached he

809
01:15:21,900 --> 01:15:25,890
知道数据库，我了解内存缓存D和数据库的种类
knew about the database I'm understand
memcache D and the database kind of

810
01:15:25,890 --> 01:15:35,940
在一致性计划方面进行了合作，也许Facebook可以在
cooperated in a consistency scheme and
perhaps if Facebook could have at the

811
01:15:35,940 --> 01:15:40,440
从一开始，您就知道预言了事情将如何发展。 
very beginning you know predicted the
how things would play out on what the

812
01:15:40,440 --> 01:15:44,490
问题将会是，如果他们有足够的工程师来工作，他们
problems would be and if they have had
enough engineers to work on it they

813
01:15:44,490 --> 01:15:48,480
从一开始就可以建立一个可以提供所有
could have from the beginning built a
system that could provide both all the

814
01:15:48,480 --> 01:15:54,120
他们需要的高性能多数据中心复制分区
things they needed high-performance
multi data center replication partition

815
01:15:54,120 --> 01:15:59,580
一切都在这样做的公司中
and everything and they're having
companies that have done that so the

816
01:15:59,580 --> 01:16:06,420
我知道的例子最类似于
example I know of that sort of most
directly comparable to the system in

817
01:16:06,420 --> 01:16:10,800
这篇论文是，如果您关心这些东西，您可能想看看它
this paper is that if you care about
this stuff you might want to look at it

818
01:16:10,800 --> 01:16:20,540
是Yahoo的花生存储系统，其设计从头开始， 
is Yahoo's peanuts storage system which
in a sort of designed from scratch and

819
01:16:20,540 --> 01:16:26,100
您知道许多细节上都不同，但是它确实提供了多站点
you know different different in many
details but it does provide multi-site

820
01:16:26,100 --> 01:16:32,730
复制具有一致性和良好的性能，因此可以做到
replication with consistency and good
performance so it's possible to do

821
01:16:32,730 --> 01:16:37,130
更好，但是您知道所有存在的问题都存在
better but you know all the issues are
present that's just had a more

822
01:16:37,130 --> 01:16:41,270
集成的也许优雅的解决方案
integrated perhaps elegant set of
solutions

823
01:16:41,270 --> 01:16:47,970
因此，对于本文而言，对我们而言，至少对他们而言
the takeaway so for us from this paper
one is that for them at least and for

824
01:16:47,970 --> 01:16:54,210
许多大型操作缓存对于高生存至关重要至关重要
many big operations caching is vital
absolutely vital for to survive high

825
01:16:54,210 --> 01:16:59,580
加载和缓存并不仅仅是减少延迟，它还需要更多
load and the caching is not so much
about reducing latency it's much more

826
01:16:59,580 --> 01:17:05,570
隐藏相对较慢的巨大负载
about hiding enormous load from
relatively slow

827
01:17:05,570 --> 01:17:11,519
缓存实际上是为Facebook做的存储服务器正在隐藏排序
storage servers that's what a cache is
really doing for Facebook is hiding sort

828
01:17:11,519 --> 01:17:18,059
隐藏几乎所有来自数据库服务器的负载的另一个收获是
of concealing almost all the load from
the database servers another takeaway is

829
01:17:18,059 --> 01:17:23,130
在大型系统中，您始终需要考虑缓存
that you always in big systems you
always need to be thinking about caching

830
01:17:23,130 --> 01:17:28,409
与控制，对不起，分区与复制，我的意思是您需要一些方法
versus control versus sorry partition
versus replication I mean you need ways

831
01:17:28,409 --> 01:17:34,019
正式或非正式地决定您的资源量
of either formally or informally sort of
deciding how much your resources are

832
01:17:34,019 --> 01:17:40,579
将致力于分区以及复制多少，最后
going to be devoted to partitioning and
how much to replication and finally

833
01:17:40,579 --> 01:17:45,239
理想情况下，您将能够从一开始就在本文中做得更好
ideally you'd be able to do a better job
in this paper about from the beginning

834
01:17:45,239 --> 01:17:51,469
集成不同的存储层以实现良好的一致性
integrating the different storage layers
in order to achieve good consistency

835
01:17:51,469 --> 01:17:59,510
好吧，这就是我要说的，请问我问题
okay that is all I have to say please
ask me questions if you have
