無處不在的C/S架構(gòu)
在這個充斥著云的時代,我們使用的軟件可以說99%都是C/S架構(gòu)的！
- 你發(fā)郵件用的Outlook,Foxmail等
- 你看視頻用的優(yōu)酷，土豆等
- 你寫文檔用的Office365,googleDoc，Evernote等
- 你瀏覽網(wǎng)頁用的IE,Chrome等(B/S是特殊的C/S)
- ......
C/S架構(gòu)的軟件帶來的一個明顯的好處就是：只要有網(wǎng)絡(luò)，你可以在任何地方干同一件事。
例如：你在家里使用Office365編寫了文檔。到了公司，只要打開編輯地址就可以看到在家里編寫的文檔，進(jìn)行展示或者繼續(xù)編輯。甚至在手機(jī)上進(jìn)行閱讀與編輯。不再需要U盤拷來拷去了。
C/S架構(gòu)可以抽象為如下模型：
- C就是Client(客戶端),上面的B是Browser(瀏覽器)
- S就是Server(服務(wù)器)：服務(wù)器管理某種資源，并且通過操作這種資源來為它的客戶端提供某種服務(wù)
C/S架構(gòu)之所以能夠流行的一個主要原因就是網(wǎng)速的提高以及費(fèi)用的降低，特別是無線網(wǎng)絡(luò)速度的提高。試想在2G時代，大家最多就是看看文字網(wǎng)頁，小說什么的。看圖片，那簡直就是奢侈！更別說看視頻了！
網(wǎng)速的提高，使得越來越多的人使用網(wǎng)絡(luò)，例如：優(yōu)酷，微信都是上億用戶量，更別說天貓雙11的瞬間訪問量了！這就對服務(wù)器有很高的要求！能夠快速處理海量的用戶請求！那服務(wù)器如何能快速的處理用戶的請求呢？
高性能服務(wù)器
高性能服務(wù)器至少要滿足如下幾個需求：
- 效率高：既然是高性能，那處理客戶端請求的效率當(dāng)然要很高了
- 高可用：不能隨便就掛掉了
- 編程簡單：基于此服務(wù)器進(jìn)行業(yè)務(wù)開發(fā)需要足夠簡單
- 可擴(kuò)展：可方便的擴(kuò)展功能
- 可伸縮：可簡單的通過部署的方式進(jìn)行容量的伸縮，也就是服務(wù)需要無狀態(tài)
而滿足如上需求的一個基礎(chǔ)就是高性能的IO!
Socket
無論你是發(fā)郵件，瀏覽網(wǎng)頁，還是看視頻～實(shí)際底層都是使用的TCP/IP，而TCP/IP的編程抽象就是Socket!
我一直對Socket的中文翻譯很困惑，個人覺得是我所接觸的技術(shù)名詞翻譯里最莫名其妙的，沒有之一！
Socket中文翻譯為"套接字"！什么鬼？在很長的時間里我都無法將其和網(wǎng)絡(luò)編程關(guān)聯(lián)上！后來專門找了一些資料，最后在知乎上找到了一個還算滿意的答案(具體鏈接，請見文末的參考資料鏈接)！
Socket的原意是插口，想表達(dá)的意思是插口與插槽的關(guān)系！"send socket"插到"receive socket"里，建立了鏈接，然后就可以通信了！
套接字的翻譯，應(yīng)該是參考了套接管(如下圖)！從這個層面上來看，是有那么點(diǎn)意思！
套接字這個翻譯已經(jīng)是標(biāo)準(zhǔn)了，不糾結(jié)這個了！
我們看一下Socket之間建立鏈接及通信的過程！實(shí)際上就是對TCP/IP連接與通信過程的抽象:
- 服務(wù)端Socket會bind到指定的端口上，Listen客戶端的"插入"
- 客戶端Socket會Connect到服務(wù)端
- 當(dāng)服務(wù)端Accept到客戶端連接后
- 就可以進(jìn)行發(fā)送與接收消息了
- 通信完成后即可Close
對于IO來說，我們聽得比較多的是:
- BIO:阻塞IO
- NIO:非阻塞IO
- 同步IO
- 異步IO
以及其組合:
- 同步阻塞IO
- 同步非阻塞IO
- 異步阻塞IO
- 異步非阻塞IO
那么什么是阻塞IO、非阻塞IO、同步IO、異步IO呢？
- 一個IO操作其實(shí)分成了兩個步驟：發(fā)起IO請求和實(shí)際的IO操作
- 阻塞IO和非阻塞IO的區(qū)別在于第一步：發(fā)起IO請求是否會被阻塞，如果阻塞直到完成那么就是傳統(tǒng)的阻塞IO;如果不阻塞，那么就是非阻塞IO
- 同步IO和異步IO的區(qū)別就在于第二個步驟是否阻塞，如果實(shí)際的IO讀寫阻塞請求進(jìn)程，那么就是同步IO，因此阻塞IO、非阻塞IO、IO復(fù)用、信號驅(qū)動IO都是同步IO;如果不阻塞，而是操作系統(tǒng)幫你做完IO操作再將結(jié)果返回給你，那么就是異步IO
舉個不太恰當(dāng)?shù)睦?：比如你家網(wǎng)絡(luò)斷了，你打電話去中國電信報修！
- 你撥號---客戶端連接服務(wù)器
- 電話通了---連接建立
- 你說：“我家網(wǎng)斷了,幫我修下”---發(fā)送消息
- 說完你就在那里等，那么就是阻塞IO
- 如果正好你有事，你放下帶電話，然后處理其他事情了，過一會你來問下，修好了沒---那就是非阻塞IO
- 如果客服說：“馬上幫你處理，你稍等”---同步IO
- 如果客服說：“馬上幫你處理，好了通知你”，然后掛了電話---異步IO
本文只討論BIO和NIO,AIO使用度沒有前兩者普及，暫不討論！
下面從代碼層面看看BIO與NIO的流程!
BIO
- 客戶端代碼
//Bind,Connect
Socket client = new Socket("127.0.0.1",7777);
//讀寫
PrintWriter pw = new PrintWriter(client.getOutputStream());
BufferedReader br=
new BufferedReader(new InputStreamReader(System.in));
pw.write(br.readLine());
//Close
pw.close();
br.close();
- 服務(wù)端代碼
Socket socket;
//Bind,Listen
ServerSocket ss = new ServerSocket(7777);
while (true) {
//Accept
socket = ss.accept();
//一般新建一個線程執(zhí)行讀寫
BufferedReader br = new BufferedReader(
new InputStreamReader(socket .getInputStream()));
System.out.println("you input is : " + br.readLine());
}
- 上面的代碼可以說是學(xué)習(xí)Java的Socket的入門級代碼了
- 代碼流程和前面的圖可以一一對上
模型圖如下所示：
BIO優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
- 模型簡單
- 編碼簡單
- 缺點(diǎn)
- 性能瓶頸低
優(yōu)缺點(diǎn)很明顯。這里主要說下缺點(diǎn)：主要瓶頸在線程上。每個連接都會建立一個線程。雖然線程消耗比進(jìn)程小，但是一臺機(jī)器實(shí)際上能建立的有效線程有限，以Java來說，1.5以后，一個線程大致消耗1M內(nèi)存！且隨著線程數(shù)量的增加，CPU切換線程上下文的消耗也隨之增加，在高過某個閥值后，繼續(xù)增加線程，性能不增反降！而同樣因?yàn)橐粋€連接就新建一個線程，所以編碼模型很簡單！
就性能瓶頸這一點(diǎn)，就確定了BIO并不適合進(jìn)行高性能服務(wù)器的開發(fā)！像Tomcat這樣的Web服務(wù)器，從7開始就從BIO改成了NIO，來提高服務(wù)器性能！
NIO
- NIO客戶端代碼(連接)
//獲取socket通道
SocketChannel channel = SocketChannel.open();
channel.configureBlocking(false);
//獲得通道管理器
selector=Selector.open();
channel.connect(new InetSocketAddress(serverIp, port));
//為該通道注冊SelectionKey.OP_CONNECT事件
channel.register(selector, SelectionKey.OP_CONNECT);
- NIO客戶端代碼(監(jiān)聽)
while(true){
//選擇注冊過的io操作的事件(第一次為SelectionKey.OP_CONNECT)
selector.select();
while(SelectionKey key : selector.selectedKeys()){
if(key.isConnectable()){
SocketChannel channel=(SocketChannel)key.channel();
if(channel.isConnectionPending()){
channel.finishConnect();//如果正在連接，則完成連接
}
channel.register(selector, SelectionKey.OP_READ);
}else if(key.isReadable()){ //有可讀數(shù)據(jù)事件。
SocketChannel channel = (SocketChannel)key.channel();
ByteBuffer buffer = ByteBuffer.allocate(10);
channel.read(buffer);
byte[] data = buffer.array();
String message = new String(data);
System.out.println("recevie message from server:, size:"
+ buffer.position() + " msg: " + message);
}
}
}
- NIO服務(wù)端代碼(連接)
//獲取一個ServerSocket通道
ServerSocketChannel serverChannel = ServerSocketChannel.open();
serverChannel.configureBlocking(false);
serverChannel.socket().bind(new InetSocketAddress(port));
//獲取通道管理器
selector = Selector.open();
//將通道管理器與通道綁定，并為該通道注冊SelectionKey.OP_ACCEPT事件，
serverChannel.register(selector, SelectionKey.OP_ACCEPT);
- NIO服務(wù)端代碼(監(jiān)聽)
while(true){
//當(dāng)有注冊的事件到達(dá)時，方法返回，否則阻塞。
selector.select();
for(SelectionKey key : selector.selectedKeys()){
if(key.isAcceptable()){
ServerSocketChannel server =
(ServerSocketChannel)key.channel();
SocketChannel channel = server.accept();
channel.write(ByteBuffer.wrap(
new String("send message to client").getBytes()));
//在與客戶端連接成功后，為客戶端通道注冊SelectionKey.OP_READ事件。
channel.register(selector, SelectionKey.OP_READ);
}else if(key.isReadable()){//有可讀數(shù)據(jù)事件
SocketChannel channel = (SocketChannel)key.channel();
ByteBuffer buffer = ByteBuffer.allocate(10);
int read = channel.read(buffer);
byte[] data = buffer.array();
String message = new String(data);
System.out.println("receive message from client, size:"
+ buffer.position() + " msg: " + message);
}
}
}
NIO模型示例如下：
- Acceptor注冊Selector，監(jiān)聽accept事件
- 當(dāng)客戶端連接后，觸發(fā)accept事件
- 服務(wù)器構(gòu)建對應(yīng)的Channel，并在其上注冊Selector，監(jiān)聽讀寫事件
- 當(dāng)發(fā)生讀寫事件后，進(jìn)行相應(yīng)的讀寫處理
NIO優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
- 性能瓶頸高
- 缺點(diǎn)
- 模型復(fù)雜
- 編碼復(fù)雜
- 需處理半包問題
NIO的優(yōu)缺點(diǎn)和BIO就完全相反了!性能高，不用一個連接就建一個線程，可以一個線程處理所有的連接！相應(yīng)的，編碼就復(fù)雜很多，從上面的代碼就可以明顯體會到了。還有一個問題，由于是非阻塞的，應(yīng)用無法知道什么時候消息讀完了，就存在了半包問題！
半包問題
簡單看一下下面的圖就能理解半包問題了！
我們知道TCP/IP在發(fā)送消息的時候，可能會拆包(如上圖1)！這就導(dǎo)致接收端無法知道什么時候收到的數(shù)據(jù)是一個完整的數(shù)據(jù)。例如:發(fā)送端分別發(fā)送了ABC,DEF,GHI三條信息，發(fā)送時被拆成了AB,CDRFG,H,I這四個包進(jìn)行發(fā)送，接受端如何將其進(jìn)行還原呢？在BIO模型中，當(dāng)讀不到數(shù)據(jù)后會阻塞，而NIO中不會!所以需要自行進(jìn)行處理!例如，以換行符作為判斷依據(jù)，或者定長消息發(fā)生，或者自定義協(xié)議！
NIO雖然性能高，但是編碼復(fù)雜，且需要處理半包問題！為了方便的進(jìn)行NIO開發(fā)，就有了Reactor模型!
Reactor模型
- AWT Events
Reactor模型和AWT事件模型很像，就是將消息放到了一個隊(duì)列中，通過異步線程池對其進(jìn)行消費(fèi)！
Reactor中的組件
- Reactor:Reactor是IO事件的派發(fā)者。
- Acceptor:Acceptor接受client連接，建立對應(yīng)client的Handler，并向Reactor注冊此Handler。
- Handler:和一個client通訊的實(shí)體，按這樣的過程實(shí)現(xiàn)業(yè)務(wù)的處理。一般在基本的Handler基礎(chǔ)上還會有更進(jìn)一步的層次劃分， 用來抽象諸如decode，process和encoder這些過程。比如對Web Server而言，decode通常是HTTP請求的解析， process的過程會進(jìn)一步涉及到Listener和Servlet的調(diào)用。業(yè)務(wù)邏輯的處理在Reactor模式里被分散的IO事件所打破， 所以Handler需要有適當(dāng)?shù)臋C(jī)制在所需的信息還不全（讀到一半）的時候保存上下文，并在下一次IO事件到來的時候（另一半可讀了）能繼續(xù)中斷的處理。為了簡化設(shè)計(jì)，Handler通常被設(shè)計(jì)成狀態(tài)機(jī)，按GoF的state pattern來實(shí)現(xiàn)。
對應(yīng)上面的NIO代碼來看:
- Reactor：相當(dāng)于有分發(fā)功能的Selector
- Acceptor：NIO中建立連接的那個判斷分支
- Handler：消息讀寫處理等操作類
Reactor從線程池和Reactor的選擇上可以細(xì)分為如下幾種：
Reactor單線程模型
這個模型和上面的NIO流程很類似，只是將消息相關(guān)處理獨(dú)立到了Handler中去了！
雖然上面說到NIO一個線程就可以支持所有的IO處理。但是瓶頸也是顯而易見的！我們看一個客戶端的情況，如果這個客戶端多次進(jìn)行請求，如果在Handler中的處理速度較慢，那么后續(xù)的客戶端請求都會被積壓，導(dǎo)致響應(yīng)變慢！所以引入了Reactor多線程模型!
Reactor多線程模型
Reactor多線程模型就是將Handler中的IO操作和非IO操作分開，操作IO的線程稱為IO線程，非IO操作的線程稱為工作線程!這樣的話，客戶端的請求會直接被丟到線程池中，客戶端發(fā)送請求就不會堵塞！
但是當(dāng)用戶進(jìn)一步增加的時候，Reactor會出現(xiàn)瓶頸！因?yàn)镽eactor既要處理IO操作請求，又要響應(yīng)連接請求！為了分擔(dān)Reactor的負(fù)擔(dān)，所以引入了主從Reactor模型!
主從Reactor模型
主Reactor用于響應(yīng)連接請求，從Reactor用于處理IO操作請求！
Netty
Netty是一個高性能NIO框架，其是對Reactor模型的一個實(shí)現(xiàn)！
- Netty客戶端代碼
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
Bootstrap b = new Bootstrap();
b.group(workerGroup);
b.channel(NioSocketChannel.class);
b.option(ChannelOption.SO_KEEPALIVE, true);
b.handler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new TimeClientHandler());
}
});
ChannelFuture f = b.connect(host, port).sync();
f.channel().closeFuture().sync();
} finally {
workerGroup.shutdownGracefully();
}
- Netty Client Handler
public class TimeClientHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf m = (ByteBuf) msg;
try {
long currentTimeMillis =
(m.readUnsignedInt() - 2208988800L) * 1000L;
System.out.println(new Date(currentTimeMillis));
ctx.close();
} finally {
m.release();
}
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx,
Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
- Netty服務(wù)端代碼
EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new TimeServerHandler());
}
})
.option(ChannelOption.SO_BACKLOG, 128)
.childOption(ChannelOption.SO_KEEPALIVE, true);
// Bind and start to accept incoming connections.
ChannelFuture f = b.bind(port).sync();
f.channel().closeFuture().sync();
} finally {
workerGroup.shutdownGracefully();
bossGroup.shutdownGracefully();
}
- Netty Server Handler
public class TimeServerHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelActive(final ChannelHandlerContext ctx) {
final ByteBuf time = ctx.alloc().buffer(4);
time.writeInt((int)
(System.currentTimeMillis() / 1000L + 2208988800L));
final ChannelFuture f = ctx.writeAndFlush(time);
f.addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) {
assert f == future;
ctx.close();
}
});
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx,
Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
我們從Netty服務(wù)器代碼來看，與Reactor模型進(jìn)行對應(yīng)！
- EventLoopGroup就相當(dāng)于是Reactor，bossGroup對應(yīng)主Reactor,workerGroup對應(yīng)從Reactor
- TimeServerHandler就是Handler
- child開頭的方法配置的是客戶端channel，非child開頭的方法配置的是服務(wù)端channel
具體Netty內(nèi)容，請?jiān)L問Netty官網(wǎng)！
Netty的問題
Netty開發(fā)中一個很明顯的問題就是回調(diào)，一是打破了線性編碼習(xí)慣，
二就是Callback Hell！
看下面這個例子：
a.doing1(); //1
a.doing2(); //2
a.doing3(); //3
1,2,3處代碼如果是同步的，那么將按順序執(zhí)行！但是如果不是同步的呢？我還是希望2在1之后執(zhí)行，3在2之后執(zhí)行！怎么辦呢？想想AJAX!我們需要寫類似如下這樣的代碼！
a.doing1(new Callback(){
public void callback(){
a.doing2(new Callback(){
public void callback(){
a.doing3();
}
})
}
});
那有沒有辦法解決這個問題呢？其實(shí)不難，實(shí)現(xiàn)一個類似Future的功能！當(dāng)Client獲取結(jié)果時，進(jìn)行阻塞，當(dāng)?shù)玫浇Y(jié)果后再繼續(xù)往下走！實(shí)現(xiàn)方案，一個就是使用鎖了，還有一個就是使用RingBuffer。經(jīng)測試，使用RingBuffer比使用鎖TPS有2000左右的提高！
