日期:2025.4.25(凌晨) 2025.5.8(凌晨) 2025.5.11
学习内容:
-
注册功能
-
添加好友
-
修复了终止Muduo服务器段错误的bug
-
将boost服务器改成集群
-
修复了集群后发送消息只能接收到第一条消息的bug
个人总结:
首先先表示歉意,鸽了太久了这个项目。
由于这个月基本都是比赛,导致向比赛倾斜(实际是放松的更多,旅游月了直接)。
效果还是可以的,拿了块西安邀请金和重庆金。算是圆了没有国金的遗憾(邀请金也是金)
后面还有南昌和长春的,估计要铁牌预定了。
然后来稍微说一点点关于这个项目的内容:
以下部分内容来自之前写的:
注册功能|添加好友
阿巴阿巴,我是真的不想写前端啦。
这次主要是实现了注册功能和添加好友功能。
注册的页面就直接复制了登录的界面,都差不多,注册成功之后会发送给客户端注册成功的ID是多少,然后等待4秒就会跳转回登录页面。
修复了终止Muduo服务器段错误的bug
这里的段错误我忘了是哪里的问题了,但是当时是用了gdb调试core发现出来的,不得不说还是非常方便的,太好用了,直接就可以输出出来哪里有段错误的信息。只能说很香
将boost服务器改成集群
这里阐述一下,我们之前的进度是只有一个boost服务器与muduo服务器做对接,但是我们之前的只有muduo服务器的时候还是集群服务器,可以服务器之间通过那个redis来相互对接。所以我们也要实现这个,确切的讲,我们希望用户可以分布在很多的boost服务器里,这样也可以优化性能的同时,也不用担心所有用户都会瘫痪的问题等。
换个说法,之前我们集群是用来muduo服务器分布各个用户,因为muduo服务器里有一个存有用户的表,里面也存有各个的Connection,但是现在显然这个任务我们交给boost去做了,所以我们现在改成集群也应该是用boost集群去做,其实改起来非常的简单,毕竟我们之前的设计还算不错,在boost和muduo里都存有各个连接的表,muduo里有用户id对应连接的boost,boost里有用户id对应连接的connection,在之前的设计里我们是直接muduo找到对应的boost然后发送消息给boost,现在我们要将boost改成集群了后,其实没有什么影响,或者说其实对于我们整个的这个逻辑流程都没有任何的影响,可以无条件负担直接上nginx,算是改起来非常轻松的了。
直接上一下nginx的配置就好了。
stream{
upstream SerVer{
server 127.0.0.1:8080 weight=1 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8081 weight=1 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8082 weight=1 max_fails=3 fail_timeout=30s;
}
server{
proxy_connect_timeout 1s;
listen 8000;
proxy_pass SerVer;
tcp_nodelay on;
}
}
我们直接改一下这个之前写的web端里连接的端口为8000,然后开了三个server去均衡就好了。
这里为什么开三个,是因为后面的bug。。。也是这个玩意卡了我好几天
修复了集群后发送消息只能接收到第一条消息的bug
这个bug,非常的诡异。
boost改成了集群之后,我们发送消息给对方的时候,对方都只能接收到我们发送的第一条消息,而这个限制会随着每一次的对方发送消息之后被刷新掉。
什么意思呢?
就是说,A给B发消息两条,B只能接收到第一条,此时如果B再给A发送消息两条,A也只能接收到第一条消息,然后A再给B发送两条消息,B还是只能接收到A的这两条消息的第一条消息,非常的诡异只能说。
随后我排查了一下,发现问题出现在,第一条消息正常,但是第二条消息由muduo发送给id对应的boost服务器的时候,那个boost服务器根本就收不到。
调试日志输出的时候不会有输出,本来以为有可能是收到了但是没有显示出来,重写了好几次的boost服务器的异步读写,但是还是没用,然后打开了浏览器的消息栏那里,发现压根就没有接收到这个消息。
所以我猜测可能是缓冲区的问题?目前其实尚不明了。
但是我注意到,如果muduo转发给boost的时候如果两个用户都在同一个服务器上面就没有问题,也就是说我们每一次接受完一次消息之后,如果当前的boost服务器会发送出去消息,形成接受一次,就发送一次的这种模式的话,就不会有什么问题。
这也是我猜测是不是缓冲区的问题的原因之一,随后可能会去系统的学习一下boost服务器。
但是目前写了一个很弱智的东西去解决,就是我们每一次接受消息之后就会发送一条没有任何意义的消息给muduo,以此来刷新掉,这样这个诡异的bug就也比较诡异的修复好了。
void ConnectionMgr::RecvFromMuduo()
{
if (_is_reading_header)
{
RecvFromMuduoHead();
}
else
{
RecvFromMuduoBody();
}
}
void ConnectionMgr::RecvFromMuduoHead()
{
async_read(_muduo_socket, boost::asio::buffer(recv_buf_head), [this](boost::system::error_code ec, size_t)
{
if (ec)
{
std::cout << "ERROR: RECVFROMMUDUO head: " << ec.message() << std::endl;
_muduo_socket.close();
return;
}
int head_len;
memcpy(&head_len, recv_buf_head.data(), 4); // TODO
std::cout << "head_len: " << head_len << std::endl;
recv_buf_body.resize(head_len);
_is_reading_header = false;
RecvFromMuduoBody(); });
}
void ConnectionMgr::RecvFromMuduoBody()
{
async_read(_muduo_socket, boost::asio::buffer(recv_buf_body), [this](boost::system::error_code ec, size_t)
{
if (ec)
{
std::cout << "ERROR: RECVFROMMUDUO body: " << ec.message() << std::endl;
_muduo_socket.close();
return;
}
std::string json_str(recv_buf_body.data(), recv_buf_body.size());
solve(json_str);
_is_reading_header = true;
auto it = _map_cons.begin();
json js;
js["1"] = 1;
SendToMuduo(it->second,js.dump());
RecvFromMuduoHead(); });
}
中间的:
auto it = _map_cons.begin();
json js;
js["1"] = 1;
SendToMuduo(it->second,js.dump());
就是我刚才提到的发送一条没有意义的代码。
然后我们的bug就修复好了233333
本来是想找出来具体的问题的,但是发现果然个人能力比较有限。唉,菜就得多练多学。
来源链接:https://www.cnblogs.com/advisedy/p/18872439
如有侵犯您的版权,请及时联系3500663466#qq.com(#换@),我们将第一时间删除本站数据。
暂无评论内容