Erlang кластеризация и gproc

Question

Я немного озадачен кластеризацией с gproc в качестве pubsub.

Я бы хотел проводить клиентские сессии с gproc ... Он отлично работает с одним узлом.

Однако,Мне нужно кластеризовать всю систему.

Кажется (насколько я понимаю), что gproc имеет 2 способа работы с кластерами, устанавливая его как глобальный, или используя gproc_dist, который выглядит как поведение gen_leader.

Прав ли я до сих пор?Каковы будут недостатки каждого метода?(Все еще предполагая, что я правильно понял)

Answer 1

1. Я думаю, что global реализована gen_leader. так что они один и тот же метод.

2. gproc_dist_tests.erl уже предоставляет пример кода для объяснения.

   dist_test_() ->
   {timeout, 120,
    [{setup,
      fun() ->
          Ns = start_slaves([dist_test_n1, dist_test_n2]),
          ?assertMatch({[ok,ok],[]},
               rpc:multicall(Ns, application, set_env,
                     [gproc, gproc_dist, Ns])),
          ?assertMatch({[ok,ok],[]},
               rpc:multicall(Ns, application, start, [gproc])),
          Ns
      end,
      fun(Ns) ->
          [rpc:call(N, init, stop, []) || N <- Ns]
      end,
      fun(Ns) ->
          {inorder,
       [
        {inparallel, [
                  fun() ->
                          ?debugVal(t_simple_reg(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_simple_counter(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_aggr_counter(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_update_counters(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_shared_counter(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_mreg(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_await_reg(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_await_self(Ns))
                  end,
                  fun() ->
                          ?debugVal(t_await_reg_exists(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_give_away(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_sync(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_monitor(Ns))
                  end,
                  fun() ->
                      ?debugVal(t_subscribe(Ns))
                  end
                 ]
        },
        fun() ->
            ?debugVal(t_sync_cand_dies(Ns))
        end,
        {timeout, 90, [fun() ->
                   ?debugVal(t_fail_node(Ns))
               end]}
       ]}
      end
     }]}.
   

3. Я думаю, что gproc создан для решения ограничения регистров процесса эрланга. То есть «только атом, а не кортеж» может использоваться в качестве зарегистрированного ключа, и один и только один процесс может быть зарегистрирован для одного зарегистрированного ключа. Erlang уже предоставил mnesia db и т. Д. Для решения данных сеанса клиента. Если данные сеанса клиента высоки, я думаю, что не стоит использовать для их обработки gproc, поскольку это задержит регистрацию процесса.