erlang_mysql_driver 源码分析2

最新推荐文章于 2025-10-09 14:50:35 发布

原创

最新推荐文章于 2025-10-09 14:50:35 发布 · 1.7k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #erlang #driver #pool #mysql-conn

pool模型

探究erlang_mysql_driver对同一时刻大量请求的支持

mysql:fetch 和 mysql_conn

今天看到网络上的一篇文章说，erlang_mysql_driver的连接池实际上是没有意义的。
大概意思是，当我们的业务进程调用 mysql:fetch 去执行sql语句时，mysql:fetch会call一条消息到mysql_dispatcher进程中。所以当我们在同一时刻多进程大量调用mysql:fetch时，mysql_dispatcher会收到多条call消息，并且这些消息会阻塞在mysql_dispatcher的消息队列里。这些消息会按到达的顺序逐个处理。那么后面调用fetch的进程就必须等待，每个请求需要等待上一个请求执行结束后才能开始执行。所以虽然mysql_dispatcher背后有多个连接进程（mysql_conn）但是他们并没有起到并发使用的作用。

乍一看，好像挺有道理的。但是我又觉得不对劲，毕竟作者不至于挖个这么大的坑吧，于是测试了一下。
同一时刻，spawn 10万个进程，每个进程都调用mysql:fetch进行数据库查询。
按上面的说法，那么这个时候应该会有大量的消息阻塞在mysql_dispatcher中，测试发现mysql_dispatcher消息队列里的这些消息很快就处理完了。也就是mysql_dispatcher很快就把这些消息分发给了mysql_conn，这里我建立9个mysql_conn进程。然后大部分的消息（10万个请求）被堆积在9个mysql_conn进程的消息队列中，而且每个mysql_conn收到的消息是平均的。
证明我们的mysql_dispatcher还是能够顺利完成任务的，而且可以看出 mysql_dispatcher处理这些消息肯定只有简单的分发消息，没有涉及数据io过程的。

gen_server:call gen_server:rep

最低0.47元/天解锁文章

6 条评论

sshtsl 2017.05.26
[code=javascript] case get_next_conn(PoolId, State) of {ok, Conn, NewState} -> {reply, Conn, NewState}; error -> %% we have no active connection matching PoolId {reply, {error, {no_connection_in_pool, PoolId}}, State} end. [/code] 就算是让mysql_dispatcher真正成为请求转发进程，单点性能好点了~~ ps:求指教，最近在比较erlang-mysql-driver 和 emysql的性能，准备在新项目换个mysql驱动，驱动来源： emysql：https://github.com/Eonblast/Emysql erlydb_mysql：https://github.com/anka-213/erlydb
- aaaajw回复sshtsl 2017.05.27
  [reply]sshtsl[/reply] 这个我也不敢妄言给什么建议，我们项目用过erlang_mysql_driver，也用过emysql。最终选择了erlang_mysql_driver，是因为这个相对比较稳定，bug较少。 erlang_mysql_driver:https://github.com/dizzyd/erlang-mysql-driver.git

sshtsl 2017.05.26
并发测试 3w并发失败率56% emysql并发好点 10w失败率50% 5w失败率1% 这是我简单测试的结果。

sshtsl 2017.05.26
不对吧，pool确实是没用的吧。 mysql:fetch/3 call_server({fetch, PoolId, Query}, Timeout); with_next_conn/2 %% 这里会执行receive pool pid send mysql查询结果，之后才会{noreply, newstate} mysql_dispatcher必然是单点瓶颈。 ---------------------------------------------------------------------
- aaaajw回复sshtsl 2017.05.27
  [reply]sshtsl[/reply] mysql_conn:fetch是mysql_dispatcher调用的，如果这个接口（mysql_conn:fetch）很耗时的话，mysql_dispatcher确实会被卡住。所以这个接口并没有直接执行数据io过程（对数据库驱动而言主要的耗时是在和数据库io的过程）。我的意思是，源码那样的处理已经可以把数据io的消耗转移给众多的mysql_conn进程，mysql_dispatcher的消耗仅仅是在gb_trees的lookup、enter这类的操作上。你改成把mysql_conn的Pid直接返回给业务进程也是可以的，但我觉得并不能提升多少性能。
- sshtsl回复aaaajw 2017.05.27
  [reply]aaaajw[/reply] 对 norepley 确实是立刻返回，但最终执行这个mysql_conn:fetch的进程还是被call的那个进程，我改了下这个逻辑，noreply,改成{repey, conn, newstate}, 谁发起调用谁执行mysql_conn:fetch，这时mysql_dispatcher才真正意义上是转发消息了
- aaaajw回复sshtsl 2017.05.27
  [reply]sshtsl[/reply] 你说的这个Fun/x就是fun(Conn, State1) -> Pid = Conn#conn.pid, mysql_conn:fetch(Pid, QueryList, From), {noreply, State1} end). 这里mysql_conn:fetch就是单纯地转发消息给mysql_conn
- sshtsl回复aaaajw 2017.05.27
  [reply]aaaajw[/reply] 不对吧你看下具体代码执行fun/x的时候会receive的 fun 结束后才会gen_call 才会返回。
- aaaajw回复sshtsl 2017.05.27
  [reply]sshtsl[/reply] mysql:fetch中最终执行 “send mysql查询结果“和执行具体的query 的进程是mysql_conn，并不是mysql_dispatcher。 “之后才会{noreply, newstate}“，这里是当mysql_dispatcher找到合适的mysql_conn后，就马上把query信息转发给这个mysql_conn了，所以{noreply, NewState}基本是马上就返回的了，并不需要等query执行完后才返回。