ETS
ETS
本章是
Mix和OTP指南的一部分，它取决于本指南的前几章。有关更多信息，请阅读简介指南或查看边栏中的章节索引。
每当我们需要查找存储桶时，我们都需要向注册表发送消息。如果我们的注册表被多个进程同时访问，注册表可能会成为瓶颈！
在本章中，我们将学习ETS（Erlang Term Storage）以及如何将其用作缓存机制。
警告！不要过早使用ETS作为缓存！记录并分析您的应用程序性能并确定哪些部分是瓶颈，以便知道您
是否应该缓存以及应该缓存什么。一旦你确定了需求，本章仅仅是ETS如何使用的一个例子。
ETS作为缓存
ETS允许我们将任何Elixir术语存储在内存表中。使用ETS表格通过Erlang的:ets模块完成：
iex> table = :ets.new(:buckets_registry, [:set, :protected])
8207
iex> :ets.insert(table, {"foo", self()})
true
iex> :ets.lookup(table, "foo")
[{"foo", #PID<0.41.0>}]
创建ETS表时，需要两个参数：表名和一组选项。从可用选项中，我们传递了表类型及其访问规则。我们选择了:set类型，这意味着密钥不能被复制。我们还设置了表的访问权限:protected，这意味着只有创建该表的进程才能写入该表，但所有进程都可以读取该进程。这些实际上是默认值，所以我们将从现在开始跳过它们。
ETS表也可以命名，允许我们通过给定名称访问它们：
iex> :ets.new(:buckets_registry, [:named_table])
:buckets_registry
iex> :ets.insert(:buckets_registry, {"foo", self()})
true
iex> :ets.lookup(:buckets_registry, "foo")
[{"foo", #PID<0.41.0>}]
让我们改变KV.Registry使用ETS表格。第一个变化是修改我们的注册表以要求名称参数，我们将用它来命名ETS表和注册表进程本身。ETS名称和进程名称存储在不同的位置，所以不存在冲突的可能性。
打开lib/kv/registry.ex，让我们改变它的实现。我们在源代码中添加了评论以突出显示我们所做的更改：
defmodule KV.Registry do
use GenServer
## Client API
@doc """
Starts the registry with the given options.
`:name` is always required.
"""
def start_link(opts) do
# 1. Pass the name to GenServer's init
server = Keyword.fetch!(opts, :name)
GenServer.start_link(__MODULE__, server, opts)
end
@doc """
Looks up the bucket pid for `name` stored in `server`.
Returns `{:ok, pid}` if the bucket exists, `:error` otherwise.
"""
def lookup(server, name) do
# 2. Lookup is now done directly in ETS, without accessing the server
case :ets.lookup(server, name) do
[{^name, pid}] -> {:ok, pid}
[] -> :error
end
end
@doc """
Ensures there is a bucket associated with the given `name` in `server`.
"""
def create(server, name) do
GenServer.cast(server, {:create, name})
end
## Server callbacks
def init(table) do
# 3. We have replaced the names map by the ETS table
names = :ets.new(table, [:named_table, read_concurrency: true])
refs = %{}
{:ok, {names, refs}}
end
# 4. The previous handle_call callback for lookup was removed
def handle_cast{:create, name}, {names, refs}) do
# 5. Read and write to the ETS table instead of the map
case lookup(names, name) do
{:ok, _pid} ->
{:noreply, {names, refs}}
:error ->
{:ok, pid} = KV.BucketSupervisor.start_bucket()
ref = Process.monitor(pid)
refs = Map.put(refs, ref, name)
:ets.insert(names, {name, pid})
{:noreply, {names, refs}}
end
end
def handle_info{:DOWN, ref, :process, _pid, _reason}, {names, refs}) do
# 6. Delete from the ETS table instead of the map
{name, refs} = Map.pop(refs, ref)
:ets.delete(names, name)
{:noreply, {names, refs}}
end
def handle_info(_msg, state) do
{:noreply, state}
end
end
请注意，在我们的更改KV.Registry.lookup/2向服务器发送请求之前，现在它直接从ETS表中读取，该表在所有进程之间共享。这是我们正在实施的缓存机制背后的主要思想。
为了使缓存机制起作用，创建的ETS表需要具有访问权限:protected（缺省值），因此所有客户端都可以从中读取数据，而只有KV.Registry进程写入该数据。我们还设置了read_concurrency: true何时启动表格，针对并发读取操作的常见场景优化表格。
我们上面执行的更改已打破我们的测试，因为注册表:name在启动时需要选项。此外，某些注册表操作（例如lookup/2要求将名称作为参数提供）而不是PID，因此我们可以执行ETS表查找。让我们改变设置功能test/kv/registry_test.exs来解决这两个问题：
setup context do
{:ok, _} = start_supervised{KV.Registry, name: context.test})
%{registry: context.test}
end
一旦我们改变了setup，一些测试将会继续失败。您甚至可能会注意到测试在运行之间通过和失败不一致。例如，“spawns buckets”测试：
test "spawns buckets", %{registry: registry} do
assert KV.Registry.lookup(registry, "shopping") == :error
KV.Registry.create(registry, "shopping")
assert {:ok, bucket} = KV.Registry.lookup(registry, "shopping")
KV.Bucket.put(bucket, "milk", 1)
assert KV.Bucket.get(bucket, "milk") == 1
end
可能会失败：
{:ok, bucket} = KV.Registry.lookup(registry, "shopping")
如果我们刚刚在上一行创建了存储桶，那么这条线如何失败？
这些失败发生的原因是，为了教学目的，我们犯了两个错误：
- 我们正在过早地优化（通过添加这个缓存层）
2. 我们正在使用cast/2（虽然我们应该使用call/2）
比赛条件？
在Elixir中开发并不会让你的代码免受竞争条件的影响。然而，Elixir的抽象概念在默认情况下没有共享，因此更容易发现竞争条件的根本原因。
我们测试中发生的事情是，在操作和我们可以在ETS表中观察到这种变化的时间之间存在延迟。这是我们期待的事情：
- 我们调用
KV.Registry.create(registry, "shopping")
2. 注册表创建存储桶并更新缓存表
3. 我们从表格中获取信息 KV.Registry.lookup(registry, "shopping")
4. 上面的命令返回 {:ok,bucket}
但是，由于KV.Registry.create/2是一个强制操作，所以在我们真正写入表之前，命令将会返回！换句话说，这发生了：
- 我们调用
KV.Registry.create(registry, "shopping")
2. 我们从表格中获取信息 KV.Registry.lookup(registry, "shopping")
3. 上面的命令返回 :error
4. 注册表创建存储桶并更新缓存表
为了解决这个问题，我们需要KV.Registry.create/2使用call/2而不是使用同步cast/2。这将保证客户只有在对表格进行更改后才能继续。让我们改变函数和它的回调，如下所示：
def create(server, name) do
GenServer.call(server, {:create, name})
end
def handle_call{:create, name}, _from, {names, refs}) do
case lookup(names, name) do
{:ok, pid} ->
{:reply, pid, {names, refs}}
:error ->
{:ok, pid} = KV.BucketSupervisor.start_bucket()
ref = Process.monitor(pid)
refs = Map.put(refs, ref, name)
:ets.insert(names, {name, pid})
{:reply, pid, {names, refs}}
end
end
我们将回调从更改handle_cast/2为handle_call/3并更改为使用创建的桶的pid进行回复。一般来说，Elixir开发人员更喜欢使用，call/2而不是cast/2因为它也提供了背压 - 你会阻止，直到你得到答复。cast/2在不必要时使用也可以被认为是不成熟的优化。
让我们再次运行测试。这一次，我们会通过--trace选项：
$ mix test --trace
--trace当您的测试死锁或存在竞争条件时，该选项非常有用，因为它同步运行所有测试（async: true无效）并显示有关每个测试的详细信息。这次我们应该下降到一两次间歇性的失败：
1) test removes buckets on exit (KV.RegistryTest)
test/kv/registry_test.exs:19
Assertion with == failed
code: KV.Registry.lookup(registry, "shopping") == :error
lhs: {:ok, #PID<0.109.0>}
rhs: :error
stacktrace:
test/kv/registry_test.exs:23
根据失败消息，我们期望该表不再存在于表格中，但它仍然存在！这个问题与我们刚刚解决的问题相反：以前在创建存储桶和更新表的命令之间存在延迟，现在存储桶过程死亡和从表中删除表项之间存在延迟。
不幸的是，这次我们不能简单地将handle_info/2负责清洗ETS表的操作改为同步操作。相反，我们需要找到一种方法来保证注册管理机构处理:DOWN在存储桶崩溃时发送的通知。
一个简单的方法是向注册中心发送一个同步请求：因为消息是按顺序处理的，如果注册中心回复Agent.stop调用后发送的请求，这意味着:DOWN消息已被处理。Agent.stop在两次测试中，通过创建一个“伪造”存储桶来实现这一点，这是一个同步请求：
test "removes buckets on exit", %{registry: registry} do
KV.Registry.create(registry, "shopping")
{:ok, bucket} = KV.Registry.lookup(registry, "shopping")
Agent.stop(bucket)
# Do a call to ensure the registry processed the DOWN message
_ = KV.Registry.create(registry, "bogus")
assert KV.Registry.lookup(registry, "shopping") == :error
end
test "removes bucket on crash", %{registry: registry} do
KV.Registry.create(registry, "shopping")
{:ok, bucket} = KV.Registry.lookup(registry, "shopping")
# Stop the bucket with non-normal reason
Agent.stop(bucket, :shutdown)
# Do a call to ensure the registry processed the DOWN message
_ = KV.Registry.create(registry, "bogus")
assert KV.Registry.lookup(registry, "shopping") == :error
end
我们的测试现在应该（总是）通过！
这就结束了我们的优化章节。我们使用ETS作为缓存机制，可以从任何进程读取数据，但写入操作仍然通过单个进程序列化。更重要的是，我们还了解到，一旦数据可以异步读取，我们需要知道它可能引入的竞争条件。
在实践中，如果您发现自己处于需要动态流程的流程注册表的位置，则应该使用作为Elixir一部分提供的Registry模块。它提供的功能类似于我们使用GenServer +构建的功能，:ets同时还能够同时执行写入和读取操作。即使在有40个内核的机器上，它也可以扩展到所有内核。
接下来，让我们讨论外部和内部依赖关系以及Mix如何帮助我们管理大型代码库。
