下面是一個reactor模式下的io簡單類圖：
reactor::run是一個死循環，單獨佔用一個線程，循環體內容是：
調用load_event()，加載自上次以來變化的事件，函數會調用_dispatch的add_event()和del_event()，將要監聽的fd和該fd上關心的事件告知demultiplexer；
調用_dispatch->dispatch()進入wait狀態，等待事件發生或超時。
passiveio_event和activeio_event的作用是建立tcp連接，即創建streamio_event對象，然後將其加入reactor。
在已建立的連接上有事件發生時，找到其對應的streamio_event對象，根據是讀還是寫調用handle_read()或handle_write()。
在handle_read()或handle_write()內部，則委託給session *_ses負責具體的邏輯。
一個session對應一個連接，它的內部可能會有接收和發送緩衝，加解密等一些組件；session_manager組織了多個session，調用session_manager的send時，需要指定一個sid，send會找到對應session，session在做了一些工作後，向reactor添加可以發送的事件，這會喚醒demultiplexer::dispatch()，然後去發送數據。
reactor包含demuliplexer和多個event，但調用demuliplexer::dispatch()時又會把reactor傳過去，event內部也有指向reactor的指針，這三個類耦合比較緊密，但好在它們整體對外解耦了。
session內部有指向session_manager的指針，session_manager管理着session，在我看來這樣實在不好。在看wdb代碼時，page類內部有指向pagecache類的指針，我通過把b樹的merge、split等操作從page移到pagecache，使得page類不再需要使用pagecache的方法了，但這裏卻是不好將session和session_manager解耦。