**：下面是一些資料用例，可能我們在瀏覽linkedin網頁時都已經看到過了。
更新後的個人資料後幾乎可以實時的出現在招聘搜尋頁面
更新後的個人資料後幾乎可以實時的出現在人脈網頁
分享乙個更新，可以近實時的出現在新聞feed頁面
令人震驚的是，如果我們使用較好的寬頻，這些頁面可以在數毫秒內完成載入!讓我們向linkedin工程師團隊致敬!
像其它初創公司一樣，linkedin 早期也是通過單個的rdbms (關係型資料庫管理系統)的幾張表來儲存使用者資料和人脈關係。是不是很原始?後來這個rdmbs擴充套件出兩個額外的資料庫系統，其中乙個用來支撐使用者個人資料的全文搜尋，另乙個用來實現社交圖。這兩個資料庫通過databus來取得最新資料。databus是乙個變化捕捉系統，它的主要目標就是捕捉那些來至可信源(像oracle)中資料集的變更，並且把這些變化更新到附加資料庫系統中。
一致性：所有應用在同一時刻看到相同的資料
可用性：保證每個請求都能收到應答，無論成功或失敗
分割槽容錯性：部分系統的訊息丟失或失敗不影響系統系統整體的正常執行
根據上面的法則，linkedin工程師團隊實現了他們稱作為時間線一致性(或者說近線系統的最終一致性，下面會解釋)以及另外兩個特性：可用性和分割槽容錯性。下面介紹目前linkedin的資料架構。
rdbms
oracle
mysql(作為espresso的底層資料儲存)
rdbms
espresso(linkedin自己開發的文件型nosql資料儲存系統)
voldemart (分布式key-value儲存系統)
hdfs (存放hadoop map-reduce任務的資料)
caching
memcached
基於lucene的索引
存放查詢、關係圖等功能資料的lucene 索引
espresso使用的索引
圖：linkedin資料庫系統包括了databus、nosql、rdbms以及indexes
上面提到的資料儲存庫被歸為三種不同型別的系統，下面會逐一解釋：
espresso是乙個支援水平擴充套件、索引、時間線一致性、基於文件且高可用的nosql資料倉儲，旨在代替支撐公司網頁操作所使用的傳統oracle資料庫。設計它的初衷是為了提高linkedin的inmail訊息服務的可用性。目前有如下一些應用在使用espresso作為可信源系統。能夠看到nosql資料儲存是如果被用來處理如此眾多應用的資料需求很是神奇!
成員間訊息,
社交動作，如：更新
文章分享
使用者個人資料
公司資料
新聞文章
離線系統主要包括hadoop和乙個teradata資料倉儲，用來執行批處理和分析類的工作。之所以被稱為離線是因為它對資料執行的的批處理操作。 apache azkaban被用來管理hadoop和etl任務，這些任務從主可信源系統獲取資料後交由map-reduce處理，處理結果被儲存在hdfs，然後通知』消費者『(例如：voldemart)通過合適的方式來獲取這些資料並切換索引來保證能獲取到最新的資料。
voldemart，乙個key-value儲存系統，為系統中的唯讀頁面提供服務。voldemart的資料**於hadoop框架(hadoop azkaban：編排hadoop map-reduce任務的執行計畫)。這就是近線系統，它們從類似hadoop的離線系統獲取資料。下面這些頁面的資料都是來自於voldemart：
你可能認識的人
看過本頁面的人還在看
你可能感興趣的工作
你可能感興趣的事件
下面是幾種不同的索引，這些索引由databus-乙個變化資料捕捉系統-來更新的：
供seas(search-as-a-service)使用的』成員搜尋索引『。當你在linkedin上搜尋不同的成員時，這些資料就是來自於搜尋索引。通常這個功能對招聘人員的幫助很大。
社交圖索引幫助在人們的人脈關係中顯示成員以及關係。通過這個索引使用者幾乎可以實時的得到網路關係的變化。
通過讀複製集獲取到的成員資料資料。這些資料會被』標準化服務『訪問。讀複製集是對源資料庫的複製，這樣能使源資料庫的更新同步到這些複製集上面。增加讀複製集的最主要原因是能夠通過將讀操查詢分散到讀複製集上來減輕源資料庫(執行使用者發起的寫操作)的壓力。
下圖展示了資料變化捕獲事件是如何利用databus更新到近線系統的：
將更新寫入oracle master資料庫
將資料變更，如最新技能和職位資訊，更新到標準化服務。
將上面提到的變更更新到搜尋索引服務。
將關係變更更新到圖索引服務。
資料庫讀寫分離：你應當計畫兩種資料庫，一種用來執行寫操作的可以稱為「可信源」系統，另一種執行讀操作的可以稱為派生資料庫系統。這裡的經驗法則就是將由使用者發起的寫操作和使用者讀操作使用的資料庫區分開來。
派生資料庫系統：使用者的讀操作應該被分配到派生資料庫或者讀複製集上去。而派生資料庫系統則可以建立在下面的系統之上：
nosql資料儲存，例如：voldemart、redis、cassandra、mongodb等。
對於使用者的讀操作，應該盡量從主可信源資料庫系統建立索引或者基於key-value的資料(**於hadoop map-reduce之類的系統)，並且將每次由使用者發起的被寫入主可信源系統的變更一併更新到這些索引或派生資料(key-value)。
建立派生資料時，你可以針對主資料集或者變更資料集執行基於hadoop的map-reduce任務，然後更新hdfs並且通知派生資料儲存系統(類似voldemart的nosql儲存)來取走資料。
對於資料一致性來說，你可以以將這些資料儲存庫建立為分布式系統，集群中的每個節點又都包含主從節點。所有節點都可以建立水平擴充套件的資料shards。
為了保證這些分布式資料儲存系統正常執行時間最大化，你可以使用像apache helix這一類的集群管理工具。
處理機的排程
描述 fcfs是最簡單的排程演算法，該演算法可用於作業排程，也可用於程序排程，當在作業排程中採用該演算法時，系統將按照作業到達的先後次序進行排程，或者說優先考慮在系統中等待時間最長的作業，而不管作業需要執行時間的長短，從後背作業佇列中選擇幾個最先進入該佇列的作業，將他們調入記憶體，為他們分配資源和建...
處理機的狀態
處理器總處於以下三種狀態之一 核心態，執行於程序上下文，核心代表程序執行於核心空間 核心態，執行於中斷上下文，核心代表硬體執行於核心空間 使用者態，執行於使用者空間。程序上下文 當使用者的應用程式通過系統呼叫進入核心，使用者空間的程序要傳遞很多變數和引數的值給核心 核心態執行的時候要儲存一些暫存器值...
Sigslot WebRTC中的事件處理機制
sigslot 是sarah thompson 設計實現的c 事件處理的框架,這套框架非常輕量級,全部 只有乙個sigslot.h 檔案,其設計也非常出色,最大限度的將事件和處理機制解耦,並且保證了執行緒安全.在webrtc中,sigslot 是其基礎的事件處理框架,在多個模組的訊息通知,響應處理中...