初识ProtocolBuf------了解使用阶段

初识ProtocolBuf

  对于ProtocolBuf的一些情况：“google公司发布的一套开源编码规则，基于二进制流的序列化传输，可以转换成多种编程语言，几乎涵盖了市面上所有的主流编程语言。”

枚举类型数据定义:

//操作类型

enum e_MsgOper_PRO

{

         E_ADD_PRO= 0;                       

         E_DEL_PRO= 1;

         E_MOD_PRO= 2;

}

//用户角色

enum e_RoomRoles_PRO

{

         E_HOST_PRO= 0;                                         //群主

         E_MANGER_PRO= 1;                                  //管理员

         E_NORMAL_PRO= 2;                                  //普通成员

}

通过枚举类型的数据定义来看，有点想C的枚举定义，但是，每个枚举值都是以’;’结束的，并且也不支持typedef而，有点遗憾的是不像C/C++一样，它的枚举值只能大于等于0；为了尽量避免和你的语言内部使用的数据结构发生冲突，最好在Pro文件上加上比较容易识别的后缀，我添加的后缀就是_PRO;

消息类型数据定义:

message HsUserOrderListInfo_Pro                            //用户订单基本信息

{

         requireduint32                                    uOrderID= 1;                                        //订单查询标示;

         optionale_HsOrderState_Pro                   iOrderState= 2;                                   //订单状态ID

         optionalstring                                      szOrderState= 3;                                //订单状态

         optionalstring                                      szOrderType= 4;                                  //订单类型标示;

         optionalstring                                      szOrderTime= 5;                                 //订单生成日期;

}

message HsUserOrderList_Resp_Pro

{

         requirede_HsOperResult_Pro         eOperResult = 1[default = E_HSOPER_SUCCESS_PRO];

         repeatedHsUserOrderListInfo_Pro         Value =2;

}

1、数据类型

Protocol支持的基本数据类型还是比较多的如下表所示：

 N 表示打包的字节并不是固定。而是根据数据的大小或者长度。

   例如int32，如果数值比较小，在0~127时，使用一个字节打包。

   关于枚举的打包方式和uint32相同。

   关于message，类似于C语言中的结构包含另外一个结构作为数据成员一样。

   关于 fixed32 和int32的区别。fixed32的打包效率比int32的效率高，但是使用的空间一般比int32多。因此一个属于时间效率高，一个属于空间效率高。根据项目的实际情况，一般选择fixed32，如果遇到对传输数据量要求比较苛刻的环境，可以选择int32.

2、字段名称

   字段名称的命名与C、C++、Java等语言的变量命名方式几乎是相同的。

   protobuf建议字段的命名采用以下划线分割的驼峰式。例如 first_name而不是firstName.

3、字段编码值

   有了该值，通信双方才能互相识别对方的字段。当然相同的编码值，其限定修饰符和数据类型必须相同。

   编码值的取值范围为 1~2^32（4294967296）。

   其中 1~15的编码时间和空间效率都是最高的，编码值越大，其编码的时间和空间效率就越低（相对于1-15），当然一般情况下相邻的2个值编码效率的是相同的，除非2个值恰好实在4字节，12字节，20字节等的临界区。比如15和16.

   1900~2000编码值为Google protobuf系统内部保留值，建议不要在自己的项目中使用。

   protobuf 还建议把经常要传递的值把其字段编码设置为1-15之间的值。

   消息中的字段的编码值无需连续，只要是合法的，并且不能在同一个消息中有字段包含相同的编码值。

   建议：项目投入运营以后涉及到版本升级时的新增消息字段全部使用optional或者repeated，尽量不实用required。如果使用了required，需要全网统一升级，如果使用optional或者repeated可以平滑升级。

4、默认值

当在传递数据时，对于required数据类型，如果用户没有设置值，则使用默认值传递到对端。当接受数据是，对于optional字段，如果没有接收到optional字段，则设置为默认值。

编程语言转换

ProtocolBuf支持针对多种语言的数据类型转换，当然还是以Java语言的转换最到位，悲催的C++数据转换竟然抹掉了所有的注释说明，因此，使用ProtocolBuf转换后的C++代码，需要你对着.pro文件去细看，还有就是针对C++语言的支持的一个缺陷是，如果数据内容完全相同，只是消息名称不一样的话，也不支持。转换之后，只需把.h和.cc文件加入到工程中，再引入Protocol的动态库即可。关于ProtocolBuf的转换工具也是开源的，虽然不太好用，但也是可以的，如果实在忍受不了，则自己写一个呗。

ProtocolBuf的缺陷;

ProtcolBuf的出现，优点：免费、开源、短小、传输效率高，然而，它也有其自身的缺点：那就是还不够成熟，且数据易读性很差，但ProtocolBuf是谷歌自己使用和编写出来的，协议尚未纳入到国际表中中去，仅靠抓包和码流分析，难以发现问题，不过，好在其是开源的，可以根据自己的业务数据，写出一套专门的数据拆分工具来，也可以使用网上已有的数据解析工具；另外一点就是调试比较难，发现有问题，调试起来并不能得心应手，因为转换后的语言信息可读性太差。

有时间做个性能对比，pb,xml，fb