[GitHub] [incubator-brpc] yanglimingcn commented on pull request #760: MySQL Prepared Statement support

[GitBox <gi...@apache.org>]

yanglimingcn commented on pull request #760:
URL: https://github.com/apache/incubator-brpc/pull/760#issuecomment-810075482


   > > 添加了mysql的prepared statement协议的支持。
   > > 遇到的两个问题解决方案如下：
   > > 1、prepared statement首先是在某个连接上创建一个statement id，后续操作可以根据这个statement id向这个连接发送后续的请求。同一个语句在每个连接上的statement id是不同的。在pooled模式下，每次RPC选择的连接是不同的，所以需要记录SocketId和statement id的关系，我们这里称为id_map。但是一个SocketId有可能关闭，然后又重新建立起来，这个新SocketId对应的连接没有这个statement id。id_map没有机制可以做到同步更新，保存的SocketId与statement id关系信息是旧的关系。这样就会产生问题。
   > > 这个问题的修改方式是，给socketid对应的fd一个唯一的版本号，每次通过stmt_id找到socketid的时候对比一下版本号，版本号一致说明fd没有变化，版本号不一致说明fd变化过。
   > > 2、目前还不能支持single模式，唯一的原因就是auth部分，正常auth多个请求会竞争发送auth，后续操作就不需要发送auth了，auth不用等待服务端应答，就可以让其他请求继续发送。但是mysql的auth和这个逻辑不通，mysql的auth首先接收mysql-server发送过来的salt，客户端根据salt加密密码，再把加密后的密码发送给服务端。这样的逻辑如果不等待服务端应答就解锁别的请求，就会出现发送auth的请求落后于正常的请求，导致消息乱序。
   > > 这个目前就先不支持single模式了。
   > 
   > 1. statement id是和连接相关的？还是和地址相关，即同一个地址不同的连接可以用一个statement id？
   > 2. single模式的认证过程的问题，我在开发cql协议的时候也遇到了，解决放案如下：
   >    在认证交互流程完成前，业务请求包先累积在buf里，等认证完成再一起发送出去。
   
   1、statement id 是连接相关的。
   2、嗯，业务请求包先累积在buf里这个我参考一下


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org