今天看了seda的event-driven模型，還有seda主頁上面的一些**，覺得非常棒。我覺得在event driven的模型上，加上「請求合併」的演算法，這樣的框架，將會提高現在很多系統的併發效能。
seda的event-driven模型，就是把系統分成若干個stage，每個stage負責一部分功能，它們通過事件驅動，這非常適合使用請求合併的演算法。 例如，現在請求佇列中有兩個查詢使用者資訊，請求a查詢使用者u1，請求b查詢使用者u2，此時可以把這兩個請求合併成乙個請求，統一訪問資料庫，然後分別返回。 這樣，原本需要兩次訪問資料庫，現在只需要一次了。
前段時間，朋友問我乙個問題：「現在大多數的企業應用系統，可承受的強併發數量都很低，通常能夠承受強併發的系統，都採用事件驅動的非同步模型」，我當時沒有答案，我現在覺得，在一些對事務不敏感的操作，企業應用完全可以使用這一模型，例如大多數業務操作需要使用到的一些基礎資料資料（人員資訊、組織架構等等）。
I O模式和事件驅動
預備知識.md 對於一次i o操作 以讀操作為例 資料會先被拷貝到作業系統核心的緩衝區中，然後從作業系統核心的緩衝區拷貝到應用程式的緩衝區 這種方式稱為標準i o或快取i o，大多數檔案系統的預設i o都是這種方式 最後交給程序。所以說，當乙個讀操作發生時 寫操作與之類似 它會經歷兩個階段 1 等待...
驅動python python實現事件驅動
eventmanager事件管理類實現，大概就百來行 左右。encoding utf 8 系統模組 from queue import queue,empty from threading import class eventmanager def init self 初始化事件管理器 事件物件列表...
事件驅動與流程驅動
1 流程驅動 類似 一般就是主動輪詢 在幹活中還要分心 主動去找活幹 這樣有空餘的時間也完全浪費掉了 2 事件驅動 類似 比如公司有乙個oa系統 你幹完活的時候只需要看下oa系統有沒分配給你活 沒有可以幹自己的事 不用擔心還有其他事沒幹完 3者對比 採用警覺式者主動去輪詢 polling 行為取決於...