Unistor 介绍（ V1.0 ）

Unistor 介绍 （V1.0）新浪网研发.SINA @2012.2.20

总体介绍 新浪网研发.SINA @2012.2.20

Unistor定位与思想 • Unistor是定位在【memeche、redis】与【mysql】间的一个key/value存储产品。 • 其遵循以下的原则： • 数据的高可靠性---》高效的持久化存储。 • 高可用性---》通过zookeeper实现主、从切换，而且对外不分主从。但可以构建master与slave集群。 • 存储高效性---》针对热点数据，提供了基于key的读、写cache，有独立的dirty数据flush线程。 • 基于引擎的多数据结构支持---》与redis不同，unistor通过为不同数据结构提供不同的存储引擎以实现高效。但对外具有一致的接口（通过extra参数实现引擎特殊功能支持），此如同OO的重载。 • 数据的定量存储支持---》由于不是海量存储系统，可以通过引擎控制数据失效规则。 • 跨IDC高效数据同步--->无论IDC内或IDC间，都采用可配置的多条连接进行数据同步。 • Data是object----》可以对object的field进行操作。 • 不做分组：为了简单，unistor不做分组支持。但提供数据export、import工具方便用户进行分组变更。此类分组既可以通过key的范围，也可以通过key的hash值。而且key的大小比较及key的hash有引擎自己定义。因此，key不仅仅是字符串，而且可以是字符化表示的数据结构。

适应场景 通过开发不同的存储引擎，实现如下的应用场景： • 前端高可用cache系统： cache的数据大于内存大小。 • 要求存储固定时间的存储系统：如数据必须cache一周、一月等指定的时间才能够实现。 • 要求存储固定数据量的存储需求如按照用户为单位，每个用户存储最新N条数据。 • 小文件的大文件存储如图片缩略图文件、用户session。 • 高效计数器 unistor的计数器支持max、min值，而且高效。可开发专门的计数器系统。

不适应场景 • 海量数据存储： unistor不会做自动分组，因此不会做海量数据。但会提供数据导出、导入工具，支持用户自己分组安排。 • 关系管理： unistor从结构上支持按照存储引擎（用户）定义的key的范围或key的hash值进行数据管理。但这种管理都是基于Key的。平台不提供基于key外的其他自动的关系管理，除非存储引擎自己处理。 • Key为非ascii场景 unistor对于key是不做解释的，但其必须为ascii字符，对于非ascii字符的场景不支持。但，在引擎内部可以使binary的数据结构，用户可以通过存储引擎定义此结构【等于】【小于】、【hash】的操作。而且内存cache也使用用户定义的此些函数对key进行操作。

总体架构图 说明： 1、集群可以分master、slave集群。每个集群可有自己独立的zookeeper管理。 2、Master集群的所有节点，都是可写的，其内部实现master转发。 3、Slave集群的master，负责从配置的master集群同步数据，而其他的从master同步。 4、数据同步采用可配置的多条连接，以提高吞吐里。而且集群内部的同步为串行同步。

服务内部架构

服务内部架构说明 • 存储引擎采用动态加载，可以扩展，当前实现了bdb的btree引擎，支持expire。 • 内部有基于key的read cache。有write cache及独立的write cache的flush线程。 • 有独立的转发线程，实现master集群内部【写】及【master读】的master转发。数据转发采用可配置的多条连接以提高转发效率。 • Binlog的数据分发，分为集群内部、外部两个分发接口，由独立的线程运行。两种分发都采用可配置的多条连接、而且支持压缩、chunk以提高分发效率。 • 数据读是多线程的，线程的数量可以配置。 • 数据写是单线程的。 • 有独立的checkpoint线程，以完成数据的checkpoint，同时担负expire时间的检测。 • 有独立的zookeeper事件接收线程，以处理zookeeper的事件。并将这些事件通知相关的线程。

功能说明-1 • 高可用性，Master失效后，从master同步数据的slave会自动变为master。 • 支持Master、slave的集群。 • 集群内的数据转发、数据同步及集群间的数据同步，才用可配置的多条连接。 • Key/value的value，可以是multi-field结构，类似于数据库table的column，可单独get/set。 • 支持版本控制、支持用户认证。 • 支持如下的接口： • add：可add一个key或key的一个、多个field。 • set：可以set一个key或key的一个、多个field。 • update：可update一个key或key的一个、多个field。支持版本控制。 • inc：可inc一个key或key的一个field。支持版本控制。 • del：可del一个key或key的一个field。支持版本控制。 • exist：检测指定的key或field是否存在。 • get：可get一个key或key的一个、多个field。可控制是否从master获取数据。 • multi-Get：可get多个key或多个key的一个、多个field。可控制是否从master获取数据。 • list：查询指定范围的key；可以asc、desc；可指定输出的field；可控制是否从master获取数据。

功能说明-2 • 支持基于key范围或key的hash值，export数据。 • 内部有基于key的读、写cache，以保证热点数据的高效读、写。 • 所有key具有32位的版本号，控制key的更新。 • 通过存储引擎，可以实现对多种数据结构的存储支持。

数据操作接口说明 新浪网研发.SINA @2012.2.20

操作接口—add（存在则失败） • 接收：【消息类型：1】 • k：key的名字。 • f：添加的field。 • x：引擎扩展字符串。 • d：消息的数据（任意内容，最长为2M） • e：key的超时时间，单位为second。只有创建key的时候才使用。 • v：版本号，若指定则新加的数据的版本号为指定值；否则若添加key为1，若存在则为当前版本号+1。 • sign：添加规则。0：添加key；1：添加field，key必须存在；2：添加field，key可不存在。缺省为0。 • c：是否cache。1：cache；0：不cache。缺省为1. • u：用户名 • p：口令 • 回复：【消息类型：2】 • ret：接收状态（0：成功，其他：各种错误代码） • v：成功后的数据版本号。 • fn：key的field数量。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—set（不存在则添加） • 接收：【消息类型：3】 • k：key的名字 • f：set的field。 • x：引擎扩展字符串。 • d：消息的数据（任意内容，最长为2M） • e：key的超时时间，单位为second。只有创建key的时候才使用。 • sign：set标记。 0：更新整个key；1：更新key的field。缺省为0。 • v：版本号，若指定则新加的数据的版本号为指定值；否则若添加key为1，存在则为当前版本号+1。 • c：是否cache。1：cache；0：不cache。缺省为1。 • u：用户名 • p：口令 • 回复：【消息类型：4】 • ret：接收状态（0：成功，其他：各种错误代码） • v：成功后的数据版本号。 • fn：key的field数量 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—update（不存在则失败） • 接收：【消息类型：5】 • k：key的名字 • f：update的field。 • x：引擎扩展字符串。 • d：消息的数据（任意内容，最长为2M） • e：key的超时时间，单位为second。只有创建key的时候才使用。 • sign：update标记。 0：更新整个key；1：更新指定的field，而且field必须存在；2：更新field，允许field不存在，若不存在则添加。缺省为0。 • v：若指定，则更新是key的版本号必须为此值。 • u：用户名 • p：口令 • 回复：【消息类型6】 • ret：接收状态（0：成功，其他：各种错误代码） • v：成功后的数据版本号。 • fn：key的field的数量。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—inc • 接收：【消息类型：7】 • k：key的名字 • f：inc的field。 • x：引擎扩展字符串。 • n: inc的值，可为负值。 • max：计数的最大值 • min：计数的最小值。 • e：若是创建key而且指定此值，则设置key的expire值。只有创建key的时候才使用。 • sign：inc的规则。0：计数器必须存在；1：若计数器为field，则计数器对应的key必须存在，而field可以不存在。2：计数器可以不存在，系统自动创建。缺省值为0 • v：若指定，则更新是key的版本号必须为此值。 • u：用户名 • p：口令 • 回复：【消息类型：8】 • ret：接收状态（0：成功，其他：各种错误代码） • v：成功后的数据版本号。 • n：计数后的值。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—delete（不存在则失败） • 接收：【消息类型：9】 • k：key的名字 • f：delete的field。 • x：引擎扩展字符串。 • v：若指定，则更新是key的版本号必须为此值。 • u：用户名 • p：口令 • 回复：【消息类型】 • ret：接收状态（0：成功，其他：各种错误代码） • v：成功后的数据版本号。 • fn：key剩余field的数量。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—exist • 接收：【消息类型：11】 • k：key的名字 • f：检测的field。若不指定则检测key。 • x：引擎扩展字符串。 • v：若指定则返回key的版本号。 • mt：是否从master获取。此为消息头的attr的bit0标志位。1：是；0：不是。 • u：用户名 • p：口令 • 回复：【消息类型：12】 • ret：接收状态（0：成功，其他：各种错误代码） • fn：key的field的数量。 • v：若获取版本号，则返回数据版本号。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—get • 接收：【消息类型：13】 • k：key的名字 • f：get的field，多个field以【\n】分割。 • x：引擎扩展字符串。 • i：返回key的定义。0：key的data；1：key的info；2：系统key。若返回的统计信息，则为【expire，version，data length、version】。 • v：若指定则返回key的版本号。 • mt：是否从master获取。此为消息头的attr的bit0标志位。1：是；0：不是。 • u：用户名 • p：口令 • 回复：【消息类型：14】 • ret：接收状态（0：成功，其他：各种错误代码） • d：若成功，为key的数据。 • v：若获取版本号，则返回数据版本号。 • fn：key的field数量。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—gets • 接收：【消息类型：15】 • k：多个key的名字，为key/value的格式。 • f：get的field，多个field以【\n】分割。 • x：引擎扩展字符串。 • i：返回key的定义。0：key的data；1：key的info；2：系统key。若返回的统计信息，则为【expire，version，data length、version】。 • mt：是否从master获取。此为消息头的attr的bit0标志位。1：是；0：不是。 • u：用户名 • p：口令 • 回复：【消息类型：16】 • ret：接收状态（0：成功，其他：各种错误代码） • d：若成功，为key的数据。其为key/value结构，每个key就是参数中的key。若key不存在则表示key不存在。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—list • 接收：【消息类型：17】 • begin：开始的key，若不指定则从开始获取。 • end：结束的key，若不存在则不限制。不包含最后的key。 • n：获取的数量，缺省50，最大1000 • f：get的field，多个field以【\n】分割。 • x：引擎扩展字符串。 • asc：是否升序 • ib：是否包含begin的key • i：是否返回key的统计信息。1：是；0：不是，缺省为0。若返回的统计信息，则为【expire，version，data length、version】。 • mt：是否从master获取。此为消息头的attr的bit0标志位。1：是；0：不是。 • u：用户名 • p：口令 • 回复：【消息类型18】 • ret：接收状态（0：成功，其他：各种错误代码） • d：若成功，为key的数据。为key/value结构，每个key就是参数中的key。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—import（直接覆盖） • 接收：【消息类型：19】 • k：key的名字 • x：引擎扩展字符串。 • d：消息的数据（任意内容，最长为2M） • e：key的超时时间，单位为second。只有创建key的时候才使用。 • v：版本号，若指定则新加的数据的版本号为指定值；否则若添加key为1，存在则为当前版本号+1。 • c：是否cache。1：cache；0：不cache。缺省为1。 • u：用户名 • p：口令 • 回复：【消息类型：20】 • ret：接收状态（0：成功，其他：各种错误代码） • v：成功后的数据版本号。 • fn：key的field数量。返回值恒为0。 • err：错误时的错误消息（ret为非0的错误描述）

操作接口—认证接口 • 接收：【消息类型：21】 • u：用户名 • p：口令 • 回复：【消息类型：22】 • ret：接收状态（0：成功，其他：各种错误代码） • err：错误时的错误消息（ret为非0的错误描述）

数据Export接口说明 新浪网研发.SINA @2012.2.20

Subscribe说明 Subscribe是export及binlog同步时，用来描述export或binlog的数据规则的。具体说明如下： • 表达式为： type:group_express或者为*、空、all。 • type分为：mod、range、key三种类型。 • *、空、all表示订阅全部 • mod订阅规则--基于group求余。 group_express内容为[mod：index1,index2....]，表示对group以mod求余，余数为index1、index2等。mod为0表示不求余 • range订阅规则：基于group求余后的范围。 group_express内容为[mod:begin-end,begin-end,...]表示对group%mod的值后的group范围，多个范围可以以【,】分割，若begin==end，则只写begin就可以了。mod为0表示不求余。 • Key订阅规则：基于key范围的获取。内容为[key1-key2,key3-key4...]，表示key[key1,key2)、[key3,key4)半开半闭区间。若key中出现【,】或【-】，则用,,或--表示。若前一个为空，则表示最小，若后一个为空，则表示最大

错误接口 • 接收：【消息类型：109】 • ret：错误消息号。 • err：错误的消息内容 • 回复：【消息类型：110】无需回复，直接关闭连接。此消息用于export及数据同步过程中的错误通报。若收到此消息则连接会被server关闭。

数据Export接口—Export报告接口 • 接收：【消息类型：51】 • u：用户名 • p：口令 • chunk：chunk传送的数据包的大小，单位为KBYTE。缺省64KByte。 • subscribe：key的export规则。具体见订阅规则说明。 • k：开始的key，若为空表示从开始导出。 • 回复：【消息类型：52】 • sid：开始export时的sid值，需要从此值后同步binlog。 • session：数据发送的session值。当前没用。若失败，则返回错误的消息类型，并描述具体的错误。

数据Export接口—数据发送接口 • 接收：【消息类型：51】 • seq：数据包的序列号，此为64位的网络字节序的整数。 • k：多个key名字为k的key/value。每个value的内容如下 • k：key的名字 • d：key的值。 • v：key的版本号。 • e：key的失效时间。 • x：引擎的扩展 • 回复：【消息类型：52】 • seq：接收到的数据包的序列号，此为64位的网络字节序的整数。

数据Export接口—数据导出完毕接口 • 接收：【消息类型：53】 • sid：导出完毕时的binlog的sid值，至少需要同步此部分binlog保证数据的完整性。 • 回复：无需回复，unistor会主动关闭连接。

数据同步接口说明 新浪网研发.SINA @2012.2.20

数据同步接口—数据同步报告接口 • 接收：【消息类型：101】 • sid：同步开始点。 • u：用户名 • p：口令 • chunk：chunk传送的数据包的大小。单位为KBYTE。缺省为0表示不按照chunk发送。 • subscribe：传送消息的过滤定义。具体见subscribe的说明。 • sign：数据传送的签名。支持crc32与md5，缺省不签名。 • zip：是否压缩。1：压缩；0：不压缩。缺省不压缩。 • 回复：【消息类型：102】 • session：数据发送的session值。可以基于此session值建立多条连接同步。若认证或其他失败，则发送错误消息。随后开始同步数据。

数据同步接口—多连接同步的连接报告接口 • 接收：【消息类型：103】 • Session：连接所属的同步session。 • 回复：【消息类型：104】不回复，若成功直接发送数据，否则发送错误消息。

数据同步接口—非chunk模式同步数据 • 接收：【消息类型：105】 • seq：同步消息的序列号。消息数据的开头为64位的网络字节序整数，表示消息的序列号。 • sid：数据变更的sid值。 • t：数据变更的时间戳 • d：数据 • g：数据的分组 • type：消息的类型，对应于add、set、update、delete、inc。 • v：数据的版本号。 • md5：若md5签名，则传送md5签名值。 • crc32：若crc32签名，则传送crc32的签名值。 • 回复：【消息类型：106】 • seq：同步数据的seq值。

数据同步接口—chunk模式同步数据 • 接收：【消息类型：107】 • seq：同步消息的序列号。消息数据的开头为64位的网络字节序整数，表示消息的序列号。 • m：key/value结构的多个数据变更。内部的每个数据都是【非chunk】模式的一个数据消息。 • md5：若md5签名，则传送md5签名值。 • crc32：若crc32签名，则传送crc32的签名值。 • 回复：【消息类型：108】 • seq：同步数据的seq值。

配置说明 新浪网研发.SINA @2012.2.20

Unistor配置文件-1 [common] home=运行目录 thread_num=数据接收线程的数据 store_type=数据引擎类型，如bdb等，配置中应该有【bdb】的配置项 sock_buf_kbyte=数据分发的socket buf max_chunk_kbyte=数据分发的chunk包大小 store_flush_num=多少条数据变更，需要flush到store_type指定的存储中。否则在write cache。 host=主机标示，如172.16.42.63 idc=机房名字 group=分组id monitor=监控地址及端口号，如：*:9666 trans_conn_num=内部消息转发的connection数量 sync_conn_num=内部数据同步的connection数量。 max_write_queue_messge=写队列允许排队等待的最多写消息数量，超过此数量则拒绝新写。 max_trans_message=并发转发允许的最多等待的消息数量，超过此数量则拒绝转发，此包括转给master的写、读。

Unistor配置文件-2 write_cache_mbyte=写cache的大小 read_cache_mbyte=读cache的大小 read_cache_max_key_num=读cache的hash的桶数量 master_lost_binlog=若slave切换为master，则运行丢失的最大binlog数量，否则禁止切换为master enable_expire=yes/no，是否支持expire expire_default=缺省的超时值。 expire_concurrent=超时检测的并发数量。 [zk] ---zookeeper的配置 server=zookeeper的连接地址，如172.16.42.63:2181，多个以【，】分割。 auth=连接鉴权信息 root=配置在zookeeper中的根目录 [inner_dispatch] ---内部分发信息 user=分发的用户名 passwd=分发的用户口令 listen=内部分发的监听地址，如：*:9667

Unistor配置文件-3 [outer_dispatch]---外部分发配置 user=外部分发的用户名 passwd=外部分发的用户口令 listen=外部分发的监听地址，如：*:9668 [recv] ----数据增、删、改、查询的配置 user=用户名 passwd=用户口令 listen=监听地址，如：*:9669 [binlog] ---binlog的配置 path=binlog的目录 file_prefix=binlog的文件前缀 file_max_mbyte=binlog文件的大小 max_file_num=最大的binlog文件数量

Unistor配置文件-4 del_out_file=对于超过管理范围的binlog，是否删除 cache=是否cache flush_log_num=收到多少条binlog必须flush磁盘 flush_log_second=多少时间必须flush磁盘 [bdb] ----store-type指定的bdb的配置 env_home=bdb的env-home的路径 db_path=bdb数据文件的路基 compress=是否压缩 cache_msize=bdb的cache大小 page_ksize=bdb的文件page的大小

Zookeeper的配置信息-1 -----/ |----idc名字 | |----分组1 | | |----master：存放当前的master信息。【master-ip】:【新master最小sid】:【最新sid值】:【最新时间戳】 | | |----host | | | |----ip1：此分组下的服务器ip地址，内容为【最新变更sid值】:【最新变更的时间戳】 | | | |----ip2 | | | ----lock：集群主机的lock目录 | | | |----172.16.42.62-0135a30661b81a1e-0000001354 格式为【ip】-【zk session】-【zk seq】 | | | |----172.16.42.63-0135a30661b81a1d-0000001353 | | | ----conf：集群配置，内容如下

Zookeeper的配置信息-2 [common] master_idc=yf ：集群的master idc [sync] ：若是slave集群，需要配置其从哪个集群同步数据（可以是master，也可以是slave）。 ip=172.16.42.62,172.16.42.63 ：同步集群的服务器列表，多个以【,】分割。 port=9668 ：同步的端口号。 user=dwb1 ：用户名 passwd=dwb1 ：同步的用户口令 zip=1 ：同步时，是否压缩。 sign=crc ：同步是的签名方式，可以为空、md5、crc32 sync_conn_num=20：同步的并发连接数量 max_chunk_kbyte=64 ：同步时的chunk大小。

编译安装 新浪网研发.SINA @2012.2.20

编译安装—unistor的依赖 • 依赖的库： • cwinux 需要cwinux V2.3.2版本。 • Expat 最新版本即可。 • zookeeper C 库最新版本即可以上的库全部都是通过configure、make、make install的方式编译、安装。需要注意的是，安装后，其header文件及lib文件，必须分别位于安装目录下的include及lib目录下。在unistor编译指定路径的时候，需要指定安装目录。

编译安装—unistor的编译、安装（一） • 编译 • tar xvfz unistor.tar.gz • cd unistor • ./configure --prex=安装目录 --with-cwinux=cwinux安装目录 –with-zk=zk的安装目录 –with-openssl=openssl安装目录 • make && make install • 安装目录结构安装目录 |-- unistor：unistor的执行程序 |-- unistor.cnf：unistor的默认配置文件，需要在配置文件的【common:home】设置此【安装目录】。子文件需要自己形成。 |-- log：unistor的log目录，unistor会默认创建此目录 |-- engine：存储引擎目录，此必须在安装目录下，而且名字为engine。 `|-- libuni_bdb.so：bdb存储引擎，其格式为【libuni_存储引擎名字.so】

编译安装—bench的编译、安装 • 功能：unistor的压力测试服务 • 编译进入bench目录，执行： ./configure --with-cwinux=cwinux安装目录 && make • 安装目录结构（以unistor-bench为例）安装目录 |-- unistor_bench：unistor_bench的执行程序 |-- unistor_bench.cnf：unistor_bench的默认配置文件，需要在配置文件的【common:home】 | 设置此【安装目录】。子文件需要自己形成。 |-- log：unistor_bench的log目录，unistor_bench会默认创建此目录。 • 修改unistor_bench的配置文件：unistor_bench.cnf • 运行 • 启动： ./unistor_bench [-f 配置文件] >/dev/null ##若配置文件不是unistor_bench.cnf，则需要通过【-f】参数指定。 • 停止：./unistor –stop

编译安装—Tool的编译、安装 • 功能：Unistor的工具集 • 编译 • cd unistor/tool • ./configure --prex=安装目录 --with-cwinux=cwinux安装目录 –with-expat=xml expat库的安装目录 • make && make install • 安装目录结构 • binlog： binlog的查看工具 • kv_add： key add的工具 • kv_set：key set的工具 • kv_update： key update的工具 • kv_inc：key inc的工具 • kv_del：key delete的工具 • kv_exist：检查key是否存在的工具 • kv_get：获取一个或多个key的工具 • kv_list：获取指定范围key列表的工具 • kv_export：数据导出工具

编译安装—存储引擎的安装（bdb为例） • 功能：unistor的存储引擎。由于各库的依赖关系不一致，下面以bdb为例说明。 • 编译 • cd unistor/driver/bdb • ./configure --prex=安装目录 --with-cwinux=cwinux安装目录 --with-bdb=bdb的安装目录 • make && make install • 安装目录结构安装完成后，会在【安装目录】下形成一个【libuni_XXX.so】的库文件。XXX为存储引擎的名字，对于bdb来说就叫bdb。

存储引擎 新浪网研发.SINA @2012.2.20

存储引擎--说明 • Unistor的数据是通过外挂的存储引擎存储。 • 通过不同的存储引擎，可以实现不同类型数据的存储。 • 通过不同的存储引擎，可以实现不同类型数据结构的存储。 • 存储引擎可以是基于内存的。 • 通过unistor.cnf来设置存储引擎的配置信息。其是在unistor.cnf中、名字为【具体存储引擎名字】的section。如，对于bdb的存储引擎，在unistor.cnf中，有一个【bdb】的section来配置bdb引擎。

Unistor 介绍（ V1.0 ）