从一开始，Discord就是Elixir的早期使用者。 Erlang VM是我们打算构建的高并发、实时系统的完美候选者。我们用Elixir开发了Discord的原型，这成为我们现在的基础设施的基础。 Elixir的愿景很简单：通过更加现代化和用户友好的语言和工具集，使用Erlang VM的强大功能。
两年多的发展，我们的系统有近500万并发用户和每秒数百万个事件。虽然我们对选择的基础设施没有任何遗憾，但我们需要做大量的研究和实验才能达到这种程度。 Elixir是一个全新的生态系统，Erlang的生态系统缺乏在生产环境中的使用信息（尽管erlang in anger非常棒）。我们为Discord工作的过程中吸取了一系列的经验教训和创造了一系列的开源库。
消息发布
虽然Discord功能丰富，但大多数功能都归结为发布/订阅。用户连接WebSocket并启动一个会话process（一个GenServer），然后会话process与包含公会process（内部称为“Discord Server”，也是一个GenServer）的远程Erlang节点进行通信。当公会中发布任何内容时，它会被展示到每个与其相关的会话中。
当用户上线时，他们会连接到公会，并且公会会向所有连接的会话发布在线状态。公会在幕后有很多其他逻辑，但这是一个简化的例子：
def handle_call({:publish, message}, _from, %{sessions: sessions}=state) do
Enum.each(sessions, &send(&1.pid, message))
{:reply, :ok, state}
end我们最初Discord只能创建少于25人的公会。当人们开始将Discord用于大型公会时，我们很幸运能够出现“问题”。最终，用户创建了许多像守望先锋这样的Discord公会服务器，最多可以有30,000个并发用户。在高峰时段，我们开始看到这些process的消息消费无法跟上消息生成的速度。在某个时刻，我们必须手动干预并关闭生成消息的功能以应对高负载。在达到超负载之前，我们必须弄清楚问题所在。
我们首先在公会process中对热门路径进行基准测试，并迅速发现了一个明显的问题。在Erlang process之间发送消息并不像我们预期的那么高效，并且reduction(用于进程调度的Erlang工作单元)也非常高。我们发现单次 send/2 调用的运行时间可能在30μs到70us之间。这意味着在高峰时段，从大型公会(3W人)发布活动可能需要900毫秒到2.1秒！ Erlang process实际上是单线程的，并行工作的唯一方法是对它们进行分片。这本来是一项艰巨的任务。
我们必须以某种方式分发发布消息的工作。由于Erlang中创建process很廉价，我们的第一个猜测就是创建另一个process来处理每次发布。但是，每次发布的时间安排不同，Discord客户端依赖于事件的原子一致性(linearizability)。该解决方案也不能很好地扩展，因为公会服务本身的压力并没有减轻。
受到一篇《Boost message passing between Erlang nodes》博客文章的启发，Manifold诞生了。 Manifold将消息的发送工作分配给的远程分区节点(一系列PID)，这保证了发送process调用send/2的次数最多等于远程分区节点的数量。 Manifold首先对会话process PID进行分组，然后发送给每个远程分区节点的Manifold.Partitioner。然后Partitioner使用 erlang.phash2/2 对会话process PID进行一致性哈希，分成N组，并将消息发送给子workers(process)。最后，这些子workers将消息发送到会话process。这可以确保Partitioner不会过载，并且通过 send/2 保证原子一致性。这个解决方案实际上是 send/2 的替代品：
Manifold.send([self(), self()], :hello)
Manifold的作用是不仅可以分散消息发布的CPU成本，还可以减少节点之间的网络流量：
高速访问共享数据
Discord是通过一致性哈希实现的分布式系统。使用此方法需要我们创建可用于查找特定实体的节点的环数据结构。我们希望这很高效，所以我们使用Erlang C port（负责与C代码连接的process）并选择了Chris Moos写的lib。它对我们很有用，但随着Discord的发展壮大，当我们有大量用户重连时，我们开始发现性能问题。负责处理环数据的Erlang进程将开始变得繁忙以至于处理跟不上请求，并且整个系统将变得过载。最初的解决方案似乎很明显：运行多个process处理环数据，以更好地利用cpu的所有核来响应请求。但是，我们注意到这是一条热门路径。我们可以做得更好吗？
让我们分解这条热门路径的消耗：
- 用户可以加入任意数量的公会，但普通用户是5个。
- 负责会话的Erlang VM最多可以有500,000个实时会话。
- 当会话连接时，必须为它加入的每个公会查找远程节点。
- 使用request/reply与另一个Erlang进程通信的成本约为12μs。
如果会话服务器崩溃并重新启动，则需要大约30秒(500000X5X12μs)的时间来查找环数据。这甚至没有计算Erlang为其他process工作而取消环数据process调度的时间。我们可以取消这笔花销吗？
当他们想要加速数据访问时，人们在Elixir中做的第一件事就是引入ETS。 ETS是一个用C实现的快速、可变的字典; 我们不能马上将环数据搬进ETS，因为我们使用C port来控制环数据，所以我们将代码转换为纯Elixir。 在Elixir实现中，我们会有一个process，其工作是持有环数据并不断将其copy到ETS中，以便其他process可以直接从ETS读取。 这显著改善了性能，ETS读取时间约为7μs(很快)，但我们仍然花费17.5秒来查找环中的值。 环数据结构实际上相当大，并且将其copy进和copy出ETS是很大的花费。 我们很失望，在任何其他编程语言中，我们可以轻松地拥有一个可以安全读的共享值。 在Erlang中必须造轮子！
在做了一些研究后，我们找到了mochiglobal，一个利用VM功能的module：如果Erlang发现一个总是返回相同常量的函数，它会将该数据放入一个只读的共享堆，process可以访问而无需复制。 mochiglobal的实现原理是通过在运行时创建一个带有一个函数的Erlang module并对其进行编译。 由于数据永远不会被copy，查询成本降低到0.3us，总时间缩短到750ms(0.3usX5X500000)！ 天下没有免费午餐，在运行时使用环数据(数据量大)构建module的时间可能需要一秒钟。 好消息是我们很少改变环数据，所以这是我们愿意接受的惩罚。
我们决定将mochiglobal移植到Elixir并添加一些功能以避免创建atoms。 我们的版本名为FastGlobal。
极限并发
在解决了节点查找热路径的性能之后，我们注意到负责处理公会节点上的guild_pid查找的process变慢了。 先前的节点查找很慢时，保护了这些process，新问题是近5,000,000个会话process试图冲击10个process（每个公会节点上有一个process）。 使这条路径跑得更快并不能解决问题，潜在的问题是会话process对公会注册表的request可能会超时并将请求留在公会注册表的queue中。 然后request会在退避后重试，但会永久堆积request并最终进入不可恢复状态。 会话将阻塞在这些request直到接收到来自其他服务的消息时引发超时，最终导致会话撑爆消息队列并OOM，最终整个Erlang VM级联服务中断。
我们需要使会话process更加智能。理想情况下，如果调用失败是不可避免的，他们甚至不会尝试对公会注册表进行调用。 我们不想使用断路器(circuit breaker)，因为我们不希望超时导致不可用状态。 我们知道如何用其他编程语言解决这个问题，但我们如何在Elixir中解决它？
在大多数其他编程语言中，如果失败数量过高，我们可以使用原子计数器来跟踪未完成的请求并提前释放，事实上就是实现信号量(semaphore)。 Erlang VM是围绕协调process之间通信而构建的，但是我们不想负责进行协调的process超负载。 经过一些研究，我们偶然发现这个函数：ets.update_counter/4，它的功能是对ETS的键值执行原子递增操作。 其实我们也可以在write_concurrency模式下运行ETS，但是ets.update_counter/4 会返回更新后结果值，为我们创建 semaphore库 提供了基础。 它非常易于使用，并且在高吞吐量下表现非常出色：
semaphore_name = :my_sempahore
semaphore_max = 10
case Semaphore.call(semaphore_name, semaphore_max, fn -> :ok end) do
:ok ->
IO.puts "success"
{:error, :max} ->
IO.puts "too many callers"
end事实证明，该库有助于保护我们的Elixir基础设施。 与上述级联中断类似的情况发生在上星期，但这次可以自动恢复服务。 我们的在线服务(管理长连的服务)由于某些原因而崩溃，但会话服务甚至没有影响，并且在线服务能够在重新启动后的几分钟内重建：
在线服务中的实时在线状态
session服务的cpu使用情况
总结
选择使用和熟悉Erlang和Elixir已被证明是一种很棒的体验。 如果我们不得不重新开始，我们肯定会做出相同的选择。 我们希望分享我们的经验和工具，并且能帮助其他Elixir和Erlang开发人员。希望在我们的旅程中继续分享、解决问题并在此过程中学习。