thrift的网络传输性能和需要注意的问题

来源:thrift的网络传输性能和需要注意的问题

thrift应该目前支持编程语言种类最多的跨语言 rpc服务框架, http://thrift.apache.org/

thrift实现了完整的网络服务,所以一般使用thrift时,会使用到thrift的服务框架。当然,也可以用自己已经实现的网络服务,用io流对接thrift接口的输入输出流实现thrift的接入。

无论是用thrift的网络实现,还是自己实现的网络服务,只要对接thrift,在调用thrift接口实现rpc时,都是走thrift的网络传输方式。

thrift的网络传输实现方式 不适合也不支持压力较大的网络传输需求。实际上,调用一次thrift接口,并不是只调一次网络io写数据,而是拆分为多次写数据传送。

调用一个thrift 的接口发送数据时,thrift会将这个操作拆分为几个操作:

调用thrift的方法时:thrift会找到这个方法所在的对象,调用write方法,

在write方法在,分别对各个参数,

依次调用 writeFieldBegin,writeXXX(具体参数类型) ,WriteFieldStop 等函数

每次调用也同时调用网络io写相应数据.

以目前最新的thrift-0.18.1实现为例

比如 go的实现:

func (p *ItnetPonMergeArgs) Write(ctx context.Context, oprot thrift.TProtocol) error {
 if err := oprot.WriteStructBegin(ctx, "PonMerge_args"); err != nil {
 return thrift.PrependError(fmt.Sprintf("%T write struct begin error: ", p), err) }
 if p != nil {
 if err := p.writeField1(ctx, oprot); err != nil { return err }
 if err := p.writeField2(ctx, oprot); err != nil { return err }
 }
 if err := oprot.WriteFieldStop(ctx); err != nil {
 return thrift.PrependError("write field stop error: ", err) }
 if err := oprot.WriteStructEnd(ctx); err != nil {
 return thrift.PrependError("write struct stop error: ", err) }
 return nil
}
//第一个参数
func (p *ItnetPonMergeArgs) writeField1(ctx context.Context, oprot thrift.TProtocol) (err error) {
 if err := oprot.WriteFieldBegin(ctx, "pblist", thrift.LIST, 1); err != nil { //WriteFieldBegin
 return thrift.PrependError(fmt.Sprintf("%T write field begin error 1:pblist: ", p), err) }
 if err := oprot.WriteListBegin(ctx, thrift.STRUCT, len(p.Pblist)); err != nil {
 return thrift.PrependError("error writing list begin: ", err)
 }
 for _, v := range p.Pblist { 
 if err := v.Write(ctx, oprot); err != nil {
 return thrift.PrependError(fmt.Sprintf("%T error writing struct: ", v), err)
 }
 }
 if err := oprot.WriteListEnd(ctx); err != nil {
 return thrift.PrependError("error writing list end: ", err)
 }
 if err := oprot.WriteFieldEnd(ctx); err != nil {
 return thrift.PrependError(fmt.Sprintf("%T write field end error 1:pblist: ", p), err) }
 return err
}
//第二个参数,操作类似第一个参数
func (p *ItnetPonMergeArgs) writeField2(ctx context.Context, oprot thrift.TProtocol) (err error) {
 if err := oprot.WriteFieldBegin(ctx, "id", thrift.I64, 2); err != nil {
 return thrift.PrependError(fmt.Sprintf("%T write field begin error 2:id: ", p), err) }
 if err := oprot.WriteI64(ctx, int64(p.ID)); err != nil {
 return thrift.PrependError(fmt.Sprintf("%T.id (2) field write error: ", p), err) }
 if err := oprot.WriteFieldEnd(ctx); err != nil {
 return thrift.PrependError(fmt.Sprintf("%T write field end error 2:id: ", p), err) }
 return err
}

调用Pon(ItnetPonMergeArgs)方法的thrift传输顺序是:

Write->

1. writeField1->WriteFieldBegin-> WriteByte-> io
2. -> Write16 -> io
3. ->WriteBinary-> Write32 -> io
4. ->Write -> io
5. writeField2->WriteFieldBegin-> WriteByte -> io
6. ->Write16 -> io
7. ->Write64-> Write -> io
8. WriteFieldStop ->io

可以看到,一次简单的方法调用,如果方法中有两个参数, 则至少有8次io流写数据调用。

如果参数多时,或是参数中一个结构体的变量多时,则会有更多的io流写数据调用。

在海量的网络传输中,这样的传输方式,网络io流写数据调用成倍增加,海量网络io数据写入导致性能急剧下降。

thrift设计的传输层提供了zlib协议压缩,在zlib压缩发送的情况下,将数据进行了整体压缩收发,zlib分为2次发送后,接收端再解压;

以go为例子:

可以在 compress/flate 看到zlib的写数据最终io写入调用:

func (d *compressor) syncFlush() error {
 if d.err != nil {
 return d.err
 }
 d.sync = true
 d.step(d)
 if d.err == nil {
 d.w.writeStoredHeader(0, false) //第一次调用
 d.w.flush() //第二次调用
 d.err = d.w.err
 }
 d.sync = false
 return d.err
}
//两次io数据写入

所以,在海量调用thrift方法的情况下,zlib模式的性能要远超非zlib的情况。但是zlib压缩会比较消耗内存,大量使用时可能导致频繁gc,也可能导致性能下降。当然,即使如此,大部分情况下zlib传输依然比非zlib传输的性能要好许多。

其他语言的实现:比如 java:

public void write(org.apache.thrift.protocol.TProtocol oprot, SelectByIdxLimit_args struct) throws org.apache.thrift.TException {
 struct.validate();
 oprot.writeStructBegin(STRUCT_DESC);
 if (struct.name != null) {
 oprot.writeFieldBegin(NAME_FIELD_DESC); //io调用
 oprot.writeString(struct.name); //io调用
 oprot.writeFieldEnd();
 }
 if (struct.column != null) {
 oprot.writeFieldBegin(COLUMN_FIELD_DESC); //io调用
 oprot.writeString(struct.column); //io调用
 oprot.writeFieldEnd();
 }
 if (struct.value != null) {
 oprot.writeFieldBegin(VALUE_FIELD_DESC); //io调用
 {
 oprot.writeListBegin(new org.apache.thrift.protocol.TList(org.apache.thrift.protocol.TType.STRING, struct.value.size()));
 for (java.nio.ByteBuffer _iter49 : struct.value)
 {
 oprot.writeBinary(_iter49); //io调用
 }
 oprot.writeListEnd();
 }
 oprot.writeFieldEnd();
 }
 oprot.writeFieldBegin(START_ID_FIELD_DESC); //io调用
 oprot.writeI64(struct.startId); //io调用 
 oprot.writeFieldEnd();
 oprot.writeFieldBegin(LIMIT_FIELD_DESC); //io调用
 oprot.writeI64(struct.limit); //io调用
 oprot.writeFieldEnd();
 oprot.writeFieldStop(); //io调用
 oprot.writeStructEnd();
 }

传输方式都是相似的

实现方式各个语言都相似,当然,数据写入顺序肯定是一样的。

有任何问题或建议请Email:donnie4w@gmail.com或 http://tlnet.top/contact 发信给我,谢谢!

• 编辑
• 预览