什么是Storm? Storm是twitter开源的一套实时数据处理框架，基于该框架你可以通过简单的编程来实现对数据流的实时处理变换。 Storm的配置文件一般存放在$STORM_HOME/conf下，通常名为storm.yaml，它符合yaml格式要求。 配置项详解: 以下是从storm的backtype.storm.Config类中搜集的所有storm支持的配置项(Based storm 0.6.0): 配置项 配置说明 storm.zookeeper.servers ZooKeeper服务器列表 storm.zookeeper.port ZooKeeper连接端口 storm.local.dir storm使用的本地文件系统目录(必须存在并且storm进程可读写) storm.cluster.mode Storm集群运行模式([distributed|local]) storm.local.mode.zmq Local模式下是否使用ZeroMQ作消息系统，如果设置为false则使用java消息系统。默认为false storm.zookeeper.root ZooKeeper中Storm的根目录位置 storm.zookeeper.session.timeout 客户端连接ZooKeeper超时时间 storm.id 运行中拓扑的id,由storm name和一个唯一随机数组成。 nimbus.host nimbus服务器地址 nimbus.thrift.port nimbus的thrift监听端口 nimbus.childopts 通过storm-deploy项目部署时指定给nimbus进程的jvm选项 nimbus.task.timeout.secs 心跳超时时间，超时后nimbus会认为task死掉并重分配给另一个地址。 nimbus.monitor.freq.secs nimbus检查心跳和重分配任务的时间间隔.注意如果是机器宕掉nimbus会立即接管并处理。 nimbus.supervisor.timeout.secs supervisor的心跳超时时间,一旦超过nimbus会认为该supervisor已死并停止为它分发新任务. nimbus.task.launch.secs task启动时的一个特殊超时设置.在启动后第一次心跳前会使用该值来临时替代nimbus.task.timeout.secs. nimbus.reassign 当发现task失败时nimbus是否重新分配执行。默认为真，不建议修改。 nimbus.file.copy.expiration.secs nimbus判断上传/下载链接的超时时间，当空闲时间超过该设定时nimbus会认为链接死掉并主动断开 ui.port Storm UI的服务端口 drpc.servers DRPC服务器列表，以便DRPCSpout知道和谁通讯 drpc.port Storm DRPC的服务端口 supervisor.slots.ports supervisor上能够运行workers的端口列表.每个worker占用一个端口,且每个端口只运行一个worker.通过这项配置可以调整每台机器上运行的worker数.(调整slot数/每机) supervisor.childopts

Flash存储设备在淘宝的应用实践
View more presentations from Feng Yu

SSD在淘宝的应用实践
View more presentations from Feng Yu

Tair是淘宝开源的分布式KV缓存系统，内部将功能模块化，抽离出底层存储细节，可以接入不同的存储引擎。leveldb是Google开源的单机存储引擎，目前，已经作为Tair的持久化存储引擎ldb上线使用，这里对接入leveldb所做的处理以及修改进行介绍。 Tair首先是一个分布式的框架，有一系列策略满足CAP（数据备份，迁移复制等）。另外，还有针对应用场景的功能特性（namespace，数据过期时间，原子计数等）。接入leveldb时主要对KV操作之外的功能做相应的处理。leveldb本身的实现介绍参见leveldb实现解析。 一. 修改配置 leveldb中有一系列参数会与读写的效率有关，将相关的配置以及编译常量统一修改成可运行时配置参数，测试选取最佳配置值。 二. 实例个数控制 首先确定在一个tair server上要启几个leveldb实例？ Tair中以桶来组织数据，如果按照一个桶一个leveldb实例，在做迁移复制的时候会很方便，但考虑如果在一块磁盘上起多个实例，那么整体看来，多个顺序写变成了随机写，每个实例的compact进程会加剧整个磁盘的随机IO，所以并不采用每个桶一个实例，而是针对磁盘的数量由相关配置控制实例的个数。 三. 内部key的格式 为实现Tair中的功能逻辑，ldb传入leveldb的user-key格式如下： 1)    Tair中的数据可以设置过期时间，过期时间保存可以保存在在value的meta中，但考虑能在leveldb内部提前检查，省去解析value的消耗，将过期时间保存在key中，但并不参与排序。 2)    Tair中的数据组织以及迁移复制都是以桶（bucket）单位，为获得一个桶的数据，添加桶号前缀，保证一个桶的数据都存储在一起。leveldb内部对key做前缀压缩，桶号基本都可以被压缩掉。 3)    Tair中的数据区分namespace，会将namespace作为客户端传入key的前缀存储。 四. 自定义comparator 为了实现Tair中的功能逻辑，实现自定义的comparator传入leveldb，实现自定义的排序逻辑(传入leveldb的user-key中表示过期时间的前四个字节不参与排序)，并为comparator添加两个判断数据是否有效的逻辑接口（ShouldDrop()/ShouldDropMaybe()）,修改leveldb内部做遍历以及compact时判断数据是否有效（kTypeValue/kTypeDeletion）的逻辑。 1)    ShouldDropMaybe(): 用来判断数据是否已经过期。解析key中的expired_time即可。 2)    ShouldDrop(): 用来判断数据是否属于已经清理掉的数据（bucket已经迁移或者namespace已经被清理）。 3)    区分过期数据与清理数据的判断，是因为丢弃过期数据必须保证该key是数据的最后出现，否则删除该数据会让该key失去最后的更新状态，而清理数据有gc信息保证，不需要关心数据的状态。 五. 清理数据/自定义的内部compact逻辑 这里把清理数据的操作称为gc。 1.    迁移的bucket以及清理的namespace中的数据 一旦发生bucket迁移或者清理namespace，会把相应的信息保存下来（GcNode） struct GcNode { // 迁移走的bucket或者清掉的namespace int32_t key_; // 清理发生时的SequnceNumber,用来判断数据的时间点 uint64_t sequence_; // 清理发生时的FileNumber，用来缩小compact的范围 uint64_t file_number_; // 清理发生时的时间 uint32_t when_; [...]

Tair已经将leveldb作为持久化存储引擎ldb，并部署线上使用。这里对leveldb本身做具体的实现解析。后续会有引入leveldb时所作修改的介绍。
leveldb实现解析.pdf