1. 自我介紹
2. 介紹項目
3. 爲什麼選用這個
4. Avro的數據存儲框架是什麼
5. 做項目的過程遇到的難題？
6. kafka的 partition
http://www.cnblogs.com/haoxinyue/p/5743775.html
7. 爲什麼線程池大小是CPU的兩倍
8. 你們的項目用的哪一個mysql引擎，爲什麼？
9. mysql的死鎖
http://www.cnblogs.com/zejin2008/p/5262751.html
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低,併發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般
所謂死鎖: 是指兩個或兩個以上的進程在執行過程中,
因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去.
此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等竺的進程稱爲死鎖進程.
表級鎖不會產生死鎖.所以解決死鎖主要還是針對於最常用的InnoDB.
死鎖的關鍵在於：兩個(或以上)的Session加鎖的順序不一致。
那麼對應的解決死鎖問題的關鍵就是：讓不同的session加鎖有次序
案例一：
需求：將投資的錢拆成幾份隨機分配給借款人。
起初業務程序思路是這樣的：
投資人投資後，將金額隨機分爲幾份，然後隨機從借款人表裏面選幾個，然後通過一條條select for update 去更新借款人表裏面的餘額等。
抽象出來就是一個session通過for循環會有幾條如下的語句：
Select * from xxx where id=’隨機id’ for update
基本來說，程序開啓後不一會就死鎖。
這可以是說最經典的死鎖情形了。
例如兩個用戶同時投資，A用戶金額隨機分爲2份，分給借款人1，2
B用戶金額隨機分爲2份，分給借款人2，1
由於加鎖的順序不一樣，死鎖當然很快就出現了。
對於這個問題的改進很簡單，直接把所有分配到的借款人直接一次鎖住就行了。
Select * from xxx where id in (xx,xx,xx) for update
在in裏面的列表值mysql是會自動從小到大排序，加鎖也是一條條從小到大加的鎖10. 如何做sql的優化操作
http://blog.163.com/double_dimple/blog/static/11613323520123114104776/
http://database.51cto.com/art/200904/118526.htm
對查詢進行優化，應儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
應儘量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0應儘量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
應儘量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
11. 如何實現一個非阻塞io，NIO
http://blog.csdn.net/wangyangzhizhou/article/details/50205291
由一個專門的線程來處理所有的 IO 事件，並負責分發
事件驅動機制：事件到的時候觸發，而不是同步的去監視事件。
線程通訊：線程之間通過 wait,notify
等方式通訊。保證每次上下文切換都是有意義的。減少無謂的線程切換。
一共有以下四種事件：
服務端接收客戶端連接事件 SelectionKey.OP_ACCEPT(16)
客戶端連接服務端事件 SelectionKey.OP_CONNECT(8)
讀事件 SelectionKey.OP_READ(1)
寫事件 SelectionKey.OP_WRITE(4)
服務端和客戶端各自維護一個管理通道的對象，我們稱之爲selector，該對象能檢測一個或多個通道 (channel) 上的事件。我們以服務端爲例，如果服務端的selector上註冊了讀事件，某時刻客戶端給服務端發送了一些數據，阻塞I/O這時會調用read()方法阻塞地讀取數據，而NIO的服務端會在selector中添加一個讀事件。服務端的處理線程會輪詢地訪問selector，如果訪問selector時發現有感興趣的事件到達，則處理這些事件，如果沒有感興趣的事件到達，則處理線程會一直阻塞直到感興趣的事件到達爲止。
12. 垃圾回收機制
13. 一個臨時變量會在內存裏面怎麼保存
14. 如何獲取另一個線程的變量
http://blog.csdn.net/xorxos/article/details/46994013
管道、回調、輪詢
輪詢
public class ReturnThreadInfo extends Thread {
private String str;
public ReturnThreadInfo() {
this.str = "Hello";
}
public void run(){
this.str = "Hello World!";
}
public String getThreadInfo(){
return this.str;
}
}
public class Main{
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
ReturnThreadInfo returnThreadInfo = new ReturnThreadInfo();
returnThreadInfo.start(); //創建並啓動ReturnThreadInfo線程
while(true){
String str = returnThreadInfo.getThreadInfo();
if(!str.equals("Hello")){
System.out.println(returnThreadInfo.getThreadInfo());
break;
}
}
}
} 回調
public class ReturnThreadInfo extends Thread {
private String str;
public ReturnThreadInfo() {
this.str = "Hello";
}
public void run(){
this.str = "Hello World!";
Main.receiveStr(str); //回調receiveStr方法
}
}
public class Main{
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
// TODO code application logic here
ReturnThreadInfo returnThreadInfo = new ReturnThreadInfo();
returnThreadInfo.start();
}
public static void receiveStr(String str){
System.out.println(str);
}
}