带有协议缓冲区和高级节俭的抄写员？

Question

我在这里有两个问题：

问题1：

- 节俭可以提供内同类功能吗？ （请参阅我的示例下一个）

- 如果可以的话，节俭可以轻松使用此类功能吗？

这是Scribe接口（Scribe/if/Scribe.Thrift）。但是它的消息字段只能是字符串，我相信它不够灵活。

#!/usr/local/bin/thrift --cpp --php

##  Copyright (c) 2007-2008 Facebook
...
...
## See accompanying file LICENSE or visit the Scribe site at:
## http://developers.facebook.com/scribe/

include "fb303/if/fb303.thrift"

namespace cpp scribe.thrift

enum ResultCode
{
  OK,
  TRY_LATER
}

struct LogEntry
{
  1:  string category,
  2:  string message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

如果我能做以下操作，那就太好了（我什至不知道节俭本身是否根据其文档提供了内类功能 - 但是协议缓冲区肯定可以）。

enum ResultCode
{
  OK,
  TRY_LATER
}

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry
{
  1:  string category,
  2:  MyLogStructure message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

---

问题2：

- 抄写员可以轻松使用协议缓冲区作为内部数据表示吗？ （没有太多的代码修改）

- 如果上述问题的答案是“否”，Google是否开源SRIBE实施了？

Answer 1

是的，节俭结构可以包括其他结构，您的定义（重复以下）将有效：

enum ResultCode { OK, TRY_LATER }

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry {
  1: string category,
  2: MyLogStructure message 
}

service scribe extends fb303.FacebookService {
  ResultCode Log(1: list messages);
}

如果您重新定义了像这样的抄写员的界面，则可能必须修改Scribe的代码以根据其内部使用的方式处理新类型 string message.

当然，您总是可以序列化您的 MyLogStructure 反对字符串并完全避免此问题。

不，我不认为Scribe可以轻松地使用协议缓冲区作为其内部数据表示。所有RPC代码都是从这些定义生成的，您可以重新定义 Log 采用任意对象的方法（例如，协议缓冲对象），但这与上面一样困难。

据我所知，Google尚未开源任何分布式记录系统。 chukwa 来自Yahoo/Hadoop是一种选择。