thrift,netty资源

ant-thrift:https://github.com/ehrmann/thrift-task

http://thrift.apache.org/about

facebook的版本分支:https://github.com/facebook/fbthrift

zookeeper和netty的集成:https://github.com/linkedin/norbert 

http://blog.csdn.net/yangbutao/article/details/8332505

Thrift--Spring集成ThriftServlet http://hanqunfeng.iteye.com/blog/1946999

thrift 性能http://www.cnblogs.com/xxxteam/archive/2013/04/25/3042760.html

只试用thrift作为编码解码器的例子:

http://www.tuicool.com/articles/qMNJJv

http://www.tuicool.com/articles/QJ7Jva

Nifty是facebook公司开源的，基于netty的thrift服务端实现,客户端可以直接试用原来的thrift客户端。http://www.oschina.net/p/nifty

一下部分原文地址：http://www.codelast.com/?p=4824

本文仅讨论Java版的Thrift server.如果你对C++版的感兴趣，请参考 这个 页面。

Thrift 是 一个跨语言的序列化/RPC框架，它含有三个主要的组件：protocol，transport和server，其中，protocol定义了消息是怎样 序列化的，transport定义了消息是怎样在客户端和服务器端之间通信的，server用于从transport接收序列化的消息，根据 protocol反序列化之，调用用户定义的消息处理器，并序列化消息处理器的响应，然后再将它们写回transport。Thrift模块化的结构使得 它能提供各种server实现。下面列出了Java中可用的server实现：
· TSimpleServer
· TNonblockingServer
· THsHaServer
· TThreadedSelectorServer
· TThreadPoolServer

有多个选择很好，但是哪个适合你呢？在本文中，我将描述这些server之间的区别，并展示测试结果，以说明它们的性能特点（测试的细节在附录B中）。下面，我们就从最简单的开始：TSimpleServer

TSimplerServer接受一个连接，处理连接请求，直到客户端关闭了连接，它才回去 接受一个新的连接。正因为它只在一个单独的线程中以阻塞I/O的方式完成这些工作，所以它只能服务一个客户端连接，其他所有客户端在被服务器端接受之前都 只能等待。TSimpleServer主要用于测试目的，不要在生产环境中使用它！

TNonblockingServer使用非阻塞的I/O解决了TSimpleServer一个客户端阻塞其他所有客户端的问题。它使用了java.nio.channels.Selector，通过调用select()， 它使得你阻塞在多个连接上，而不是阻塞在单一的连接上。当一或多个连接准备好被接受/读/写时，select()调用便会返回。 TNonblockingServer处理这些连接的时候，要么接受它，要么从它那读数据，要么把数据写到它那里，然后再次调用select()来等待下 一个可用的连接。通用这种方式，server可同时服务多个客户端，而不会出现一个客户端把其他客户端全部“饿死”的情况。

然而，还有个棘手的问题：所有消息是被调用select()方法的同一个线程处理的。假设有 10个客户端，处理每条消息所需时间为100毫秒，那么，latency和吞吐量分别是多少？当一条消息被处理的时候，其他9个客户端就等着被 select，所以客户端需要等待1秒钟才能从服务器端得到回应，吞吐量就是10个请求/秒。如果可以同时处理多条消息的话，会很不错吧？

因此，THsHaServer（半同步/半异步的server）就应运而生了。它使用一个单 独的线程来处理网络I/O，一个独立的worker线程池来处理消息。这样，只要有空闲的worker线程，消息就会被立即处理，因此多条消息能被并行处 理。用上面的例子来说，现在的latency就是100毫秒，而吞吐量就是100个请求/秒。

为了演示，我做了一个测试，有10客户端和一个修改过的消息处理器——它的功能仅仅是在返回之前简单地sleep 100毫秒。我使用的是有10个worker线程的THsHaServer。消息处理器的代码看上去就像下面这样：

publicResponseCode sleep()throwsTException

{  

    try{

        Thread.sleep(100);

    }catch(Exception ex) {

    }

    returnResponseCode.Success;

}

结果正如我们想像的那样，THsHaServer能够并行处理所有请求，而TNonblockingServer只能一次处理一个请求。

Thrift 0.8引入了另一种server实现，即TThreadedSelectorServer。它与THsHaServer的主要区别在 于，TThreadedSelectorServer允许你用多个线程来处理网络I/O。它维护了两个线程池，一个用来处理网络I/O，另一个用来进行请 求的处理。当网络I/O是瓶颈的时候，TThreadedSelectorServer比THsHaServer的表现要好。为了展现它们的区别，我进行 了一个测试，令其消息处理器在不做任何工作的情况下立即返回，以衡量在不同客户端数量的情况下的平均latency和吞吐量。对THsHaServer， 我使用32个worker线程；对TThreadedSelectorServer，我使用16个worker线程和16个selector线程。

结果显示，TThreadedSelectorServer比THsHaServer的吞吐量高得多，并且维持在一个更低的latency上。

最后，还剩下 TThreadPoolServer。TThreadPoolServer与其他三种server不同的是：

  有一个专用的线程用来接受连接。

一旦接受了一个连接，它就会被放入ThreadPoolExecutor中的一个worker线程里处理。

   worker线程被绑定到特定的客户端连接上，直到它关闭。一旦连接关闭，该worker线程就又回到了线程池中。

  你可以配置线程池的最小、最大线程数，默认值分别是5（最小）和Integer.MAX_VALUE（最大）。

这意味着，如果有1万个并发的客户端连接，你就需要运行1万个线程。所以它对系统资源的消耗不像其他类型的server一样那么“友好”。此外，如果客户端数量超过了线程池中的最大线程数，在有一个worker线程可用之前，请求将被一直阻塞在那里。

我们已经说过，TThreadPoolServer的表现非常优异。在我正在使用的计算机 上，它可以支持1万个并发连接而没有任何问题。如果你提前知道了将要连接到你服务器上的客户端数量，并且你不介意运行大量线程的 话，TThreadPoolServer对你可能是个很好的选择。

希望本文能帮你做出决定：哪一种Thrift server适合你。我认为TThreadedSelectorServer对大多数案例来说都是个安全之选。如果你的系统资源允许运行大量并发线程的话，你可能会想考虑使用TThreadPoolServer。