缓存之Tair

32 阅读 0 评论 0 点赞

介绍

在Tair出现之前的很长一段时间里，像redis、memcache这些知名NoSql数据库是不支持分布式的，在这样的背景下，由淘宝网自主开发并在2010.6开源的一个高性能、高扩展、高可靠分布式缓存，类似map的key/value结构，在淘宝、天猫等各个应用中广泛应用。

Tair官网：https://www.oschina.net/p/tair
gitee地址：https://gitee.com/mirrors/Tair
github wiki地址：https://github.com/alibaba/tair/wiki

概念

configID：一个Tair集群的唯一标识
namespace：应用的一个内存或者持久化存储区域，0到65535之间的一个数字
quta：配额，对应了每个 namespace 储存区的大小限制，超过配额后将使用LRU（最少使用）策略淘汰
expireTime：数据的过期时间。当超过过期时间之后，数据将对应用不可见，不同的存储引擎有不同的策略清理掉过期的数据
prefix：前缀处理，保证了拥有相同前缀的key根据哈希算法后，分散在同一个dataserver上，提高了处理速度。

特性

Tair实现了集群部署，特性都是一些集群的特性，容错、解决单点故障、跨机房管理、多集群管理、支持副本等。Tair的特性有：
• Namespace
• Expire
• Prefix
• List，zset，hash，set
• LocalCache
• FlowControl
抽象存储层，内部采用MDB、RDB、LDB三中存储引擎满足了各种存储需求。
MDB是内存型，K/V结构，底层是memcache ，由于是内存型性能最高但是不支持持久化。
RDB底层是redis引擎，支持List、Set、Zset、Map、String等多种数据结构，性能略低于MDB。
LDB是持久化型引擎，底层是google的levelDB，K/V结构，性能最低，但是可靠性最高。

应用场景

由于Tair底层的MDB、RDB、LDB三种引擎支持，既能作为缓存使用又可以作为持久化存储数据库，命令除了put、get、delete以及批量接口外，还有一些附加的实用功能比如version支持、原子计数器、item支持，可以用于实现分布式锁，队列等。

Tair与其他缓存对比

	Tair	Redis	Memcache	Ehcache
是否开源	开源	开源	开源	开源
使用语言	服务器端C++；客户端支持C、JAVA、PHP等	ANSI C语言编写，提供多种语言(C/C++/JAVA/PHP等)的API	服务端C，客户端支持c、php、java、python等	java
集群	支持	3.0以后支持	服务端不支持，客户端使用一致性hash算法将数据分布式存储	支持，默认是异步同步
容灾	支持	3.0以后支持	可通过客户端实现	支持
高可用	支持	3.0以后支持	不支持，可通过第三方应用比如magent实现	支持
动态扩展	支持	3.0以后支持	可通过客户端实现	支持，本地存储在.data和.index文件
效率	LDB < RDB < MDB	高	高于redis	高于memcache
持久化	LDB、RDB引擎支持	支持（AOF、默认RDB）	不支持，可通过第三方应用实现	支持
缓存过期失效策略	支持	支持	支持，lru算法	支持，LRU(默认)，FIFO，LFU
数据结构	K/V、list、hash、set、sortedsort等	K/V、list、hash、set、sortedsort五种数据结构	支持简单的K/V结构	支持简单的K/V结构
分布式	支持	3.0以后支持	客户端使用一致性hash做分布式	支持
跨机房管理	支持	不支持	不支持	不支持
多集群管理	支持	不支持	不支持	不支持
使用状况	只有阿里内部大规模使用	普遍使用	使用情况较多	多用于hibernate的缓存实现
缺点	文档不全，社区不活跃，单节点上性能没有redis高，不能对key实现模糊查询，单条数据不能太大key建议1k以下，value不能超过1M，建议10k以下	3.0以前不支持集群，单线程无法充分利用多核服务器CPU，事务支持较弱，rdb每次都是写全量数据，成本高，aof追加导致log特别大	结构单一，数据在内存重启会丢失，数据大小受内存限制	结构单一、只适用于java体系，只能用java编写客户端，且使用磁盘做cache时占空间
优点	采用分布式集群架构，具备自动容灾及故障迁移能力，对存储层做了抽象，底层方便切换不同的存储引擎，采用一致性哈希算法将key分散在Q个桶中，并将桶放到不同的dataserver上，保证数据平衡，tair高可用比较强，容灾性比redis强，支持多种集群结构，支持跨机房数据分布	非常丰富的数据结构而且都是原子性操作、高速读写、支持事务，支持aof、rdb两种持久化机制，拥有丰富特性，订阅发布 Pub / Sub 功能、Key 过期策略、事务、支持多个 DB、计数、支持集群和数据备份	简洁，灵活，多线程非阻塞io效率高，所有支持多种语言api，且在并发下用cas保证一致性	效率高，功能强大，版本迭代特别快、缓存策略支持多种，可以通过rmi可插入api实现分布式缓存、具备缓存监听、支持多缓存实例、提供hibernate的缓存实现、支持非持久化和持久化缓存数据

Tair安装部署

虚拟机环境准备

连接方式：

”NAT“ ：

网络地址转换（NAT）和 NAT网络一个意思，全称Network Address Translation借助网络地址转换功能，通过宿主机所在的网络实现访问互联网。也是默认网络连接模式，虚拟机在外部网络中没有自己的IP地址，宿主机无法ping通虚拟机，虚拟机彼此间也不通，可访问外部网络。
优点：轻松实现上网，不占用网段中的IP地址。
缺点：宿主机不能访问虚拟机，同网段中的主机无法找到虚拟机

“桥接网卡”：

虚拟机有独立的IP，虚拟机和宿主机处于同一网段，真实存在于网络中，像是一台真实的主机，虚拟机和宿主机彼此互通，且网络中的其他主机也可以互通，主机需要有网络或接入到路由器，才能与虚拟机通信，虚拟机才可访问外网。
优点：可以轻松实现上网，同网段中的主机任意互通。
缺点：占用网段中的IP地址。

”仅主机(Host-Only )网络“：

是一种比较复杂的模式。是在主机中模拟的虚拟网卡，所有虚拟机连接这张虚拟网卡上，虚拟机和虚拟机之间处于一个网段默认可以相互访问，虚拟机和主机默认不能互相访问，但是可以通过配置这张虚拟网卡实现，互相访问和上网等功能

“内部网络”:

内部网络模式，虚拟机与外网完全断开，只实现虚拟机于虚拟机之间的内部网络模式。虚拟机和主机不能相互访问，不属于同一网络，虚拟机和虚拟机之间可以相互访问。

	NAT	Bridged Adapter桥接	Internal内部网络	Host-only Adapter仅主机
虚拟机访问主机	√	√	×	默认不行，需配置
主机访问虚拟机	×	√	×	默认不行，需配置
虚拟机访问其他主机	√	√	×	默认不行，需配置
其他主机访问虚拟机	×	√	×	默认不行，需配置
虚拟机之间	×	√	√	默认√

安装相关依赖库

[root@test ~]# yum install -y gcc gcc-c++ make m4 libtool boost-devel zlib-devel openssl-devel libcurl-devel

yum：是yellowdog updater modified 的缩写，Linux中的包管理工具
gcc：一开始称为GNU C Compiler，也就是一个C编译器，后来因为这个项目里集成了更多其他不同语言的编译器，所以就不再只是C编译器，而称为GNU编译器套件（GCC，GNU Compiler Collection），表示一堆编译器的合集
gcc-c++则是GCC编译器合集里的C++编译器。
make是gcc的编译器,m4:是一个宏处理器.将输入拷贝到输出,用来引用文件,执行命令,整数运算,文本操作,循环等.既可以作为编译器的 前端,也可以单独作为一个宏处理器.
libtool：是一个通用库支持脚本，作用是在编译大型软件的过程中解决了库的依赖问题；将繁重的库依赖关系的维护工作承担下来，提供统一的接口，隐藏了不同平台间库的名称的差异等。安装libtool会自动安装所依赖的automake和autoconfig， autoconf:是用来生成自动配置软件源代码脚本（configure）的工具.configure脚本能独立于autoconf运行, automake:会根据源码中的Makefile.am来自动生成Makefile.in文件，Makefile.am中定义了宏和目标，运行automake命令会生成Makefile文件，然后使用make命令编译代码。
boost-devel zlib-devel openssl-devel libcurl-devel：都是编译时所依赖的库。

下载源码

# 由于Tair依赖tbsys和tbnet库，需要安装这两个库，而这两库需要编译tb-common-utils安装
# 安装git：
[root@test ~]# yum install -y git

# 从码云上下载tb-common-utils源码:
[root@test ~]# git clone https://gitee.com/abc0317/tb-common-utils.git
[root@test ~]# cd tb-common-utils/
[root@test tb-common-utils]# ll
    total 16
    -rwxrwxrwx. 1 root root  820 Mar 20 09:28 build.sh
    -rw-r--r--. 1 root root   79 Mar 20 09:28 README.md
    drwxr-xr-x. 5 root root 4096 Mar 20 09:34 tbnet
    drwxr-xr-x. 5 root root 4096 Mar 20 09:33 tbsys
# 赋予执行权限
[root@test tb-common-utils]# chmod u+x build.sh
# 指定TBLIB_ROOT环境变量 TBLIB_ROOT为需要安装的目录。
[root@test tb-common-utils]# export TBLIB_ROOT=/root/tairlib

# 进入源码目录, 执行build.sh进行安装
[root@test tb-common-utils]# sh build.sh



# 从码云上下载Tair源码:
[root@test tb-common-utils]#cd ~
[root@test ~]# git clone https://gitee.com/mirrors/Tair.git

编译安装Tair

[root@test ~]# cd Tair
# 编译依赖
[root@test Tair]# ./bootstrap.sh
# 检测和生成 Makefile (默认安装位置是 ~/tair_bin, 修改使用 --prefix=目标目录)
[root@test Tair]# ./configure
# 编译和安装到目标目录
[root@test Tair]# make -j && make install

配置Tair

基于MDB内存引擎，采用最小化配置方式，1个ConfigServer，1个DataServer搭建Tair集群

由于MDB 引擎默认使用共享内存，所以需要查看并设置系统的tmpfs的大小，tmpfs是Linux/Unix系统上的一种基于内存的虚拟文件系统。

# df命令用于显示目前在Linux系统上的文件系统的磁盘使用情况统计
[root@test Tair]# df -h
    Filesystem               Size  Used Avail Use% Mounted on
    devtmpfs                 908M     0  908M   0% /dev
    tmpfs                    919M  185M  735M  21% /dev/shm
    tmpfs                    919M   17M  903M   2% /run
    tmpfs                    919M     0  919M   0% /sys/fs/cgroup
    /dev/mapper/centos-root   41G  2.0G   39G   5% /
    /dev/sda1               1014M  146M  869M  15% /boot
    /dev/mapper/centos-home   20G   33M   20G   1% /home
    tmpfs                    184M     0  184M   0% /run/user/0

/dev/shm 目录位于 linux 系统的内存中，而不在磁盘里，所以它的效率非常高，这里我们将大小设置1G，

修改**/etc/fstab** 的这行，如果没有就在末尾加一行

tmpfs /dev/shm tmpfs defaults 0 0

改为

tmpfs /dev/shm tmpfs defaults,size=1G 0 0

改完之后，执行mount使其生效

mount -o remount /dev/shm

生效后再使用df -h 查看

[root@test Tair]# df -h
    Filesystem               Size  Used Avail Use% Mounted on
    devtmpfs                 908M     0  908M   0% /dev
    tmpfs                    1.0G  185M  840M  19% /dev/shm
    tmpfs                    919M   17M  903M   2% /run
    tmpfs                    919M     0  919M   0% /sys/fs/cgroup
    /dev/mapper/centos-root   41G  2.0G   39G   5% /
    /dev/sda1               1014M  146M  869M  15% /boot
    /dev/mapper/centos-home   20G   33M   20G   1% /home
    tmpfs                    184M     0  184M   0% /run/user/0

切换到Tair安装目录，拷贝默认配置文件准备修改

[root@test ~]# cd /root/tair_bin/etc
[root@test etc]# mv configserver.conf.default configserver.conf
[root@test etc]# mv group.conf.default group.conf
[root@test etc]# mv dataserver.conf.default dataserver.conf

该机器ip是 192.168.31.97

configserver.conf

# tair 2.3 --- configserver config
#
[public]
# 主备 ConfigServer 的地址和端口号，第一行为主，第二行为备，目前采用最简单集群只配置一个ConfigServer
#config_server=192.168.1.1:5198
#config_server=192.168.1.2:5198
config_server=192.168.31.97:5198






[configserver]
# ConfigServer 的工作端口号，和上面的配置以及 dataserver.conf 里的要一致
port=5198
# 日志文件位置
log_file=logs/config.log
# pid 存储的文件位置
pid_file=logs/config.pid
# 默认日志级别
log_level=warn
# group.conf 文件的位置
group_file=etc/group.conf
# 运行时状态持久化文件的位置
data_dir=data/data
# 使用的网卡设备名设置为你自己当前网络接口的名称，默认为eth0
dev_name=eth0

group.conf

#group name
# 集群分组的名字，tair 支持一组 ConfigServer 管理多个集群 (不建议，避免流量瓶颈在 ConfigServer 上)
#[group_1]
[group_test]






# data move is 1 means when some data serve down, the migrating will be start.
# default value is 0
# 是否允许数据迁移，双份数据情况下，要设置为 1 (内部逻辑判断是双份的话，内部也会强制置为1)
_data_move=0
#_min_data_server_count: when data servers left in a group less than this value, config server will stop serve for this group
#default value is copy count.
# 过载保护的参数，当可用的 DataServer 节点少于这个数字时，ConfigServer 不再自动检测宕机并重建路由表(避免逐台击穿而雪崩)
_min_data_server_count=1
#_plugIns_list=libStaticPlugIn.so
# 建表算法的选择和一些参数，一般默认即可
_build_strategy=1 #1 normal 2 rack
_build_diff_ratio=0.6 #how much difference is allowd between different rack
# diff_ratio =  |data_sever_count_in_rack1 - data_server_count_in_rack2| / max (data_sever_count_in_rack1, data_server_count_in_rack2)
# diff_ration must less than _build_diff_ratio
_pos_mask=65535  # 65535 is 0xffff  this will be used to gernerate rack info. 64 bit serverId & _pos_mask is the rack info,
# 数据的备份数，注意集群一旦初始化，不能修改这个值
_copy_count=1
# 虚拟节点的个数，当集群机器数量很多时，可以调整这个值
# 注意一旦集群初始化完毕，这个值不能修改
_bucket_number=1023
# accept ds strategy. 1 means accept ds automatically
# 该文件的修改会触发 ConfigServer 自动 reload，下面的参数控制是否自动加入本文件新增的 DataServer 节点到集群
# _min_data_server_count 参数也会影响，如果节点总数小于 _min_data_server_count，也不会自动加入
_accept_strategy=1
# 是否允许 failover 机制
# 这个机制工作在 LDB 引擎模式的集群下，当 _min_data_server_count 参数大于集群机器数(阻止自动剔除宕机机器)时，
# 如果该参数为1，宕机的第一个节点会进入 failover 模式，此时备机接管读写请求，同时记录恢复日志，当宕机节点恢复时，
# 自动进入 recovery 模式，根据恢复日志补全数据。注意此时第二台如果宕机，不会自动处理，所以第一台一旦宕机收到告警，
# 请尽快人为干预处理。  **failover 机制想正常工作，需要 dataserver.conf 的 do_dup_depot 为 1 才可以**
_allow_failover_server=0

# 下面是 DataServer 节点列表，注释 data center A/B 并不是集群组的概念
# 集群组的配置是当前这个文件所有内容，复制整个内容追加到本文件尾部，可以添加一个集群组
# 注意一个节点不能出现在两个集群组里！配置文件不做该校验。
# data center A
#_server_list=192.168.1.1:5191
#_server_list=192.168.1.2:5191
#_server_list=192.168.1.3:5191
#_server_list=192.168.1.4:5191
_server_list=192.168.31.97:5191






# data center B
#_server_list=192.168.2.1:5191
#_server_list=192.168.2.2:5191
#_server_list=192.168.2.3:5191
#_server_list=192.168.2.4:5191

#quota info
# 配额信息
# 当引擎是 MDB 时，控制每个 Namespace 的内存配额，单位是字节
# Tair 支持 0~65535 的 Namespace 范围，每个 Namespace 内部的 key 命名空间隔离
# 代码中出现的 area 是 Namespace 的同义词
_areaCapacity_list=0,1124000;

dataserver.conf

#
#  tair 2.3 --- tairserver config
#
[public]
# 主备 ConfigServer 的地址
#config_server=192.168.1.1:5198
#config_server=192.168.1.2:5198
config_server=192.168.31.97:5198





[tairserver]
#
#storage_engine:
#
# mdb
# ldb
#
# 使用的引擎，支持 MDB 和 LDB
storage_engine=mdb
local_mode=0
#
#mdb_type:
# mdb
# mdb_shm
#
# 如果引擎是 MDB，这里选择使用普通内存还是共享内存
mdb_type=mdb_shm

# shm file prefix, located in /dev/shm/, the leading '/' is must
# MDB 实例的命名前缀，一般在单机部署多个节点时需要修改
mdb_shm_path=/mdb_shm_inst
# (1<<mdb_inst_shift) would be the instance count
# MDB 引擎的实例个数，多个实例减少锁竞争但是会增加元数据而浪费内存
#mdb_inst_shift=3
mdb_inst_shift=0

# (1<<mdb_hash_bucket_shift) would be the overall bucket count of hashtable
# (1<<mdb_hash_bucket_shift) * 8 bytes memory would be allocated as hashtable
# MDB 实例内部 hash 表的 bucket 数，24~27均可(取决于实例大小)
mdb_hash_bucket_shift=24
# milliseconds, time of one round of the checking in mdb lasts before having a break
mdb_check_granularity=15
# increase this factor when the check thread of mdb incurs heavy load
# cpu load would be around 1/(1+mdb_check_granularity_factor)
mdb_check_granularity_factor=10

#tairserver listen port
port=5191

supported_admin=0
# 工作时的 IO 线程数和 Worker 线程数
#process_thread_num=12
process_thread_num=4

#io_thread_num=12
io_thread_num=4

# 双份数据时，往副本写数据的 IO 线程数，只能是 1
dup_io_thread_num=1
#
#mdb size in MB
#
# MDB 引擎使用的存储数据的内存池总大小 这里 slab_mem_size控制MDB内存池的总大小，mdb_inst_shift 控制实例的个数，每个实例的大小是 slab_mem_size/(1 << mdb_inst_shift) MB，注意这里一个实例必须大于512MB且小于64GB
#slab_mem_size=4096
slab_mem_size=512





log_file=logs/server.log
pid_file=logs/server.pid

is_namespace_load=1
is_flowcontrol_load=1
tair_admin_file = etc/admin.conf

# 是否在put操作遍历 hash 表冲突链时，顺带删除已经 expired 的数据
# 会导致 put 的时延增大一点点，但是有利于控制过期数据很多的场景下内存增幅
put_remove_expired=0
# set same number means to disable the memory merge, like 5-5
mem_merge_hour_range=5-5
# 1ms copy 300 items
mem_merge_move_count=300

log_level=warn
dev_name=eth0
ulog_dir=data/ulog
ulog_file_number=3
ulog_file_size=64
check_expired_hour_range=2-4
check_slab_hour_range=5-7
dup_sync=1
dup_timeout=500

# 是否使用 LDB 集群间的数据自动同步
do_rsync=0

rsync_io_thread_num=1
rsync_task_thread_num=4

rsync_listen=1
# 0 mean old version
# 1 mean new version
# 这里只能是 1
rsync_version=1
# 同步的详细配置地址，也可以使用 file:// 来指定本地磁盘的配置位置
rsync_config_service=http://localhost:8080/hangzhou/group_1
rsync_config_update_interval=60

# much resemble json format
# one local cluster config and one or multi remote cluster config.
# {local:[master_cs_addr,slave_cs_addr,group_name,timeout_ms,queue_limit],remote:[...],remote:[...]}
# rsync_conf={local:[10.0.0.1:5198,10.0.0.2:5198,group_local,2000,1000],remote:[10.0.1.1:5198,10.0.1.2:5198,group_remote,2000,800]}
# if same data can be updated in local and remote cluster, then we need care modify time to
# reserve latest update when do rsync to each other.
rsync_mtime_care=0
# rsync data directory(retry_log/fail_log..)
rsync_data_dir=./data/remote
# max log file size to record failed rsync data, rotate to a new file when over the limit
rsync_fail_log_size=30000000
# when doing retry,  size limit of retry log's memory use
rsync_retry_log_mem_size=100000000

# depot duplicate update when one server down
# failover 机制的 DataServer 开关，见 group.conf 相关说明
do_dup_depot=0
dup_depot_dir=./data/dupdepot

# 默认的流控配置，total 为整机限制
[flow_control]
# default flow control setting
default_net_upper = 30000000
default_net_lower = 15000000
default_ops_upper = 30000
default_ops_lower = 20000
default_total_net_upper = 75000000
default_total_net_lower = 65000000
default_total_ops_upper = 50000
default_total_ops_lower = 40000

[ldb]
#### ldb manager config
## data dir prefix, db path will be data/ldbxx, "xx" means db instance index.
## so if ldb_db_instance_count = 2, then leveldb will init in
## /data/ldb1/ldb/, /data/ldb2/ldb/. We can mount each disk to
## data/ldb1, data/ldb2, so we can init each instance on each disk.
data_dir=data/ldb
## leveldb instance count, buckets will be well-distributed to instances
ldb_db_instance_count=1
## whether load backup version when startup.
## backup version may be created to maintain some db data of specifid version.
ldb_load_backup_version=0
## whether support version strategy.
## if yes, put will do get operation to update existed items's meta info(version .etc),
## get unexist item is expensive for leveldb. set 0 to disable if nobody even care version stuff.
ldb_db_version_care=1
## time range to compact for gc, 1-1 means do no compaction at all
ldb_compact_gc_range = 3-6
## backgroud task check compact interval (s)
ldb_check_compact_interval = 120
## use cache count, 0 means NOT use cache,`ldb_use_cache_count should NOT be larger
## than `ldb_db_instance_count, and better to be a factor of `ldb_db_instance_count.
## each cache mdb's config depends on mdb's config item(mdb_type, slab_mem_size, etc)
ldb_use_cache_count=1
## cache stat can't report configserver, record stat locally, stat file size.
## file will be rotate when file size is over this.
ldb_cache_stat_file_size=20971520
## migrate item batch size one time (1M)
ldb_migrate_batch_size = 3145728
## migrate item batch count.
## real batch migrate items depends on the smaller size/count
ldb_migrate_batch_count = 5000
## comparator_type bitcmp by default
# ldb_comparator_type=numeric
## numeric comparator: special compare method for user_key sorting in order to reducing compact
## parameters for numeric compare. format: [meta][prefix][delimiter][number][suffix]
## skip meta size in compare
# ldb_userkey_skip_meta_size=2
## delimiter between prefix and number
# ldb_userkey_num_delimiter=:
####
## use blommfilter
ldb_use_bloomfilter=1
## use mmap to speed up random acess file(sstable),may cost much memory
ldb_use_mmap_random_access=0
## how many highest levels to limit compaction
ldb_limit_compact_level_count=0
## limit compaction ratio: allow doing one compaction every ldb_limit_compact_interval
## 0 means limit all compaction
ldb_limit_compact_count_interval=0
## limit compaction time interval
## 0 means limit all compaction
ldb_limit_compact_time_interval=0
## limit compaction time range, start == end means doing limit the whole day.
ldb_limit_compact_time_range=6-1
## limit delete obsolete files when finishing one compaction
ldb_limit_delete_obsolete_file_interval=5
## whether trigger compaction by seek
ldb_do_seek_compaction=0
## whether split mmt when compaction with user-define logic(bucket range, eg)
ldb_do_split_mmt_compaction=0

## do specify compact
## time range 24 hours
ldb_specify_compact_time_range=0-6
ldb_specify_compact_max_threshold=10000
## score threshold default = 1
ldb_specify_compact_score_threshold=1

#### following config effects on FastDump ####
## when ldb_db_instance_count > 1, bucket will be sharded to instance base on config strategy.
## current supported:
##  hash : just do integer hash to bucket number then module to instance, instance's balance may be
##         not perfect in small buckets set. same bucket will be sharded to same instance
##         all the time, so data will be reused even if buckets owned by server changed(maybe cluster has changed),
##  map  : handle to get better balance among all instances. same bucket may be sharded to different instance based
##         on different buckets set(data will be migrated among instances).
ldb_bucket_index_to_instance_strategy=map
## bucket index can be updated. this is useful if the cluster wouldn't change once started
## even server down/up accidently.
ldb_bucket_index_can_update=1
## strategy map will save bucket index statistics into file, this is the file's directory
ldb_bucket_index_file_dir=./data/bindex
## memory usage for memtable sharded by bucket when batch-put(especially for FastDump)
ldb_max_mem_usage_for_memtable=3221225472
####

#### leveldb config (Warning: you should know what you're doing.)
## one leveldb instance max open files(actually table_cache_ capacity, consider as working set, see `ldb_table_cache_size)
ldb_max_open_files=65535
## whether return fail when occure fail when init/load db, and
## if true, read data when compactiong will verify checksum
ldb_paranoid_check=0
## memtable size
ldb_write_buffer_size=67108864
## sstable size
ldb_target_file_size=8388608
## max file size in each level. level-n (n > 0): (n - 1) * 10 * ldb_base_level_size
ldb_base_level_size=134217728
## sstable's block size
# ldb_block_size=4096
## sstable cache size (override `ldb_max_open_files)
ldb_table_cache_size=1073741824
##block cache size
ldb_block_cache_size=16777216
## arena used by memtable, arena block size
#ldb_arenablock_size=4096
## key is prefix-compressed period in block,
## this is period length(how many keys will be prefix-compressed period)
# ldb_block_restart_interval=16
## specifid compression method (snappy only now)
# ldb_compression=1
## compact when sstables count in level-0 is over this trigger
ldb_l0_compaction_trigger=1
## whether limit write with l0's filecount, if false
ldb_l0_limit_write_with_count=0
## write will slow down when sstables count in level-0 is over this trigger
## or sstables' filesize in level-0 is over trigger * ldb_write_buffer_size if ldb_l0_limit_write_with_count=0
ldb_l0_slowdown_write_trigger=32
## write will stop(wait until trigger down)
ldb_l0_stop_write_trigger=64
## when write memtable, max level to below maybe
ldb_max_memcompact_level=3
## read verify checksum
ldb_read_verify_checksums=0
## write sync log. (one write will sync log once, expensive)
ldb_write_sync=0
## bits per key when use bloom filter
#ldb_bloomfilter_bits_per_key=10
## filter data base logarithm. filterbasesize=1<<ldb_filter_base_logarithm
#ldb_filter_base_logarithm=12

[extras]
######## RT-related ########
#rt_oplist=1,2
# Threashold of latency beyond which would let the request be dumped out.
rt_threshold=8000
# Enable RT Module at startup
rt_auto_enable=0
# How many requests would be subject to RT Module
rt_percent=100
# Interval to reset the latency statistics, by seconds
rt_reset_interval=10

######## HotKey-related ########
hotk_oplist=2
# Sample count
hotk_sample_max=50000
# Reap count
hotk_reap_max=32
# Whether to send client feedback response
hotk_need_feedback=0
# Whether to dump out packets, caches or hot keys
hotk_need_dump=0
# Whether to just Do Hot one round
hotk_one_shot=0
# Whether having hot key depends on: sigma >= (average * hotk_hot_factor)
hotk_hot_factor=0.8

在CentOS 7下，安装目录下的 tair.sh 启动脚本有一行代码（55行）需要修改

tmpfs_size=`df -m |grep tmpfs | awk '{print $2}'`
#这行改成下面这一行
tmpfs_size=`df -m |grep /dev/shm | awk '{print $2}'`

启动Tair实例

# 需要跟参数
[root@test tair_bin]# ./tair.sh
usage: ./tair.sh {start_cs|stop_cs|start_ds|stop_ds|start_iv|stop_iv|start_px|start_px [SERVER_COUNT]|clean|log_debug2warn|log_warn2debug}
# start_ds启动数据节点
[root@test tair_bin]# ./tair.sh start_ds
mdb engine. tmpfs_size: 1024  safety_size: 524  slab_mem_size: 512
[root@test tair_bin]# ps -ef | grep tair
root      1983     1  1 08:51 pts/0    00:00:00 ./sbin/tair_server -f ./etc/dataserver.conf
root      2011  1626  0 08:51 pts/0    00:00:00 grep --color=auto tair
# start_ds启动config配置节点
[root@test tair_bin]# ./tair.sh start_cs
[root@test tair_bin]# ps -ef | grep tair
root      1983     1  1 08:51 pts/0    00:00:05 ./sbin/tair_server -f ./etc/dataserver.conf
root      2018     1  0 08:58 pts/0    00:00:00 ./sbin/tair_cfg_svr -f ./etc/configserver.conf
root      2034  1626  0 08:58 pts/0    00:00:00 grep --color=auto tair

使用自带客户端测试读写

[root@test tair_bin]# ./sbin/tairclient -c 192.168.31.97:5198 -g group_test
TAIR> put name itheima
put: success
TAIR> get name
KEY: name, LEN: 7
 raw data: itheima, \69\74\68\65\69\6D\61
TAIR> remove name
remove: success.
TAIR> get name
get failed: data not exists.

停止tair服务

# 停止数据节点
[root@test tair_bin]# ./tair.sh stop_ds
# 停止配置节点
[root@test tair_bin]# ./tair.sh stop_cs
[root@test tair_bin]# ps -ef | grep tair
root      2061  1626  0 09:02 pts/0    00:00:00 grep --color=auto tair

Tair入门demo

搭工程导入依赖

 <dependency>
     <groupId>com.taobao.tair</groupId>
     <artifactId>tair-client</artifactId>
     <version>2.3.5</version>
 </dependency>
 <dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.59</version>
 </dependency>

测试简单put和get命令

TestTair类

package com.itheima;

import com.alibaba.fastjson.JSON;
import com.taobao.tair.DataEntry;
import com.taobao.tair.Result;
import com.taobao.tair.impl.DefaultTairManager;

import java.util.ArrayList;
import java.util.List;

public class TestTair {
    public static void main(String[] args) {
        List<String> configList = new ArrayList<String>();
        configList.add("192.168.31.97:5198");//ConfigServer的ip和端口
        DefaultTairManager tairManager = new DefaultTairManager();
        tairManager.setConfigServerList(configList);
        tairManager.setGroupName("group_test");//和配置中的组名称保持一致
        tairManager.init();

        ResultCode putResult = tairManager.put(1, "name", "itcast");
        System.out.println(JSON.toJSONString(putResult));
        //{"code":0,"message":"success","success":true}
        
        Result<DataEntry> getResult = tairManager.get(1, "name");
        System.out.println(JSON.toJSONString(getResult));	
        //{"rc":{"code":0,"message":"success","success":true},"success":true,"value":{"createDate":0,"expriedDate":0,"key":"name","locked":false,"modifyDate":1585119311,"value":"itcast","version":1}}
        
        System.out.println(getResult.getValue());
		//value: key: name, value: itcast, version: 1 cdate: 1970-01-01 08:00:00 mdate: 2020-03-25 02:55:11 edate: NEVER
        
		System.out.println(getResult.getValue().getValue());
		//itcast
    }
}

Tair原理架构

在这里插入图片描述

一个Tair集群主要包括3个必选模块：ConfigServer、Dataserver和Client

通常情况下，一个 Tair 集群中包含2台 Configserver 及多台 DataServer。其中两台 Configserver 互为主备。通过和 Dataserver 之间的心跳检测获取集群中存活可用的 Dataserver，构建数据在集群中的分布信息（对照表）。Dataserver 负责数据的存储，并按照 Configserver 的指示完成数据的复制和迁移工作。Client 在启动的时候，从 Configserver 获取数据分布信息，根据数据分布信息，和相应的 Dataserver 进行交互，完成用户的请求。

从架构上看，Configserver 的角色类似于传统应用系统的中心节点，整个集群服务依赖于 Configserver 的正常工作。而实际上，Tair 的 Configserver 是非常轻量级的，当正在工作的 Configserver 宕机的时候，另一台会在秒级别时间内自动接管。而且，即使出现两台 ConfigServer 同时宕机的恶劣情况，只要 DataServer 没有新的变化，Tair 依然服务正常。应用在使用时只需要连接 Configserver，而不需要知道内部节点的情况。

table

对照表，存放了桶和dataserver的对应关系，put数据时，会对key进行hash计算，在对桶数量取模，然后根据对照表找到相应的dataserver

0	192.168.10.1
1	192.168.10.2
2	192.168.10.1
3	192.168.10.2
4	192.168.10.1
5	192.168.10.2

假设新增了一个节点——192.168.10.3，当configserver发现新增的节点后，会重新构建对照表。构建依据以下两个原则：

数据在新表中均衡地分布到所有节点上。
尽可能地保持现有的对照关系。

更新之后的对照表如下所示：

0	192.168.10.1
1	192.168.10.2
2	192.168.10.1
3	192.168.10.2
4	192.168.10.3
5	192.168.10.3

Client

提供访问 Tair 集群的API
更新并缓存数据分布表
LocalCache，避免过热的数据访问影响 Tair 集群服务。
流量控制

common

common 目录提供基础数据结构和组件

ConfigServer

两台 Configserver 互为主备
通过和 Dataserver 之间的心跳检测来获取集群中存活、可用的 Dataserver 节点信息
根据获取的 Dataserver 节点信息构建数据在集群中的分布表
提供数据分布表的查询服务
调度 Dataserver 之间的数据迁移、复制

DataServer

提供存储引擎
接受 Client 发起的 put/get/remove 等操作
执行数据迁移、复制
访问统计

Storage

Tair的存储分为两种：persistence（持久化）和 cache（非持久化），非持久化Tair看成是分布式缓存，持久化Tair将数据序列化到磁盘，还可以配置备份数量，将一份数据放到不同的主机上，防止数据丢失。
Tair对存储做了一个抽象层，可以很方便的替换 tair 底层的存储引擎，主要有下面三种存储引擎：

mdb

一个高效率的关系型缓存存储数据库，定位于 cache 缓存，类似于 memcache。采用page/slab管理内存。支持 k/v 存取、prefix 操作、expire数据过期，采用共享内存方式，重启数据不丢。阿里内部大都采用此种模式。
图中mempool是申请到的内存池，大小在配置文件dataserver.conf中指定slab_mem_size=4096，默认是4个g，mempool被划分很多slab组，每组slab下又包含了若干page，每个page下又包含了一组chunk，memcache中叫chunk在图中指定item，item是真正存放数据的地方。

在这里插入图片描述

rdb

定位于 cache 缓存，采用了 redis 的内存存储结构。支持 k/v, list, hash, set, sortedset 等数据结构。
在这里插入图片描述

ldb

ldb，定位于高性能存储，多实例配置使用，充分利用IO，采用了 levelDB 作为引擎，并可选择内嵌mdb作为KV级别cache 加速，这种情况下 cache 与持久化存储的数据一致性由 tair 进行维护。支持 k/v，prefix 等数据结构。

Memtable：内存数据结构，新的数据会首先写入这里。
Log文件：写Memtable前会先写Log文件，Log通过append的方式顺序写入，Log的存在使得机器宕机导致的内存数据丢失得以恢复。
compact：压缩，LevelDB的一个重要特性就是数据的分层，由于数据的分层，越旧的数据处在越大的层级，越新的数据在越小的层级，compaction的过程是产生SSTable的过程，在查询数据的时候，最先读取MemTable里面的数据，然后是L0的SSTable里面，接着是L1， L2直到最大的层级。在分层设计中，越往上层，数据的容量越大，大约Ln是Ln-1层数据的10倍。在各个层级的SSTable文件，只有L0层的数据是有MemTable直接flush到磁盘上，其它层的数据是经过compaction过程进行排序整理产生的。这意味着L0层以上的数据，各个SSTable文件内的数据是有序且不会重叠的。

在这里插入图片描述

packets

packets目录提供了通信协议中各种数据包的实现。基础库主要包括tbsys和tbnet,其中tbsys是主要的数据结构和文件操作的实现，包括排它锁和读写锁实现，对线程的包装，以及配置文件读写和分析等。tbnet是主要实现了单线程的网络读写数据流，采用了epoll的模式。

plugin

tair 还内置了一个插件容器，可以支持热插拔插件。插件由 config server 配置，config server 会将插件配置同步给各个数据节点，数据节点会负责加载/卸载相应的插件。
在这里插入图片描述
插件分为 request 和 response 两类，可以分别在 request 和 response 时执行相应的操作，比如在 put 前检查用户的 quota 信息等。插件容器也让 tair 在功能方便具有更好的灵活性。

Tair核心方法

put

put重载了三个方法，namespace是存储空间，0到65535之间，key和value都会序列化，version是版本号，expireTime是失效时间，单位为秒

ResultCode put(int namespace, Serializable key, Serializable value)
ResultCode put(int namespace, Serializable key, Serializable value, int version)
ResultCode put(int namespace, Serializable key, Serializable value, int version, 
  				int expireTime)

get
```
Result<DataEntry> get(int namespace, Serializable key)
```
get接口用于获取单个数据，要获取的数据由namespace和key指定。
当数据存在时，返回成功，数据存放在DataEntry对象中；
当数据不存在时，返回成功，ResultCode为ResultCode.DATANOTEXSITS，value为null。
mget
```
Result<List<DataEntry>> mget(int namespace, List<? extends Object> keys)
```
mget接口用于批量获取数据，要获取的数据由namespace和keys 集合指定。

数据存放在DataEntry对象中病放到List中返回

delete

ResultCode delete(int namespace, Serializable key)

根据namespace和key删除指定缓存

mdelete

ResultCode mdelete(int namespace, List<? extends Object> keys)

根据namespace和 keys 批量删除

getStat

Map<String,String> getStat(int qtype, String groupName, long serverId)

得到统计信息

incr/decr

Result<Integer> incr(int namespace, Serializable key, int value,
								int defaultValue, int expireTime)
Result<Integer> decr(int namespace, Serializable key, int value,
							int defaultValue, int expireTime)

namespace：计数器所在的namespace，key：缓存的key，value：本次增加或者减少值，defaultValue：当计数器不存在时的初始化值，expireTime：过期时间，单位为秒

setCount
```
ResultCode setCount(int namespace, Serializable key, int count)
ResultCode setCount(int namespace, Serializable key, int count, int version, int expireTime)
```
将key对应的计数设置成count，忽略key原来是否存在以及是否是计数类型。因为Tair中计数的数据有特别标志，所以不能直接使用put设置计数值。

lock/unlock

ResultCode lock(int namespace, Serializable key)
ResultCode unlock(int namespace, Serializable key)

在并发情况下可以通过lock和unlock来实现分布式锁

invalid/minvalid

ResultCode invalid(int namespace, Serializable key)
ResultCode minvalid(int namespace, List<? extends Object> keys)

删除缓存

version支持

在Tair的put接口中，有一个version参数，这个参数是为了解决并发更新同一个数据而设置的。很多情况下，更新数据是先get，修改get回来的数据，然后put回系统。如果有多个客户端get到同一份数据，都对其修改并保存，那么先保存的修改就会被后到达的修改覆盖，从而导致数据丢失问题。
比如，缓存中有一个value值为 “a,b,c”，A和B同时get到这个value。A执行操作，在后面添加一个d，value为 “a,b,c,d”。B执行操作添加一个e，value为”a,b,c,e”。如果不加控制，无论A和B谁先更新成功，它的更新都可能会被后到的更新覆盖。

version使用方式

get接口返回的是DataEntry对象，该对象中包含get到的数据的版本号，可以通过getVersion()接口获得该版本号。在put时，将该版本号作为put的参数即可。如果不考虑版本问题，则可设置version参数为0，系统将强行覆盖数据，即使版本不一致。

如果返回version不一致，怎么办？

如果更新所基于的version和系统中当前的版本不一致，则服务器会返回ResultCode.VERERROR。这时你可以选择重新get数据，然后在新版本的数据上修改；或者设置version为0重新请求，以达到强制更新的效果。

Tair使用规范

key和value不能设置太大，否则耗时大，服务qps（每秒查询率）低，影响性能

key不要使用相同的值作为前缀，否则数据都会落到一个dataserver上，增加该数据节点的压力

批量请求的key个数不要太大，否则也会影响性能

超时时间也不要设置太大或者太小，设置太小容易超时，设置太大容易阻塞，建议使用默认值

Tair虽然支持list，set，map等复杂数据结构，但是支持不是很好，元素个数不易过多

本站资源均来自互联网，仅供研究学习，禁止违法使用和商用，产生法律纠纷本站概不负责！如果侵犯了您的权益请与我们联系！

转载请注明出处：免费源码网-免费的源码资源网站 » 缓存之Tair

点赞(0) 打赏

本文分类：文章资讯
本文标签：缓存之Tair
浏览次数：32 次浏览
本文链接：https://freeymw.com/article/24025.html

上一篇 > 【大模型理论篇】关于LLaMA 3.1 405B以及小模型的崛起
下一篇 > transformers调用llama的方式

评论列表共有 0 条评论

暂无评论