NoSQL@VIP— 唯品会NoSQL平台自动化发展及运维经验分享

About Me -- 赵新宇• 唯品会NoSQL平台负责人

• 资深数据库⼯工程师

• 前新浪微博高级DBA

• Pythoner/Gopher

• Weibo: @RainSlytherin

• Weixin: @tju_newrain

• 欢迎微博互粉或微信交流！

• 招聘数据库/自动化运维/源码开发等人才！

目录• 从数据库规模的演变看业务的快速发展

• 唯品会NoSQL自动化运维平台的建设

• Twemproxy中间层的改造及大规模部署

• 负载均衡服务化（Lbaas/Libra）

• 唯品会Redis/MC/Twemproxy运维经验

• 后续的发展思路探讨

业务的快速发展

2014 Now

RedisMemcachedTwemproxyTotal

* 业务的快速发展，运维疲于奔命，持续重复单⼀一⼜又繁琐的⼯工作、与业务扯⽪皮沟通。

3000

运维标准制定

软件选型

使用规范 资源分配

申请标准 服务部署

* 运维标准化的五个阶段分别制定严格的标准和规范。

√

√

√

软件选型标准

Data Structure? Proxy or Client? HA? Persistence?

*大部分情况下Redis都可以取代MC；DBA深入到业务架构，决定选型和数据结构设计。

资源分配方案

产品树 重要程度 核心业务 重点业务 次要业务

*简单清晰的资源分配⽅方案，让⾃自动化分配逻辑简单明了！

服务部署标准

Port Version Config Yum

全局递增 单机多版本 统⼀一配置 一键安装

*统⼀一各种标准，简化各个流程，让⾃自动化部署更加⽅方便！

自动化运维

智能化 服务化

模版化"(批量化)

可视化"(产品化)

√

√

*自动化运维的四个阶段，我们仍然是从头开始...

运维服务化

* 集成基础服务，统一访问模式，统一API规范；基于API打造上层自动化运维系统及工具。

常用的API服务• /cluster/instances -- 获取某个业务的实例配置

• /redis/start -- 启动redis服务

• /memcached/stop -- 停止MC服务

• /twemproxy/clone -- 扩容twemproxy服务

• /zabbix/status -- 获取某个业务的监控状态

• /alert/send -- 发送报警

基于API的Web管理系统

* 包括：集群管理、服务器管理、实例管理等；集成Puppet、Zabbix及软件部署及资源展示等功能。

基于API的命令行工具

* 在Web管理系统以外，基于API开发命令行工具hedwig，基本可以完成95%的基础运维工作。

基于API的自助申请部署系统

* 根据用户申请的资源规模以及基于zabbix历史数据进⾏行分析，智能设定分⽚片规模及完成资源分配。

运维可视化

• 业务数据的多维度展⽰示

• Zabbix + 定制化Dashboard

• 全链路数据分析系统 -- Titan

Dashboard — 实时、历史、对⽐比

* 基于zabbix数据开发的支持实时、历史、大促对比等功能的Dashborad⻚页⾯面。

全链路数据分析系统 -- Titan

* Python脚本使用tcpdump采样抓包写日志 -> flume监控⽇日志变化将数据写⼊入kafka集群 -> 再经过spark实时分析存储在hbase中 -> 最后基于分析数据开发展示系统Logview。

Titian-日志格式内容

10.xxx.xxx.xxx 10.xxx.xxx.xxx 6379 1433080263 185 44 8 get xxx

来源地址 目的端口

请求时间

响应时间

请求⻓长度

响应⻓长度

具体命令目的地址

* 通过Python脚本解析网络包，获取上述所列格式。其中具体命令再根据对应的软件协议进行进一步解析。

Titan-响应时间分布

* 提供响应时间分布，执行次数分布，执行比例分布

Titan-hot/slow key/query

* 提供响应时间分布、hot/slow key/query，请求分布，请求占比等功能。

Titan-请求来源

* 提供来源业务池信息，来源IP占比，请求次数，响应时间占比

Titan-全站调用拓扑

* 基于来源IP数据与CMDB信息，绘制全站数据访问拓扑图；

* 资源访问及混⽤用情况⼀一⺫⽬目了然，出问题直接定位相关业务⽅方。

缓存中间层的使⽤用

• 多个中间层功能对比

• Twemproxy上线

• Twemproxy功能改造

• Twemproxy+Sentinel+ConfigCenter

多种中间层方案对比对⽐比维度 新浪cache service 腾讯ckv 淘宝tair 京东jimstore 百度bdrp

是否使用twemproxy yes no no no yes

是否属于proxy模式 yes yes no no yes

是否存在config service yes yes yes yes yes

是否需要开发client yes yes yes yes no

是否使用ssd冷热分离 no yes no yes no

是否自动多副本 yes no yes no no

是否使用replication复制数据 no yes no yes yes

是否支持扩容后自动数据迁移 no yes yes yes no

是否读写分离 yes no no yes yes

是否自动容灾处理 yes yes yes yes yes

*根据开放文档分析得出，实际的具体数据可能出现偏差。

Twemproxy中间层的优缺点

Pros

Cons TCO ConfigHA SLB Levels

ShardCode DeployConfig

*喜忧参半，没有一劳永逸的方案，特定阶段解决特定问题！

Flow

Twemproxy上线

* 2015年5月19日-5月25日的统计数据，日请求量在150亿左右。

2015/5/19 2015/5/6 2015/5/7 2015/5/8 2015/5/9 2015/5/10 2015/5/11

150

Twemproxy功能改造

• 日志自动切割

• 配置动态更新

• Sentinel+配置中心

• Replication Pool

Twemproxy+Sentinel

* Twemproxy与Sentinel同机部署，本机Sentinle只监控本机Twemproxy后端Redis资源。

* 一期Sentinel直接更新Twemproxy配置，二期引入Config Center 。

Twemproxy+Replication Pool

* 两层一致性hash环，同时双写，第⼀一层miss后读第二层；

* 可做到每一层的平滑扩缩容操作。

负载均衡服务化

• Libra（LBaaS）

• 功能抽象

• 架构（API+Daemon+SSH)

• 管理系统展示

Libra-抽象化数据模型

* 将负载均衡各功能抽象化成数据模型，可支持多种负载均衡软件接入，如：LVS/Haproxy等。

Libra — 整体架构图

* 基于Tornado的API Server与基于Fabric的Task Schedule/Executor组成负载均衡服务的主要部分。

* 不同的负载均衡软件通过开发定制的Task Schedule以插件的形式接入。

Libra-管理系统展示

!* 后端日志前端展示，问题处理简单明了。

* LVS的各种常规运维操作不再需要再登录终端敲命令，改配置文件了，全部自动化。

点击应用名称进行real server配置更新

运维实战案例

• Redis TTL 为0

• Twemproxy全部请求超时

Redis TTL=0!

结论：如果一个redis作为slave，且将slave-read-only设置为off，并写入了一个带有TTL的key时，

当key过期后，该key是不会被Redis删除的，且TTL在过期后永远为0。（3.0版本修复）

注意：在进行服务迁移等情况所构成多级复制链的时候，在relay上进行过期key的读写处理的时候

需要注意TTL带来的问题

详细过程：http://slytherin.sinaapp.com/?p=300

TTL=0

TTL=0

TTL!= 0

Twemproxy Timeout

* 现象：单个MC超时，导致几乎全部请求都超时。同时Twemproxy内存短时间内激增！

15min后才自动剔除！（tcp_retries，tcp rto）

* 结论：使用Twemproxy务必注意添加timeout参数！

* 推荐视频：http://redisconference.com/video/running-twemproxy-in-production/?iframe=yes

发展与展望!

• 运维模板化、智能化

• Redis Cluster/Tair/Gemfile/Others集群方案

• Mesos+Docker资源隔离与资源调度

• 革自己的命 — from 诸超

Thank you！