前言
nginx採用多程序的模,當乙個請求過來的時候,系統會對程序進行加鎖操作,保證只有乙個程序來接受請求。
本文基於nginx 0.8.55源**，並基於epoll機制分析
1. accept鎖的實現
1.1 accpet鎖是個什麼東西
提到accept鎖，就不得不提起驚群問題。
所謂驚群問題，就是指的像nginx這種多程序的伺服器，在fork後同時監聽同乙個埠時，如果有乙個外部連線進來，會導致所有休眠的子程序被喚醒，而最終只有乙個子程序能夠成功處理accept事件，其他程序都會重新進入休眠中。這就導致出現了很多不必要的schedule和上下文切換，而這些開銷是完全不必要的。
而在linux核心的較新版本中，accept呼叫本身所引起的驚群問題已經得到了解決，但是在nginx中，accept是交給epoll機制來處理的，epoll的accept帶來的驚群問題並沒有得到解決（應該是epoll_wait本身並沒有區別讀事件是否來自於乙個listen套接字的能力，所以所有監聽這個事件的程序會被這個epoll_wait喚醒。），所以nginx的accept驚群問題仍然需要定製乙個自己的解決方案。
accept鎖就是nginx的解決方案，本質上這是乙個跨程序的互斥鎖，以這個互斥鎖來保證只有乙個程序具備監聽accept事件的能力。
實現上accept鎖是乙個跨程序鎖，其在nginx中是乙個全域性變數，宣告如下：
ngx_shmtx_t ngx_accept_mutex;
這是乙個在event模組初始化時就分配好的鎖，放在一塊程序間共享的記憶體中，以保證所有程序都能訪問這乙個例項，其加鎖解鎖是借由linux的原子變數來做cas，如果加鎖失敗則立即返回，是一種非阻塞的鎖。加解鎖**如下：
static ngx_inline ngx_uint_t
ngx_shmtx_trylock(ngx_shmtx_t *mtx)
#define ngx_shmtx_lock(mtx) ngx_spinlock((mtx)->lock, ngx_pid, 1024)
#define ngx_shmtx_unlock(mtx) (void) ngx_atomic_cmp_set((mtx)->lock, ngx_pid, 0)
可以看出，呼叫ngx_shmtx_trylock失敗後會立刻返回而不會阻塞。
1.2 accept鎖如何保證只有乙個程序能夠處理新連線
要解決epoll帶來的accept鎖的問題也很簡單，只需要保證同一時間只有乙個程序註冊了accept的epoll事件即可。
nginx採用的處理模式也沒什麼特別的，大概就是如下的邏輯：
嘗試獲取accept鎖
if 獲取成功：
在epoll中註冊accept事件
else:
在epoll中登出accept事件
處理所有事件
釋放accept鎖
當然這裡忽略了延後事件的處理，這部分我們放到後面討論。
對於accept鎖的處理和epoll中註冊登出accept事件的的處理都是在ngx_trylock_accept_mutex中進行的。而這一系列過程則是在nginx主體迴圈中反覆呼叫的void ngx_process_events_and_timers(ngx_cycle_t *cycle)中進行。
也就是說，每輪事件的處理都會首先競爭accept鎖，競爭成功則在epoll中註冊accept事件，失敗則登出accept事件，然後處理完事件之後，釋放accept鎖。由此只有乙個程序監聽乙個listen套接字，從而避免了驚群問題。
1.3 事件處理機制為不長時間占用accept鎖作了哪些努力
accept鎖處理驚群問題的方案看起來似乎很美，但如果完全使用上述邏輯，就會有乙個問題：如果伺服器非常忙，有非常多事件要處理，那麼「處理所有事件這一步」就會消耗非常長的時間，也就是說，某乙個程序長時間占用accept鎖，而又無暇處理新連線；其他程序又沒有占用accept鎖，同樣無法處理新連線——至此，新連線就處於無人處理的狀態，這對服務的實時性無疑是很要命的。
為了解決這個問題，nginx採用了將事件處理延後的方式。即在ngx_process_events的處理中，僅僅將事件放入兩個佇列中：
ngx_thread_volatile ngx_event_t *ngx_posted_accept_events;
ngx_thread_volatile ngx_event_t *ngx_posted_events;
返回後先處理ngx_posted_accept_events後立刻釋放accept鎖，然後再慢慢處理其他事件。搜尋引擎大全
即ngx_process_events僅對epoll_wait進行處理，事件的消費則放到accept鎖釋放之後，來最大限度地縮短占有accept的時間，來讓其他程序也有足夠的時機處理accept事件。
那麼具體是怎麼實現的呢？其實就是在static ngx_int_t ngx_epoll_process_events(ngx_cycle_t *cycle, ngx_msec_t timer, ngx_uint_t flags)的flags引數中傳入乙個ngx_post_events的標誌位，處理事件時檢查這個標誌位即可。
這裡只是避免了事件的消費對於accept鎖的長期占用，那麼萬一epoll_wait本身占用的時間很長呢？這種事情也不是不可能發生。這方面的處理也很簡單，epoll_wait本身是有超時時間的，限制住它的值就可以了，這個引數儲存在ngx_accept_mutex_delay這個全域性變數中。
下面放上ngx_process_events_and_timers 的實現**，可以大概一觀相關的處理：
void
ngx_process_events_and_timers(ngx_cycle_t cycle)
else
// 拿到鎖之後把flag加上post標誌，讓所有事件的處理都延後
// 以免太長時間占用accept鎖
if (ngx_accept_mutex_held) else }}
}delta = ngx_current_msec;
// 呼叫事件處理模組的process_events，處理乙個epoll_wait的方法
(void) ngx_process_events(cycle, timer, flags);
delta = ngx_current_msec - delta; //計算處理events事件所消耗的時間
ngx_log_debug1(ngx_log_debug_event, cycle->log, 0, 「timer delta: %m」, delta);
// 如果有延後處理的accept事件，那麼延後處理這個事件
if (ngx_posted_accept_events)
// 釋放accept鎖
if (ngx_accept_mutex_held)
// 處理所有的超時事件
if (delta)
ngx_log_debug1(ngx_log_debug_event, cycle->log, 0,「posted events %p」, ngx_posted_events);
if (ngx_posted_events) else }}
再來看看ngx_epoll_process_events的相關處理：
//讀事件
if ((revents & epollin) && rev->active) else
if (flags & ngx_post_events) else
}wev = c->write;
// 寫事件
if ((revents & epollout) && wev->active) else
if (flags & ngx_post_events) else
}
nginx內部鎖的實現
多程序或者多執行緒的程式，涉及到對共享資源的修改，都需要使用到鎖。最常見的情況 也一般是然並卵的情況 是對乙個全域性變數進行 操作，比如有個全域性變數i，如果多個執行緒同時執行i 教科書已經提到，是會出問題的。因為i 並不是乙個原子操作，彙編之後會是三個操作 movl i rip eax addl ...
nginx內部鎖的實現
多程序或者多執行緒的程式，涉及到對共享資源的修改，都需要使用到鎖。最常見的情況 也一般是然並卵的情況 是對乙個全域性變數進行 操作，比如有個全域性變數i，如果多個執行緒同時執行i 教科書已經提到，是會出問題的。因為i 並不是乙個原子操作，彙編之後會是三個操作 movl i rip eax addl ...
mysql 隱式鎖和顯示鎖 MySQL的鎖機制
2 解鎖階段 當事務釋放了乙個封鎖以後，事務進入解鎖階段，在該階段只能進行解鎖操作不能再進行加鎖操作。5 隱式和顯示鎖定 innodb會根據隔離級別在需要的時候自動加鎖，這稱為隱式加鎖。另外，innodb也支援通過特定的語句進行顯示加鎖 顯示加共享鎖 select lock in share mod...