億方雲面試經驗(後臺開發工程師實習)

一、寫單例模式( C++ java Python)

class Singletonjava

{正則表達式

public:算法

static Singleton &Instance(){                            //1數據庫

if( !m_pInstatnce){ //2後端

Lock(m_mutex) //3數組

If( !m_pInstance ) //4緩存

m_pInstance = new Singleton;//5服務器

UnLock(m_mutex); //6網絡

}數據結構

return *m_pInstance; //7

}

private:

static volatitle Singleton *m_pInstatnce;            //8

private:

Singleton();                                                         //9

Singleton(const Singleton&);                             //10

Singleton& operator=(const Singleton&);            //11

~Singleton();                                                       //12

}

Singleton *Singleton:m_pInstatnce = NULL; //13


 
二、Hbase 和其餘 NoSQL相比 有什麼優點
 

一、 可拓展性 :能夠以最小的代價、無須停機的方式增長存儲系統的容量。一些狀況下咱們須要快速增長系統的容量,而且可以自動負載、利用到這些新的硬件設備。

二、 高寫入吞吐量 :大多數應用都須要存儲巨大量的數據,這就要求很高的寫入吞吐量。

三、 單個data center內高性能、低延遲的強一致性 :一些重要的應用、好比消息、要求很強的單個數據中心內的一致性,這些需求很直觀來自於用戶需求,好比展現在主頁的「未讀消息」的數目和inbox頁面顯示的消息就應當是高度一致的。儘管全局強一致性的分佈式系統幾乎是不可能的,可是一個系統至少可以提供在單個數據中心內的強一致性,這可以帶來很好的用戶體驗。

四、 高效的隨機讀取性能 :儘管應用層的緩存技術(無論是嵌入式的仍是memcached方式)被普遍應用,可是不少訪問仍然沒辦法命中緩存,須要後端的存儲系統來處理,Hbase隨機讀取性能很穩定。MySQL在隨機讀取方面很是優秀,但若是Hbase結合分佈式緩存MemeCached或者MemBase,那麼其讀取性能就能夠和MySQL比肩了。

五、 高可用性以及災難恢復 :咱們須要提供給用戶高度可用的服務,無論是遇到計劃中的事件(好比軟件升級、或者硬件/容量的增長),仍是遇到一些計劃以外的事件(好比硬件失效)。咱們也須要可以允許數據中心的一些數據丟失,可以在合理的時間範圍內切換到其餘數據中心來爲用戶提供服務。

六、 故障隔離 :咱們在大量的MySQL數據庫上的應用經驗代表,故障隔離是很是關鍵的。單個數據庫能夠down掉,可是僅只有很小一部分用戶會被這樣的事件影響。相似地,在咱們的Hadoop存儲中,單個磁盤故障僅只會影響到一小部分數據,並且系統能夠很快恢復。

七、 原子的「讀-修改-寫」原語 :原子的計數器和檢查並設置(checkand set、或者稱compare and swap)等API在構建無鎖的併發應用時很是有用,能夠幫助用戶有效地解決多線程競爭形成的不少問題。

八、 範圍掃描 :一些應用要求特定範圍內的行的集合的高效檢索。例如,給定用戶的最近100條消息的檢索。

 

 

 

 

 

一、 可拓展性

雖然全部NoSQL數據庫都承諾可拓展性,可是面對挑戰是水平卻不盡相同。

BigTable的類似產品Hbase和Hypertable暫時處於領先地位,內存存儲(Membase或Redis)和文檔數據庫(MongDB或CouchBase)緊隨其後,他們之間的差別隨着數據量的增大而被無限放大,特別是到了PB級之後。

拓展性方面Hbase具有天生的優點,支持自動負載均衡,故障轉移,壓縮和單服務器多分片,並且Hbase和HDFS配合的很是好,HDFS可以經過複製和自動平衡輕鬆容納跨越多個服務器的大文件。

因此所若是須要極端拓展性的話,列族NoSQL是最好的選擇。

可是話又說回來,若是你的大量數據會以驚人的快節奏出現,例如一些實時的交易數據或者廣告點擊追蹤數據,那麼單靠列式存儲沒法提供完美的解決方案。這個時候你須要一些更加輕快、既支持快速讀寫、又支持實時處理的存儲,沒有什麼比在內存裏面處理數據更快了,因此你能夠在Hbase前面搭配上MongDB/Redis來進行實時數據處理以及實時的數據挖掘等。其餘一些實時性不是很是高的批量查詢和數據挖掘能夠利用Mapreduce在Hbase上進行。

 

二、 事務完整性和一致性

Hbase和Hypertable提供行級的原子更新以及一致性狀態,MongDB提供文檔級別的原子更新,Cassandra只能提供最終一致性。

可是事務的要求並非必須的,許多數據,好比網絡流量日誌,社交網絡狀態更新(微博等),廣告點擊,道路交通數據,交易數據和遊戲分數等是一次寫、屢次讀,這樣的數據對事務的需求有限,甚至沒有。

有些數據雖然已更新和刪除,可是修改一般只限於單記錄而非數據集的某個範圍,有時更新很是頻繁且涉及範圍操做。若是範圍操做很常見而且須要保持更新的一致性,那麼RDBMS纔是最佳選擇,若是單個條目的原子性已經足夠,那麼列式數據庫、文檔數據庫和部分鍵/值存儲均可以。若是須要事務完整性可是能夠容納暫時的窗口不一致,那麼最終一致性存儲也是不錯的選擇。

 

三、 數據模型

MongDB支持類SQL查詢、基本的關係型引用和數據庫對象,若是使用NoSQL的主要緣由是可使用寬鬆的數據結構,那麼MongDB確定是開始使用NOSQL的最佳選擇。

不少Web爲中心的業務都開始使用MongDB,主要是由於它支持靈活的數據模型(弱Schema),同時可以提供快速的讀寫能力。(如今敏捷開發很重要、MongoDB能更快地開發應用程序。一個明顯的緣由是MongoDB沒有固定的Schema,全部花在提交、溝通和實施Schema變動的時間都省下來了)

此外MongDB對Web框架的支持很是好,好比Spring、Rails等。

最後要說明的是,MongDb很是容易上手,學習週期很短。

 

四、 查詢支持

挑選NoSQL主要考慮的因素除了存儲,還有查詢。

MongDB和Redis的查詢能力比較強。

像MongDB的查詢,與SQL類似,語法簡單,容易學習。MongoDB支持範圍查詢,正則表達式查詢,對子文檔內屬性的查詢,能夠取代原來大多數任務的SQL查詢。

像Redis的查詢,查詢方法很全,命令文檔也很豐富。

Hbase只支持基於Rowkey的單條記錄查找、基於Rowkey的範圍查找以及全表掃描。

要注意的是幾乎全部NoSQL存儲都不支持表之間的join操做。

提到查詢不得不提到索引,MongDB自己支持二級索引,Hbase不支持二級索引,可是如今也有不少方法(最多見是藉助協處理器)能夠幫助Hbase實時創建二級索引。

 

五、 性能

(1)    50/50讀和更新、即讀少寫多。

Cassandra最優秀,每秒執行超過1W次操做,平均讀延遲只有25ms、更新性能更好只有10ms。

Hbase緊隨其後。至於MySQL,每秒執行4000左右操做的時候才和上面兩個有可比性,超過5000以後延遲迅速攀升。

(2)    95/5讀和更新、即讀多寫少。

仍是Cassandra最優秀。

列式存儲連續範圍的讀取性能很是優秀,這證實和Hbase批量讀寫的性能很是好。

Hbase表現很是穩定,與每秒操做數無關,5%的更新在Hbase裏面幾乎沒有延遲。

只讀狀況下MySQL性能最好,可能與緩存有關。

若是結合分佈式緩存MemeCached或者MemBase,那麼Hbase的讀取性能就能夠和MySQL比肩了。


 


三、心跳機制
 
網絡中的接收和發送數據都是使用操做系統中的SOCKET進行實現。可是若是此 套接字已經斷開,那發送數據和接收數據的時候就必定會有問題。但是如何判斷這個套接字是否還可使用呢?這個就須要在系統中建立心跳機制。其實TCP中已經爲咱們實現了一個叫作心跳的機制。若是你設置了心跳,那TCP就會在必定的時間(好比你設置的是3秒鐘)內發送你設置的次數的心跳(好比說2次),而且此信息不會影響你本身定義的協議。所謂「心跳」就是定時發送一個自定義的結構體( 心跳包或心跳幀),讓對方知道本身「在線」。 以確保連接的有效性。
所謂的心跳包就是客戶端定時發送簡單的信息給服務器端告訴它我還在而已。代碼就是每隔幾分鐘發送一個固定信息給服務端,服務端收到後回覆一個固定信息若是服務端幾分鐘內沒有收到客戶端信息則視客戶端斷開。好比有些通訊軟件長時間不使用,要想知道它的狀態是在線仍是離線就須要心跳包,定時發包收包。發包方:能夠是客戶也能夠是服務端,看哪邊實現方便合理。通常是客戶端。服務器也能夠定時輪詢發心跳下去。 心跳包之因此叫心跳包是由於:它像心跳同樣每隔固定時間發一次,以此來告訴服務器,這個客戶端還活着。事實上這是爲了保持 長鏈接,至於這個包的內容,是沒有什麼特別規定的,不過通常都是很小的包,或者只包含包頭的一個空包。

 
四、鏈表,每一個節點有指向下一個節點的指針,還有一個額外的指針(指向其餘節點、該節點、NULL),如何深拷貝(不能創建額外的數據結構)?
 
拷貝pNext指針很是容易,因此題目的難點是如何拷貝pRand指針。
假設原來鏈表爲A1 -> A2 ->... -> An,新拷貝鏈表是B1 -> B2 ->...-> Bn。
爲了可以快速的找到pRand指向的節點,並把對應的關係拷貝到B中。咱們能夠將兩個鏈表合併成
A1 -> B1 -> A2 -> B2 -> ... -> An -> Bn。
從A1節點出發,很容易找到A1的pRand指向的節點Ax,而後也就找到了Bx,將B1的pRand指向Bx也就完成了B1節點pRand的拷貝。依次類推。

當全部節點的pRand都拷貝完成後,再將合併鏈表分紅兩個鏈表就能夠了。


 
五、int數組,有一個數值個數超過數組大小的一半,求這個數?(時間:O(n) 、空間: O(1))
 

算法電面:
 
一個二叉樹(包含父節點指針,根節點的父節點指針指向NULL),各個節點編號爲不一樣的正整數,每次從二叉樹中截取一個葉子節點,再隨機從1~100中去一個數K,複製K個該葉子節點,放入數據池中。數據池有一個get()函數,能夠獲取到一個節點並從數據池中刪除該節點,假設get()複雜度爲O(1)。最後,刪除該二叉樹。
問,給你這個數據池,如何從新構造出相同的二叉樹,而且以對映的K爲做爲節點權值,尋找出根節點到葉子節點累積權值最大的路徑。
要求:時間複雜度O(n),空間複雜度O(n),能夠用hash_map
相關文章
相關標籤/搜索