结语
小编也是很有感触,如果一直都是在中小公司,没有接触过大型的互联网架构设计的话,只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。
我们选择的这个行业就一直要持续的学习,又很吃青春饭。
虽然大家可能经常见到说程序员年薪几十万,但这样的人毕竟不是大部份,要么是有名校光环,要么是在阿里华为这样的大企业。年龄一大,更有可能被裁。
送给每一位想学习Java小伙伴,用来提升自己。
本文到这里就结束了,喜欢的朋友可以帮忙点赞和评论一下,感谢支持!
ngx_queue_init(&ngx_posted_accept_events);
ngx_queue_init(&ngx_posted_events);
3、初始化定时器。
4、调用 ngx_epoll_init 。
5、分配连接池空间、读事件结构体数组、写事件结构体数组。
6、为每个监听端口分配连接。
7、为每个监听端口的连接的读事件设置handler,并将每个监听端口的连接的读事件添加到epoll中。
worker 开始循环干活了
ngx_worker_process_cycle 函数(也不是很长,但是我不想放)。
不过这个我可以压缩一下,因为看了好几遍了,没上面那个那么恐怖:
for ( ;; ) {
…
/* 处理IO事件和时间事件 */
ngx_process_events_and_timers(cycle);
…
}
短哈。
在worker的主循环中,所有的事件都是通过函数ngx_process_events_and_timers处理的,那我们自然就要再往下走了嘛,今天我还非要看看它到底是怎么吃一半了再塞回去的!
ngx_process_events_and_timers
这个函数又干了些什么好事儿呢?
1、配置更新时间方式。是吧,原先我是不把定时器当回事儿的,但是这代码到处都是定时器,所以我就把定时器当回事儿了。
2、处理了一下惊群锁的事情。主要思想就是:负载过高咱就不抢,不然赶紧的冲上去。后面讲惊群的时候放这个代码。
3、调用事件处理函数ngx_process_events,epoll使用的是ngx_epoll_process_events函数。这个咱一会儿还得进去。
4、计算ngx_process_events函数的调用时间。
5、处理ngx_posted_accept_events队列的连接事件。这里accept事件的handler为ngx_event_accept。
6、处理定时器事件,具体操作是在定时器红黑树中查找过期的事件,调用其handler方法。
7、处理ngx_posted_events队列的读写事件,即遍历ngx_posted_events队列,调用事件的handler方法。
ngx_epoll_process_events
再坚持一会儿。。。
static ngx_int_t ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)
{
······
ngx_event_t *rev, *wev;
/* 调用epoll_wait,从epoll中获取发生的事件 */
events = epoll_wait(ep, event_list, (int) nevents, timer);
······
/* 处理epoll_wait返回为-1的情况 */
if (err) {
······
}
/* 若events返回为0,判断是因为epoll_wait超时还是其他原因 */
if (events == 0) {
if (timer != NGX_TIMER_INFINITE) {
return NGX_OK;
}
ngx_log_error(NGX_LOG_ALERT, cycle->log, 0,
“epoll_wait() returned no events without timeout”);
return NGX_ERROR;
}
/* 对epoll_wait返回的链表进行遍历 */
for (i = 0; i < events; i++) {
c = event_list[i].data.ptr;
/* 从data中获取connection & instance的值,并解析出instance和connection */
instance = (uintptr_t) c & 1;
c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
/* 取出connection的read事件 */
rev = c->read;
/* 判断读事件是否过期 */
if (c->fd == -1 || rev->instance != instance) {
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
“epoll: stale event %p”, c);
continue;
}
/* 取出事件的类型 */
revents = event_list[i].events;
ngx_log_debug3(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
“epoll: fd:%d ev:%04XD d:%p”,
c->fd, revents, event_list[i].data.ptr);
/* 若连接发生错误,则将EPOLLIN、EPOLLOUT添加到revents中,在调用读写事件时能够处理连接的错误 */
if (revents & (EPOLLERR|EPOLLHUP)) {
ngx_log_debug2(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
“epoll_wait() error on fd:%d ev:%04XD”,
c->fd, revents);
revents |= EPOLLIN|EPOLLOUT;
}
/* 事件为读事件且读事件在epoll中 */
if ((revents & EPOLLIN) && rev->active) {
······
rev->ready = 1;
/* 事件是否需要延迟处理?对于抢到锁监听端口的worker,会将事件延迟处理 */
if (flags & NGX_POST_EVENTS) {
/* 根据事件的是否是accept事件,加到不同的队列中 */
-
queue = rev->accept ? &ngx_posted_accept_events
- &ngx_posted_events;
ngx_post_event(rev, queue);
} else {
/* 若不需要延迟处理,直接调用read事件的handler */
rev->handler(rev);
}
}
/* 取出connection的write事件 */
wev = c->write;
/* 事件为写事件且写事件在epoll中 */
if ((revents & EPOLLOUT) && wev->active) {
/* 判断写事件是否过期 */
if (c->fd == -1 || wev->instance != instance) {
ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
“epoll: stale event %p”, c);
continue;
}
wev->ready = 1;
······
/* 事件是否需要延迟处理?对于抢到锁监听端口的worker,会将事件延迟处理 */
if (flags & NGX_POST_EVENTS) {
ngx_post_event(wev, &ngx_posted_events);
} else {
/* 若不需要延迟处理,直接调用write事件的handler */
wev->handler(wev);
}
}
}
return NGX_OK;
总结
大型分布式系统犹如一个生命,系统中各个服务犹如骨骼,其中的数据犹如血液,而Kafka犹如经络,串联整个系统。这份Kafka源码笔记通过大量的设计图展示、代码分析、示例分享,把Kafka的实现脉络展示在读者面前,帮助读者更好地研读Kafka代码。
麻烦帮忙转发一下这篇文章+关注我
ka犹如经络,串联整个系统。这份Kafka源码笔记通过大量的设计图展示、代码分析、示例分享,把Kafka的实现脉络展示在读者面前,帮助读者更好地研读Kafka代码。
麻烦帮忙转发一下这篇文章+关注我
[外链图片转存中…(img-H3prFOt6-1715409688999)]