转转公司经过几年的高速发展，业务场景已经非常丰富，这就对底层基础设施提出了更高的要求，尤其在存储上，需要我们有不同类型的存储服务来满足多样的业务需求。目前我们已经提供了MySQL，TiDB，ZZList，ZZRedis，ZZOS等多种存储服务。本篇文章简单介绍一下各种存储服务的适用范围以及系统架构，后面会有一系列文章详细介绍各个服务的技术细节。
首先我们看看转转目前的基础设施，如下图所示：
上图存储层中各种存储服务组成转转的存储体系，可以满足各种业务场景下的存储需求。
MySQL：传统关系型数据库，转转部分固化的关系型数据都是存储在MySQL上；
TiDB：弥补MySQL扩展性及吞吐量的不足，在数据量较大，MySQL单实例不能满足的情况下使用；
ZZRedis：分布式Redis服务的解决方案，为转转业务提供Redis缓存服务；
ZZKV&ZZList：存储非关系型数据，可用于存储我的发布、我的交易等K-List业务场景数据，并且某些情况下可替代ZZRedis释放内存资源；
ZZOS：对象存储服务对图片、图像、文本、音频、视频等文件提供永久存储服务。
下面分别介绍下这些系统的架构及设计思路：
ZZRedis
分布式Redis服务的解决方案，兼容Redis协议，底层使用分布式存储方案。ZZRedis基于开源项目Codis做的二次开发，实际上转转早期我们是直接使用的Codis，稳定性和性能表现都很好。那么我们为什么还要做二次开发呢？首先我们先来看下Codis的架构：
从上图可以看出，客户端通过Codis-proxy访问底层的Redis组，代理可以屏蔽数据分片逻辑对业务方十分友好，同时Codis-dashboard提供对Redis集群的管理功能。并且支持数据动态迁移。
Codis在功能和性能上完全满足我们的需求，但是在系统维护和易用性上还是有些不足，主要包含以下几点：
1. Codis-fe没有权限管理，裸奔安全风险大，缺少操作审计；
2. 调用方混用同一组Codis，流量上互相影响 ；
3. 平台能力不足，缺少主动管控的依据和手段；
4. 现有使用方法下，消耗内存较大，服务器资源有限；
所以，因为这几点上的不足，我们决定在Codis基础上做了二次开发解决这些问题，我们把改造后的Codis叫做ZZRedis。
ZZRedis架构如下图所示：
主要改进点如下：
1. 开发新管理平台入口，包含ZZRedis申请、管理、监控等功能，替代Codis-fe，解决缺点1；
2. 改造Jodis-client，新增调用方key，客户端通过key获取自己可用的Codis- proxy列表，解决缺点2；
3. 改造Jodis-client，新增流量统计、耗时统计，统一上报给平台监控组件。平台 监控建立服务侧视⻆、调用方视⻆的双向监控，解决缺点3。
关于内存消耗大的问题，我们通过引入固化的KV存储将性能要求不高的业务引入到固化存储上，释放紧张的内存资源。
ZZOS
对象存储，用来存储图片，视频等二进制数据。对象存储的需求很明确，就是文件存储服务，支持文件的上传和下载；
我们的定位就是提供小文件存储服务，所以在存储上我们也没做过度的设计，没有对文件进行拆分，用户文件是整个存储在服务器文件系统上的，高可用上我们也只做了主从存储，目前完全可以满足业务需求。
系统架构如下：
由上图可见，系统对外提供Http访问接口，包含：存储、路由、管理几个模块：
存储集群：负责存储二进制数据，集群以Group为单位，每个Group由两个存储节点组成(一主一从)。
路由集群：负责负载均衡和调度；
管理数据：包含用户信息及文件索引信息；
管理集群：负责用户接入及资源分配；
用户通过AdminServer注册应用信息，申请资源，调用WebServer提供的http接口进行读写访问。WebServer会对用户请求做鉴权，通过后才接受并处理请求。
上传文件：首先会从路由集群选择合适的Group，然后将数据发送到实际的存储节点。并将文件索引信息记录到DB中，返回文件对应的url。
下载文件：使用上传时返回的url，url中包含Group信息，WebServer不需要经过路由集群可直接找到存储节点获取数据。
KV及KList存储
转转对KV及KList存储需求主要是因为有两点：一是ZZRedis中很大一部分对访问延迟要求不是很严格，而内存资源相对比较昂贵，所以没必要全部放到内存中,可以释放一些服务器资源。另一点是业务上一些KList的场景还在使用MySQL存储，例如个人中心中的我的发布，还是按照uid从商品库中查询。在数据量不大的情况下还是可以满足需求的，但长远看需要有高可靠的固化的KV/KList存储服务。
基于这两点我们开始了KV/KList存储的选型，首先我们使用的是PIKA。兼容Redis协议，支持主从部署。虽然扩展性不是很好，但基本满足我们的需求，于是经过一系列功能与性能测试后我们引入了PIKA开放给业务使用，使用一段时间后我们发现PIKA还是存在一些问题，例如如果主节点挂掉，从节点升主后数据需要一段时间来预热才能正常提供服务。而且某些情况下挂掉的主节点重启后需要很长时间才能追上数据，如果是一主一从的部署方式就会有很长时间单点的情况。针对这些问题以及上面提到的PIKA扩展性不好的缺陷，我们决定从新选择KV/KList存储。
因为我们对TiDB已经有了相对丰富的运维经验，TiKV的稳定性也得到充分验证。所以我们首先想到在TiKV基础上自研KV/KList存储，具体方案是这样，基于TiDB的架构，替换计算节点TiDB，利用TiKV开放的API开发Redis代理节点。实现兼容Redis协议的分布式KV/KList存储系统。计划首先支持KV、KList两种数据类型，后面根据需求扩展支持更丰富的数据类型。
架构图如下所示：
我们的项目刚要启动时，了解到美图的同学已经采用类似的思路完成了第一版的开发，系统命名TiTan，我们与美图基础架构部的同学进行了一次深入的交流，了解了TiTan的设计思路。目前TiTan已经开源，我们对其进行了深度的定制，已经生产境上投入使用。
TiDB
之前的文章已经详细介绍过转转TiDB数据库的引入过程及使用案例，这篇文章里不再赘述了。
目前转转的存储体系已经可以为业务提供全方位的存储服务，当然存储服务建设工作任重道远还需要不断地努力，不断地完善，持续优化。
作者简介：
陈东，转转基础架构部。