1，Tair是什么

是在公司内部使用的K/V存储系统，类似于memcache，mongodb，redis等产品，主要用作缓存功能，也可以用作数据的临时存储，支持持久化以及非持久化两种。

1.1 MDB引擎架构

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

1.2 概念

ExpireTime

expiredTime 是指数据的过期时间，当超过过期时间之后，数据将对应用不可见

Version

Tair 中存储的每个数据都有版本号，版本号在每次更新后都会递增，相应的，在 Tair put 接口中也有此 version 参数，这个参数是为了解决并发更新同一个数据而设置的，类似于乐观锁。很多情况下，更新数据是先 get，修改 get 回来的数据，然后 put 回系统。如果有多个客户端 get 到同一份数据，都对其修改并保存，那么先保存的修改就会被后到达的修改覆盖，从而导致数据一致性问题,在大部分情况下应用能够接受，但在少量特殊情况下，这个是我们不希望发生的。比如系统中有一个值”1”, 现在 A 和 B 客户端同时都取到了这个值。之后 A 和 B 客户端都想改动这个值，假设 A 要改成 12，B 要改成 13，如果不加控制的话，无论 A 和 B 谁先更新成功，它的更新都会被后到的更新覆盖。Tair 引入的 version 机制避免了这样的问题。刚刚的例子中，假设 A 和 B 同时取到数据，当时版本号是 10，A 先更新，更新成功后，值为12，版本为 11。当 B 更新的时候，由于其基于的版本号是 10，此时服务器会拒绝更新，返回 version error，从而避免 A 的更新被覆盖。B 可以选择 get 新版本的 value，然后在其基础上修改，也可以选择强行更新。

1.3 部署方式

双机房单集群：

两个机房的机器属于一个集群，通过一致性hash确定数据放在哪个机器上，所以会出现A机房的应用跨机房访问B机房的数据，也就是AB两个应用访问同一根数据；非常适合分布式锁；

双机房独立集群：

两个机房属于不同的集群，A机房的应用访问A集群，B机房的应用访问B集群，两个集群之间不做数据同步，不需要跨机房，但是更新时候，需要同时使两个集群数据失效才行

适用方式：

mdb 存储引擎适用于双机房单集群单份，双机房独立集群，双机房单集群双份。

rdb 存储引擎适用于双机房单集群单份。

ldb 存储引擎适用于双机房主备集群，双机房单集群单份。

热点散列

热点问题是一直以来未解的问题，在Tair的实现中，特定的某个key必然会落到具体的特定节点上，DataServer单节点的读写性能便成了单Key的读写性能瓶颈，且无法通过简单的水平扩展来解决。由于电商系的促销活动天然的存在热点数据，所以热点数据缓存的读写能力对整个缓存集群的稳定性和服务能力都起着至关重要的作用。

旧方案：

该方案是通过服务端的抽样热点识别后，利用客户端既有的LocalCache功能，将热点数据缓存在客户端，在2016年双十一中，解决了一定场景下的热点问题。

但本方案仍然存在未完全解决的问题：

1，客户端资源开销：因为热点数据会被保存在客户端，带来了额外的内存、CPU以及GC上面的开销。

2，应用不开启，推广度难：因为本方案是需要在业务层面结合自身的业务特点以及热点特性，进行代码层面的一些功能开启，在应用基数如此庞大的情况下，无法覆盖住大部分应用的热点功能开启。

3，流量热点难以识别：因为是抽样进行热点识别，且没有对数据大小进行权重区分，因此面临着访问量小但数据量大的case，无法识别出热点。

新方案：

因此今年我们继续在热点方案上进行演进：

从完美的热点识别到散列(读) / 合并(写)

利用远端的HotZone来代替本地的localcache