scribe 概述

scribe 是可靠的、容错的

   scribe 设计的时候，考虑了网络故障、机器故障的问题，而没有考虑事务的支持。如果一个scribe的客户端实例，在发送信息给主机的时候出现了问题，那么它会将该部分信息暂时存到本地磁盘。当该问题解决之后，它会重新该部分信息发送给主机。为了避免在主机启动的时候给主机造成过重的负载，resender会等待一段时候后再去连接，目前这段时间是随机的。当主机的处理能力快被用完的时候，它会返回TRY_LATER,  resender 在接到这个返回之后的几分钟之内将不会发出请求。当主机将信息发往nfs系统或者其他的分布式文件系统的时候，也有跟resender类似的机制。当nfs系统或者其他的分布式文件系统宕掉的 时候，主机会把信息写到本地磁盘，知道文件系统恢复正常，然后再把本地磁盘的数据发送远程的文件系统里。信息显然是有顺序的，在上述的过程中，信息的顺序将保持不变。

    以下的这些错误，将会导致数据的丢失：

• 当一个client(不是resender)到scribe服务器的连接故障的时候，数据会丢失。
• 当一个scribe服务器宕机的时候，还在内存中的数据会丢失。
• 一些系统宕机通病，比如resender不能连接到任何主机的时候，它本地磁盘有可能会爆满。
• 一些很少见的超时的情况，可能会导致部分数据出现重复。

运行 Scribe
使用 scribe  客户端

scribe的配置很简单

scribe 服务器通过参数-c 指定某个具体的配置文件来启动，当没有-c参数的时候，将使用默认的配置文件路径/usr/local/scribe/scribe.conf. 配置文件最重要的作用就是决定数据应该被发送到哪个“store”。一些“store”能包含其他的“store”，举个例子说，"bucket store"能够包含多个“file store”，并通过某种hash算法将数据分发给他们。

配置文件包括一个全局配置以及每一个“store”相关的配置。全局配置，包括监听的端口，服务每秒处理的数据的最大数。每个“store”的配置文件都包含一个“category”和一个“type”。一个“store”可以有多个“category”，可以有多个“type”。配置文件的其他部分的内容取决于“store type”，可以会包含这样的一些东西，如，日志文件路径、文件大小最大值，启用新日志文件的频率策略，以及主机（resender 要发送数据过去的地址）地址。一个“store”也可以包含其他的“store”，“store”用它的“type”命名。

目前可用的“store”有：

• file –  写到一个文件，写到本地或者nfs系统
• network – sends messages to another scribe server.
• network – 将数据发送到其他的scribe服务器
• buffer –  包括一个 主“store”和一个备份“store”。当主机正常时，就发到主机上，否则就发到从机上。当主机恢复正常的时候，数据会从备份机上同步到主机上。数据的顺序还是会被保留的。作为备份“store”，有一个限制条件，即是，备份“store”必须是file 类型的store，因为它必须可读的。
  
• bucket –包含了一堆其他的类型的store，数据会根据某种hash算法，被发送各个store上。
• null – 丢弃所有的信息。
• thriftfile – 跟file store比较像，只是将数据写到 Thrift TFileTransport file 中。
  
• multi – 这个store能将数据发送其他的多台 store上。