对于protobuf，比较容易出错的地方是repeated类型。
有这么几个特点：
1. 添加元素时，对于message的repreated类型那个，添加的方式是add_mutual，这样在google::空间相当于new出了一块新的空间，返回值是新空间的地址，利用指针修改相应的数据。
2. 删除元素时，比较特别，就在于删除时要保证google::空间的连续，所以删除时候，
a.通行的删除规则，是将要删除的元素和最后一个元素交换，然后删除最后一个元素。
b. 如果要保持元素的顺序。利用链表删除的做法，将要删除元素后边的元素都哦整体往前移动，这时候的处理不能用memcpy，因为无法保证内存的连续，只能使用循环逐个元素的移动。
3. 查询元素时，只能使用遍历。因为repeated元素的存储方式，类似于std::vector，可以理解为一块连续的空间，里边保存的是每个元素的地址。刚开始使用的时候会怀疑这种O(n)复杂度的查找方式，会不会是性能的瓶颈，但是要知道这是在内存中的操作，游戏服务器的瓶颈最常见的就是io。但是需要进一步的测试数据来验证。
其他方面倒是没有使用起来太奇怪的，无非是熟练度，以及是否能将业务与这种做法结合起来。
