netty壓縮

1. 為什麼要用Netty開發

Netty是由JBOSS提供的基於java NIO的開源框架，Netty提供非同步非阻塞、事件驅動、高性能、高可靠、高可定製性的網路應用程序和工具，可用於開發服務端和客戶端。

JAVA原先是採用的是傳統的BIO，為什麼後來又研發出了NIO呢？

首先看看傳統的基於同步阻塞IO（BIO）的線程模型圖

從圖中我們可以看到，使用JDK原生NIO的不足之處

1.NIO的類庫和API相當復雜，使用它來開發，需要非常熟練地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等

2.需要很多額外的編程技能來輔助使用NIO,例如，因為NIO涉及了Reactor線程模型，所以必須必須對多線程和網路編程非常熟悉才能寫出高質量的NIO程序

3.想要有高可靠性，工作量和難度都非常的大，因為服務端需要面臨客戶端頻繁的接入和斷開、網路閃斷、半包讀寫、失敗緩存、網路阻塞的問題，這些將嚴重影響我們的可靠性，而使用原生NIO解決它們的難度相當大。

4.JDK NIO中著名的BUG--epoll空輪詢，當select返回0時，會導致Selector空輪詢而導致CUP100%，官方表示JDK1.6之後修復了這個問題，其實只是發生的概率降低了，沒有根本上解決。

那麼為什麼要用Netty呢？

1.API使用簡單，更容易上手，開發門檻低

2.功能強大，預置了多種編解碼功能，支持多種主流協議

3.定製能力高，可以通過ChannelHandler對通信框架進行靈活地拓展

4.高性能，與目前多種NIO主流框架相比，Netty綜合性能最高

5.高穩定性，解決了JDK NIO的BUG

6.經歷了大規模的商業應用考驗，質量和可靠性都有很好的驗證。

Netty能提供什麼服務？

1.開發非同步非阻塞的TCP網路應用程序

2.開發非同步非阻塞的UDP網路應用程序

3.開發非同步文件傳輸程序

4.開發非同步HTTP程序的服務端和客戶端

5.提供多種編解碼的集成框架，包括谷歌Protobuf、JBossMarshalling、Java序列化、壓縮編解碼、XML解碼、

字元串編解碼等都可以由用戶直接使用

6.提供形式多樣的編解碼基礎類庫，可以方便地進行私有協議棧編解碼框架的二次開發

7.基於職責鏈的Pipeline-Handler機制，可以方便地對網路事件進行攔截和定製

8.所有的IO操作都是非同步的，用戶可以通過Future-Listeren機制主動get結果或者等IO線程完成操作之後主動Notify來通知，

用戶業務線程不需要同步等待

9.基於鏈路空閑事件監測的心跳機制

10.流量控制和整形

......

2. 大數據適合零基礎學習嗎

零基礎可以學習大數據嗎？答案是可以的。大數據就是升級版的Java，學習大數據一定要有Java基礎。不過如果你是零基礎學習大數據，那麼也可以從Java開始學習，逐漸做到大數據，薪資會更高。
大數據這個行業成為很多小夥伴嚮往的行業，首先我想普及一下什麼叫大數據，大數據顧名思義首先具有的特點是數據量多，指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。

大數據行業薪資高為此吸引了很多的小夥伴，但是零基礎可以學習大數據嗎?零基礎如何學習大數據?針對這點小編首先介紹一下Java和大數據之間的關系，當然有部分小夥伴把大數據稱之為Java大數據。
Java工程師的發展：
初級Java工程師、中級Java工程師、高級Java工程師;而Java大數據工程師以後的發展，相比於Java而言，多了一個大數據的方向，利於想向大數據工程師轉型的學習者。
因為想要成為大數據工程師，需要一定的編程基礎，而Java語言又是現在大數據技術常用的開發語言，所以Java大數據是向大數據學習的奠基課程。

3. 我的世界 伺服器 顯示連接已丟失

伺服器地址換了，或者伺服器關閉了

4. 微服務架構的分布式事務問題如何處理

分布式系統架構中，分布式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分布式事問題日益突出！

下面我們以電商購物支付流程中，在各大參與者系統中可能會遇到分布式事務問題的場景進行詳細的分析！

5. 我看不下去鳥.Java和C#的socket通信真的簡單嗎

C# socket通信組件有很多，在vs 使用nuget搜索socket組件有很多類似的。本人使用的是自己開發的一套組件。

Java socket通信的組件也有很多，常用的大多數都是用的mina或者netty。游戲行業使用也是居多。

關於socket的底層寫法，實在太多，我就不在BB。

這里我想說，C#和C++或者叫VC++把是使用小端序作為位元組序。而java使用的是大端序作為位元組序。

也就是說比如一個int佔用四個位元組，java的位元組序和c#的位元組序是相反的，java的int四個位元組第一個位元組在數組的最後一個。C#是第一個。

也就是說如果java端正常發送一個int的位元組序給C#，需要翻轉一次端緒。反之也是一樣的。一句話來概括的話就是高位在前還是低位在前的問題。

C#輸出數字 int 4 的位元組序。為了保證c#下面絕對是是int所以加入了強制int轉化。默認的話可能是byte

java的默認輸出，這里使用的是netty的默認框架。進行的int4的位元組序輸出

高位和低位表示法完全不同。

java下面如果傳輸字元串，那麼必須要先把字元串轉化成byte數組，然後獲取數組長度，在位元組序裡面壓入int表示的數組長度，然後在然如byte數組。不管你的字元串多長。

而C#也是相同做法。但是唯一不同的是數組的長度表示法不同。微軟經過了位元組壓縮的。用位元組的前7位表示長度。第8位表示下一個位元組是否也是表示長度的位元組，值需要與128位於。

從而減少位元組的消耗。

現在一般如果我們在java和C#中無論是哪一個語言作為伺服器。架設socket通信基準。其中另外一方都要妥協位元組序反轉問題。

大多數情況下我們也許通信的要求不高，或許把一些類或者參數通過json格式化以後傳輸給對方。但是在這一條消息的傳輸中，一般會有兩個int需要位元組序。最少也要一個位元組序。

一個位元組序int表示消息長度。另外一個位元組序表示消息協議。

如果消息協議都放到json裡面沒有問題。但是消息長度是必不可少的。因為你需要知道在網路環境中，消息壓棧，然後等待系統發出是有可能兩條消息一同發送的。也或者消息發送後由於網路阻塞，前後相差好幾秒的消息同一時間達到。

這就是所謂的粘包。

我這里就不表演了。

還有另外一種通信方式，就是通過protobuf進行位元組序的序列化，和反序列，官方支持java，第三方支持C#。這個組件可以減少位元組流。達到省流量，減少網路資源消耗的問題。

例如一個long的類型值是1常規發送需要8個位元組，64位。發送。如果改用protobuf的話只需要1位元組8位就能發送。

同樣的問題，無論你使用哪一種序列化方式，都需要消息長度和消息協議號。

6. 求救，分布式事務怎麼處理

1.性能和時延問題在服務化之前，業務通常都是本地API調用，本地方法調用性能損耗較小。服務化之後，服務提供者和消費者之間採用遠程網路通信，增加了額外的性能損耗：1）客戶端需要對消息進行序列化，主要佔用CPU計算資源。2）序列化時需要創建二進制數組，耗費JVM堆內存或者堆外內存。3）客戶端需要將序列化之後的二進制數組發送給服務端，佔用網路帶寬資源。4）服務端讀取到碼流之後，需要將請求數據報反序列化成請求對象，佔用CPU計算資源。5）服務端通過反射的方式調用服務提供者實現類，反射本身對性能影響就比較大。6）服務端將響應結果序列化，佔用CPU計算資源。7）服務端將應答碼流發送給客戶端，佔用網路帶寬資源。8）客戶端讀取應答碼流，反序列化成響應消息，佔用CPU資源。通過分析我們發現，一個簡單的本地方法調用，切換成遠程服務調用之後，額外增加了很多處理流程，不僅佔用大量的系統資源，同時增加了時延。一些復雜的應用會拆分成多個服務，形成服務調用鏈，如果服務化框架的性能比較差、服務調用時延也比較大，業務服務化之後的性能和時延將無法滿足業務的性能需求。1.1RPC框架高性能設計影響RPC框架性能的主要因素有三個。1）I/O調度模型：同步阻塞I/O（BIO）還是非阻塞I/O（NIO）。2）序列化框架的選擇：文本協議、二進制協議或壓縮二進制協議。3）線程調度模型：串列調度還是並行調度，鎖競爭還是無鎖化演算法。1.I/O調度模型在I/O編程過程中，當需要同時處理多個客戶端接入請求時，可以利用多線程或者I/O多路復用技術進行處理。I/O多路復用技術通過把多個I/O的阻塞復用到同一個select的阻塞上，從而使得系統在單線程的情況下可以同時處理多個客戶端請求。與傳統的多線程/多進程模型比，I/O多路復用的最大優勢是系統開銷小，系統不需要創建新的額外進程或者線程，也不需要維護這些進程和線程的運行，降低了系統的維護工作量，節省了系統資源。JDK1.5_update10版本使用epoll替代了傳統的select/poll，極大地提升了NIO通信的性能，它的工作原理如圖1-1所示。圖1-1非阻塞I/O工作原理Netty是一個開源的高性能NIO通信框架：它的I/O線程NioEventLoop由於聚合了多路復用器Selector，可以同時並發處理成百上千個客戶端Channel。由於讀寫操作都是非阻塞的，這就可以充分提升I/O線程的運行效率，避免由於頻繁I/O阻塞導致的線程掛起。另外，由於Netty採用了非同步通信模式，一個I/O線程可以並發處理N個客戶端連接和讀寫操作，這從根本上解決了傳統同步阻塞I/O一連接一線程模型，架構的性能、彈性伸縮能力和可靠性都得到了極大的提升。Netty被精心設計，提供了很多獨特的性能提升特性，使它做到了在各種NIO框架中性能排名第一，它的性能優化措施總結如下。1）零拷貝：（1）Netty的接收和發送ByteBuffer採用DIRECTBUFFERS，使用堆外直接內存進行Socket讀寫，不需要進行位元組緩沖區的二次拷貝。如果使用傳統的堆內存（HEAPBUFFERS）進行Socket讀寫，JVM會將堆內存Buffer拷貝一份到直接內存中，然後才寫入Socket中。相比於堆外直接內存，消息在發送過程中多了一次緩沖區的內存拷貝。（2）Netty提供了組合Buffer對象，可以聚合多個ByteBuffer對象，用戶可以像操作一個Buffer那樣方便地對組合Buffer進行操作，避免了傳統通過內存拷貝的方式將幾個小Buffer合並成一個大的Buffer。（3）Netty的文件傳輸採用了transferTo方法，它可以直接將文件緩沖區的數據發送到目標Channel，避免了傳統通過循環write方式導致的內存拷貝問題。2）內存池：隨著JVM虛擬機和JIT即時編譯技術的發展，對象的分配和回收是個非常輕量級的工作。但是對於緩沖區Buffer，情況卻稍有不同，特別是對於堆外直接內存的分配和回收，是一件耗時的操作。為了盡量重用緩沖區，Netty提供了基於內存池的緩沖區重用機制。性能測試表明，採用內存池的ByteBuf相比於朝生夕滅的ByteBuf，性能高23倍左右（性能數據與使用場景強相關）。3）無鎖化的串列設計：在大多數場景下，並行多線程處理可以提升系統的並發性能。但是，如果對於共享資源的並發訪問處理不當，會帶來嚴重的鎖競爭，這最終會導致性能的下降。為了盡可能地避免鎖競爭帶來的性能損耗，可以通過串列化設計，即消息的處理盡可能在同一個線程內完成，期間不進行線程切換，這樣就避免了多線程競爭和同步鎖。為了盡可能提升性能，Netty採用了串列無鎖化設計，在I/O線程內部進行串列操作，避免多線程競爭導致的性能下降。表面上看，串列化設計似乎CPU利用率不高，並發程度不夠。但是，通過調整NIO線程池的線程參數，可以同時啟動多個串列化的線程並行運行，這種局部無鎖化的串列線程設計相比一個隊列-多個工作線程模型性能更優。4）高效的並發編程：volatile的大量、正確使用；CAS和原子類的廣泛使用；線程安全容器的使用；通過讀寫鎖提升並發性能。2.高性能序列化框架影響序列化性能的關鍵因素總結如下。1）序列化後的碼流大小（網路帶寬的佔用）。2）序列化&反序列化的性能（CPU資源佔用）。3）是否支持跨語言（異構系統的對接和開發語言切換）。4）並發調用的性能表現：穩定性、線性增長、偶現的時延毛刺等。相比於JSON等文本協議，二進制序列化框架性能更優異，以Java原生序列化和Protobuf二進制序列化為例進行性能測試對比，結果如圖1-2所示。圖1-2序列化性能測試對比數據在序列化框架的技術選型中，如無特殊要求，盡量選擇性能更優的二進制序列化框架，碼流是否壓縮，則需要根據通信內容做靈活選擇，對於圖片、音頻、有大量重復內容的文本文件（例如小說）可以採用碼流壓縮，常用的壓縮演算法包括GZip、Zig-Zag等。3.高性能的Reactor線程模型該模型的特點總結如下。1）有專門一個NIO線程：Acceptor線程用於監聽服務端，接收客戶端的TCP連接請求。2）網路I/O操作：讀、寫等由一個NIO線程池負責，線程池可以採用標準的JDK線程池實現，它包含一個任務隊列和N個可用的線程，由這些NIO線程負責消息的讀取、解碼、編碼和發送。3）1個NIO線程可以同時處理N條鏈路，但是1個鏈路只對應1個NIO線程，防止產生並發操作。由於Reactor模式使用的是非同步非阻塞I/O，所有的I/O操作都不會導致阻塞，理論上一個線程可以獨立處理所有I/O相關的操作，因此在絕大多數場景下，Reactor多線程模型都可以完全滿足業務性能需求。Reactor線程調度模型的工作原理示意如圖1-3所示。圖1-3高性能的Reactor線程調度模型1.2業務最佳實踐要保證高性能，單依靠分布式服務框架是不夠的，還需要應用的配合，應用服務化高性能實踐總結如下：1）能非同步的盡可能使用非同步或者並行服務調用，提升服務的吞吐量，有效降低服務調用時延。2）無論是NIO通信框架的線程池還是後端業務線程池，線程參數的配置必須合理。如果採用JDK默認的線程池，最大線程數建議不超過20個。因為JDK的線程池默認採用N個線程爭用1個同步阻塞隊列方式，當線程數過大時，會導致激烈的鎖競爭，此時性能不僅不會提升，反而會下降。3）盡量減小要傳輸的碼流大小，提升性能。本地調用時，由於在同一塊堆內存中訪問，參數大小對性能沒有任何影響。跨進程通信時，往往傳遞的是個復雜對象，如果明確對方只使用其中的某幾個欄位或者某個對象引用，則不要把整個復雜對象都傳遞過去。舉例，對象A持有8個基本類型的欄位，2個復雜對象B和C。如果明確服務提供者只需要用到A聚合的C對象，則請求參數應該是C，而不是整個對象A。4）設置合適的客戶端超時時間，防止業務高峰期因為服務端響應慢導致業務線程等應答時被阻塞，進而引起後續其他服務的消息在隊列中排隊，造成故障擴散。5）對於重要的服務，可以單獨部署到獨立的服務線程池中，與其他非核心服務做隔離，保障核心服務的高效運行。6）利用Docker等輕量級OS容器部署服務，對服務做物理資源層隔離，避免虛擬化之後導致的超過20%的性能損耗。7）設置合理的服務調度優先順序，並根據線上性能監控數據做實時調整。2.事務一致性問題服務化之前，業務採用本地事務，多個本地SQL調用可以用一個大的事務塊封裝起來，如果某一個資料庫操作發生異常，就可以將之前的SQL操作進行回滾，只有所有SQL操作全部成功，才最終提交，這就保證了事務強一致性，如圖2-1所示。服務化之後，三個資料庫操作可能被拆分到獨立的三個資料庫訪問服務中，此時原來的本地SQL調用演變成了遠程服務調用，事務一致性無法得到保證，如圖2-2所示。圖2-2服務化之後引入分布式事務問題假如服務A和服務B調用成功，則A和B的SQL將會被提交，最後執行服務C，它的SQL操作失敗，對於應用1消費者而言，服務A和服務B的相關SQL操作已經提交，服務C發生了回滾，這就導致事務不一致。從圖2-2可以得知，服務化之後事務不一致主要是由服務分布式部署導致的，因此也被稱為分布式事務問題。2.1分布式事務設計方案通常，分布式事務基於兩階段提交實現，它的工作原理示意圖如圖2-3所示。圖2-3兩階段提交原理圖階段1：全局事務管理器向所有事務參與者發送准備請求；事務參與者向全局事務管理器回復自己是否准備就緒。階段2：全局事務管理器接收到所有事務參與者的回復之後做判斷，如果所有事務參與者都可以提交，則向所有事務提交者發送提交申請，否則進行回滾。事務參與者根據全局事務管理器的指令進行提交或者回滾操作。分布式事務回滾原理圖如圖2-4所示。圖2-4分布式事務回滾原理圖兩階段提交採用的是悲觀鎖策略，由於各個事務參與者需要等待響應最慢的參與者，因此性能比較差。第一個問題是協議本身的成本：整個協議過程是需要加鎖的，比如鎖住資料庫的某條記錄，且需要持久化大量事務狀態相關的操作日誌。更為麻煩的是，兩階段鎖在出現故障時表現出來的脆弱性，比如兩階段鎖的致命缺陷：當協調者出現故障，整個事務需要等到協調者恢復後才能繼續執行，如果協調者出現類似磁碟故障等錯誤，該事務將被永久遺棄。對於分布式服務框架而言，從功能特性上需要支持分布式事務。在實際業務使用過程中，如果能夠通過最終一致性解決問題，則不需要做強一致性；如果能夠避免分布式事務，則盡量在業務層避免使用分布式事務。2.2分布式事務優化既然分布式事務有諸多缺點，那麼為什麼我們還在使用呢？有沒有更好的解決方案來改進或者替換呢？如果我們只是針對分布式事務去優化的話，發現其實能改進的空間很小，畢竟瓶頸在分布式事務模型本身。那我們回到問題的根源：為什麼我們需要分布式事務？因為我們需要各個資源數據保持一致性，但是對於分布式事務提供的強一致性，所有業務場景真的都需要嗎？大多數業務場景都能容忍短暫的不一致，不同的業務對不一致的容忍時間不同。像銀行轉賬業務，中間有幾分鍾的不一致時間，用戶通常都是可以理解和容忍的。在大多數的業務場景中，我們可以使用最終一致性替代傳統的強一致性，盡量避免使用分布式事務。在實踐中常用的最終一致性方案就是使用帶有事務功能的MQ做中間人角色，它的工作原理如下：在做本地事務之前，先向MQ發送一個prepare消息，然後執行本地事務，本地事務提交成功的話，向MQ發送一個commit消息，否則發送一個rollback消息，取消之前的消息。MQ只會在收到commit確認才會將消息投遞出去，所以這樣的形式可以保證在一切正常的情況下，本地事務和MQ可以達到一致性。但是分布式調用存在很多異常場景，諸如網路超時、VM宕機等。假如系統執行了local_tx()成功之後，還沒來得及將commit消息發送給MQ，或者說發送出去由於網路超時等原因，MQ沒有收到commit，發生了commit消息丟失，那麼MQ就不會把prepare消息投遞出去。MQ會根據策略去嘗試詢問（回調）發消息的系統（checkCommit）進行檢查該消息是否應該投遞出去或者丟棄，得到系統的確認之後，MQ會做投遞還是丟棄，這樣就完全保證了MQ和發消息的系統的一致性，從而保證了接收消息系統的一致性。3.研發團隊協作問題服務化之後，特別是採用微服務架構以後。研發團隊會被拆分成多個服務化小組，例如AWS的TwoPizzaTeam，每個團隊由2~3名研發負責服務的開發、測試、部署上線、運維和運營等。隨著服務數的膨脹，研發團隊的增多，跨團隊的協同配合將會成為一個制約研發效率提升的因素。3.1共用服務注冊中心為了方便開發測試，經常會在線下共用一個所有服務共享的服務注冊中心，這時，一個正在開發中的服務發布到服務注冊中心，可能會導致一些消費者不可用。解決方案：可以讓服務提供者開發方，只訂閱服務（開發的服務可能依賴其他服務），而不注冊正在開發的服務，通過直連測試正在開發的服務。它的工作原理如圖3-1所示。圖3-1隻訂閱，不發布3.2直連提供者在開發和測試環境下，如果公共的服務注冊中心沒有搭建，消費者將無法獲取服務提供者的地址列表，只能做本地單元測試或使用模擬樁測試。還有一種場景就是在實際測試中，服務提供者往往多實例部署，如果服務提供者存在Bug，就需要做遠程斷點調試，這會帶來兩個問題：1）服務提供者多實例部署，遠程調試地址無法確定，調試效率低下。2）多個消費者可能共用一套測試聯調環境，斷點調試過程中可能被其他消費者意外打斷。解決策略：繞過注冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直聯方式將以服務介面為單位，忽略注冊中心的提供者列表。3.3多團隊進度協同假如前端Web門戶依賴後台A、B、C和D4個服務，分別由4個不同的研發團隊負責，門戶要求新特性2周內上線。A和B內部需求優先順序排序將門戶的優先順序排的比較高，可以滿足交付時間點。但是C和D服務所在團隊由於同時需要開發其他優先順序更高的服務，因此把優先順序排的相對較低，無法滿足2周交付。在C和D提供版本之前，門戶只能先通過打測試樁的方式完成Mock測試，但是由於並沒有真實的測試過C和D服務，因此需求無法按期交付。應用依賴的服務越多，特性交付效率就越低下，交付的速度取決於依賴的最遲交付的那個服務。假如Web門戶依賴後台的100個服務，只要1個核心服務沒有按期交付，則整個進度就會延遲。解決方案：調用鏈可以將應用、服務和中間件之間的依賴關系串接並展示出來，基於調用鏈首入口的交付日期作為輸入，利用依賴管理工具，可以自動計算出調用鏈上各個服務的最遲交付時間點。通過調用鏈分析和標准化的依賴計算工具，可以避免人為需求排序失誤導致的需求延期。3.4服務降級和Mock測試在實際項目開發中，由於小組之間、個人開發者之間開發節奏不一致，經常會出現消費者等待依賴的服務提供者提供聯調版本的情況，相互等待會降低項目的研發進度。解決方案：服務提供者首先將介面定下來並提供給消費者，消費者可以將服務降級同Mock測試結合起來，在Mock測試代碼中實現容錯降級的業務邏輯（業務放通），這樣既完成了Mock測試，又實現了服務降級的業務邏輯開發，一舉兩得。3.5協同調試問題在實際項目開發過程中，各研發團隊進度不一致很正常。如果消費者坐等服務提供者按時提供版本，往往會造成人力資源浪費，影響項目進度。解決方案：分布式服務框架提供Mock樁管理框架，當周邊服務提供者尚未完成開發時，將路由切換到模擬測試模式，自動調用Mock樁；業務集成測試和上線時，則要能夠自動切換到真實的服務提供者上，可以結合服務降級功能實現。3.6介面前向兼容性由於線上的Bug修復、內部重構和需求變更，服務提供者會經常修改內部實現，包括但不限於：介面參數變化、參數欄位變化、業務邏輯變化和數據表結構變化。在實際項目中經常會發生服務提供者修改了介面或者數據結構，但是並沒有及時知會到所有消費者，導致服務調用失敗。解決方案：1）制定並嚴格執行《服務前向兼容性規范》，避免發生不兼容修改或者私自修改不通知周邊的情況。2）介面兼容性技術保障：例如Thrift的IDL，支持新增、修改和刪除欄位，欄位定義位置無關性，碼流支持亂序等。4.總結服務化之後，無論是服務化框架，還是業務服務，都面臨諸多挑戰，本章摘取了其中一些比較重要的問題，並給出解決方案和最佳實踐。對於本章節沒有列出的問題，則需要服務框架開發者和使用者在實踐中探索，找出一條適合自己產品的服務化最佳實踐。

7. 深度解析Java游戲伺服器開發

無論什麼語言，伺服器主要考慮的就是兩點，一是並發，二是數據（庫）對接，Java在這個方面很適合的。
並發除了有netty神庫以外，還有很多其他的網路庫，或者直接用tomcat也行，總之挺好，不過如果你要用netty的話，需要了解這個庫和並發編程，都有很多（經典）書，去看，不然你就等著踩坑吧。
數據（庫）方面，有memcache，radis的緩存庫，還有mysql和其他nosql，對接起來也很簡單，但是還是那句話，坑很多，需要自己填。
首先確定游戲需不需要長鏈接的主動推送功能，再確定並發量（效率），就基本上可以確定用什麼庫和框架了，至於數據壓縮用gzip還是7z，傳遞協議是protobuff還是json還是xml，那都是細節問題了，總之都能解決問題，不要過早考慮性能啊什麼的，先把最簡單的登錄搞起來再說

8. 大數據專業主要學習什麼語言

學習大數據，首先我們要學習Java語言和Linux操作系統，這兩個是學習大數據的基礎，學習的順序不分前後。
Java：大家都知道Java的方向有JavaSE、JavaEE、JavaME，學習大數據要學習那個方向呢？只需要學習Java的標准版JavaSE就可以了，像Servlet、JSP、Tomcat、Struts、Spring、Hibernate，Mybatis都是JavaEE方向的技術在大數據技術里用到的並不多，只需要了解就可以了，當然Java怎麼連接資料庫還是要知道的，像JDBC一定要掌握一下，有人說Hibernate或Mybites也能連接資料庫啊，為什麼不學習一下，我這里不是說學這些不好，而是說學這些可能會用你很多時間，到最後工作中也不常用，我還沒看到誰做大數據處理用到這兩個東西的，當然你的精力很充足的話，可以學學Hibernate或Mybites的原理，不要只學API，這樣可以增加你對Java操作資料庫的理解，因為這兩個技術的核心就是Java的反射加上JDBC的各種使用。
Linux：因為大數據相關軟體都是在Linux上運行的，所以Linux要學習的扎實一些，學好Linux對你快速掌握大數據相關技術會有很大的幫助，能讓你更好的理解hadoop、hive、hbase、spark等大數據軟體的運行環境和網路環境配置，能少踩很多坑，學會shell就能看懂腳本這樣能更容易理解和配置大數據集群。還能讓你對以後新出的大數據技術學習起來更快

9. Play Framework 2.x怎麼打包成war或者jar

play!framework使用netty作為網路框架，不使用tomcat等第三方web容器的

將Web應用打包成WAR文件的方法:
(1)在命令行中運用Jar命令
假定有一個Web應用：C:\myHome
myHome/WEB-INF/……
myHome/files/……
myHome/image/……
myHome/src/……
myHome/index.jsp
在命令行窗口下執行如下命令：
C:\cd myHome
C:\myHome\jar cvf myhome.war *.*/ .
解釋：jar cvf[A-war包名].
war[B-資源文件及文件夾] [C-將要生成war包的目標文件夾]「
*.*/」（B-）代表當前目錄（C:\myHome）下的所有文件及文件夾。「.
」 （C-）表明將要在當前目錄中生成war包。
操作完成後，找到C:\myHome下新生成的myhome.war，將其拷入TOMCAT_HOME/webapps/下。然後啟動Tomcat即可。
(2)利用IDE工具打包,如Eclipse
右鍵點擊你想打包的文件或者項目，選擇「export」,然後是選擇J2EE，在彈出的對話框中選擇「WAR文件」 ，上面有許多選項，還可以選「EAR」，「JAR」，個人覺得這個很方便的！
(3)利用ANT工具打包
首先配置好build.xml文件，然後dos下輸入ant ...war
選中你的web工程，lomboz J2ee---Deploy Mole,就可以把Web工程發布並打包了！

10. java-如何在Eclipse中編譯Netty的API

1. 下載java-docs-api-cn.zip中文文檔的壓縮包。如：http://dlc.sun.com.edgesuite.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/html_zh_CN.zip

2. 啟動eclipse --> [Window]菜單 --> Preferences項 --> 點擊對話框左面Java屬性下的Installed JREs，選擇右面列表中的jdk1.5.0_06，然後點擊右側的Edit按鈕打開Edit JRE對話框 --> 在JRE system libraries列表中選擇c:/java/jdk1.6.0_22/jre/lib/rt.jar，點擊右側的Javadoc Location按鈕，在彈出的對話框中選擇Javadoc in archive，將其中的Archive path設置為電腦中java-docs-api-cn.zip中文文檔的所在路徑，最後把Path within archive定位在文檔壓縮包中的api目錄（比如html/zh_CN/api）。