长生不老药中的并发和后台任务？

Question

我在控制器中有一个发送大量文本消息的功能。（1000 条消息） 控制器功能看起来像这样..

def send_sms(conn, _params) do
  // code is abbreviated
  # Spawn new process for sending message and saving to database
  spawn(fn -> send_message_and_save(user, recipients, phone_numbers) end)
  // code is abbreviated
end

还有这个功能

def send_message_and_save(user, recipients, phone_numbers) do
    // code is abbreviated 
    results = Sms.send_sms_with_messaging_service_async(phone_numbers, recipients.message, msg_sid, status_callback, account, token)

    case Sales.confirm_order(recipients, attrs) do
      {:ok, %{id: order_id, user_id: user_id}} ->
        Messenger.create_message_status(results, order_id, user_id)
        # Update Bitly status as Saved
        if is_nil(recipients.bitly_id) do
        else
          bitly = Texting.Bitly.get_bitly_by_id(recipients.bitly_id)
          Bitly.confirm_changeset(bitly) |> Bitly.update()
        end
        {:ok, "Message sent successfully. Your analytics data will be updated shortly."}
      {:error, _changeset} ->
        {:error, "Can't send message!"}
    end
end

在 send_message_and_save 函数中的作业过程是这样的 1.使用外部api请求发送1000条消息。 - 我使用 Task.Supervisor.async_stream/6 做到了这一点 2. confrim_order（将订单模式标记为“已确认”状态并更新（update） 3. create_message_status(创建操作) 4.get_bitly_by_id(获取操作) 5. Bitly.confirm_changeset 和 Bitly.update（更新操作）

在此过程中，总共将发生 5000 次数据库操作。 并且在向外部 api 请求发出请求后，对于每个外部 api 请求，我的网络服务器都会有三个状态回调请求。 这意味着，发送 1000 条消息将对 message_status 架构进行 300 万次更新操作（接受、已交付或未交付）。

所以发送 1000 条消息将结束 8000 次数据库操作，我在此尝试过，我的网站变得缓慢，并且由于超时而丢失了对我的网站的一些状态回调请求（外部 api 说“连接超时的原因有很多发生；常见原因是长时间运行的数据库查询或外部进程以及对外部系统的调用需要很长时间才能返回")

那么我该如何改善这种情况呢？我怎样才能正确设计这个？ 请帮忙:(

Answer 1

我会开始使用ETS as a cache - 你知道所有需要从数据库中提取的信息，所以继续将它加载到内存中。然后，您可以启动一个负责 ETS 表的进程，并且您可以针对内存表中的该表进行所有未来的查询，这比为您需要向其发送消息的每个用户进行多次数据库调用要快得多。请注意，ETS 表只能在本地访问**，但如果您将其包装在一个进程中，那么该进程将像任何其他 OTP 进程一样在全球范围内可用。

许多应用程序的数据库存在瓶颈，因此您可以为数据库提供的工作越少越好（对于许多系统而言）。

** local 表示节点本地。如果您只在一台服务器上运行您的应用程序，那么一切都是本地的，您不必考虑太多。如果您计划对您的应用程序进行集群化，那么您需要使用 API 将 ETS 表包装在一个进程中。进程在所有集群 BEAM 节点中具有唯一地址，因此您可以使用该 API 访问内存表。在大多数情况下，您实际上可以将 ETS 视为更快的 redis。在高层次上它们是相同的，但 ETS 使用 erlang/elixir 术语，因此它没有 redis 所具有的字符串序列化开销，因此速度更快。