分布式日志存储(11.5)

对于ESB总线的服务日志记录，由于原来类似的项目实施基本都是以接口和数据集成为主，即使是对于集团型的大项目一般一天的服务日志调用量也就在30万次左右，非实时类的服务占比都在70%以上，对于这种日志调用量采用传统的日志记录方式基本没有任何问题，一般还可以保留3个月的日志记录。

而最近的ESB项目实施可以看到，由传统的数据集成转变为了业务集成，由数据落地模式转变为了数据不落地模式，原来的定时服务调用都转变为了实时的服务调用接口。在这种场景下，服务每天的调用量会呈现指数级的增加，在月末的高峰时期，往往一个实时调用服务的一天调用次数就可以达到500万次，乃至上千万次的服务调用次数。即使10个T的数据存储空间，往往也很难存储3个月的日志。

对于如此巨大的接口服务日志量，如果采用传统的结构化数据+CLOB字段进行存储，在一开始进行方案实际的时候就考虑到了日志的数据量问题，因此我们一开始就设计了按天进行分区的分区表，每天都产生一个独立的分区表，但是如果一天的接口服务调用量就达1000万次以上，那么按天设计分区表本身日志存储压力也很大，同时对于日志信息的查询本身性能也有影响。

对于日志从存储，前面已经谈到过，可以灵活的配置每个服务的日志记录类型，其中包括了日志实例头，详细的日志报文和输入输出，如果仅仅是实例头记录，那么对于存储的消耗很小，但是仍然会影响到服务日志信息查询的性能。

同时在这种架构设计下，日志存储的扩展相对困难，而且还使用到类似IP SAN等昂贵的集中存储空间和设备。如果日志存储能够全部转移到类似NFS分布式文件存储系统上，并实现分布式的日志存储库则是一个更好的解决方案。

对于分布式日志存储，当前你完全可以基于HDFS分布式文件系统来搭建自己的分布式日志存储库，对于一条日志实例信息，也不是简单的Key-Value键值对，而是涉及到实例ID，时间，调用方系统和IP等各种结构化信息，也涉及到消息报文的非结构化信息。因此类似MongoDB，HBase这种半结构化的数据库也是可以考虑用于分布式日志信息的存储和后续检索。

在前面进行日志关键字信息查询的时候，我们采用了Solr来实现日志信息的关键字查询，实际上你也可以将Solr用于分布式日志存储和检索。对于Solr的索引文件信息存储，可以直接采用Solr本身的分布式集群进行存储，也可以考虑Hdfs存储，当时对于HDFS存储是否合适可参考：

https://blog.csdn.net/aidayei/article/details/6614393

Facebook 开源的一个可扩展，具备容错性的分布式日志系统。

LogDevice 是专为日志设计的分布式数据存储系统。一般的文件系统会将数据储存为文件，LogDevice 会将数据存储为日志，这些日志可被视为记录式的，追加式的和可修剪的文件。

记录式的（record-oriented） 意味着数据作为不可分割的记录写入日志，而不是单个字节。日志实质上是问题的最小单元，用户也一定是读取整行日志。日志的存储原则是按照日志序列号（LSN）来存放，且编号不保证是连续的，可能存在间隙。作者不会事先知道成功写入后将为其日志分配什么 LSN ，这样日志系统就可以优先高写入需求，对写入失败容错。

日志是追加式的（append-only） ，不支持修改现有记录。

日志在被删除之前预计会存在相对较长一段时间 ：几天、几月甚至几年。日志的主要空间回收机制是修剪（trimming），根据基于时间或基于空间的保留策略，删除最旧的记录，或响应修剪日志的请求。

LogDevice 从头开始设计，可提供大规模、高可靠性和高效率的多种日志类型。它还具备高度可调性，允许对每个用例进行优化，以便在从耐久性到效率性，一致性到可用性中进行恰当的权衡取舍。

具体参考：

https://www.oschina.net/p/logdevice