nosql@vip — 唯品会nosql平台⾃动化发展及运维经验分享
TRANSCRIPT
About Me -- 赵新宇!• 唯品会NoSQL平台负责⼈人!
• 资深数据库⼯工程师 !
• 前新浪微博⾼高级DBA!
• Pythoner/Gopher!
• Weibo: @RainSlytherin!
• Weixin: @tju_newrain!
• 欢迎微博互粉或微信交流! !
• 招聘数据库/⾃自动化运维/源码开发等⼈人才! !
⺫⽬目录!• 从数据库规模的演变看业务的快速发展!
• 唯品会NoSQL⾃自动化运维平台的建设 !
• Twemproxy中间层的改造及⼤大规模部署!
• 负载均衡服务化(Lbaas/Libra)!
• 唯品会Redis/MC/Twemproxy运维经验!
• 后续的发展思路探讨!
软件选型标准!
Data Structure? Proxy or Client? HA? Persistence?
*⼤大部分情况下Redis都可以取代MC;DBA深⼊入到业务架构,决定选型和数据结构设计。
常⽤用的API服务!
• /cluster/instances -- 获取某个业务的实例配置!
• /redis/start -- 启动redis服务!
• /memcached/stop -- 停⽌止MC服务 !
• /twemproxy/clone -- 扩容twemproxy服务!
• /zabbix/status -- 获取某个业务的监控状态!
• /alert/send -- 发送报警!
全链路数据分析系统 -- 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脚本解析⺴⽹网络包,获取上述所列格式。其中具体命令再根据对应的软件协议进⾏行进⼀一步解析。
多种中间层⽅方案对⽐比!对⽐比维度 新浪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/20 2015/5/21 2015/5/22 2015/5/23 2015/5/24 2015/5/25
150
Twemproxy+Sentinel!
* Twemproxy与Sentinel同机部署,本机Sentinle只监控本机Twemproxy后端Redis资源。 * ⼀一期Sentinel直接更新Twemproxy配置,⼆二期引⼊入Config Center 。
Libra — 整体架构图!
* 基于Tornado的API Server与基于Fabric的Task Schedule/Executor组成负载均衡服务的主要部分。!* 不同的负载均衡软件通过开发定制的Task Schedule以插件的形式接⼊入。!
Libra-管理系统展⽰示 !
* 后端⽇日志前端展⽰示,问题处理简单明了。 * LVS的各种常规运维操作不再需要再登录终端敲命令,改配置⽂文件了,全部⾃自动化。!
点击应⽤用名称进⾏行real server配置更新!
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/Gemfire/Others集群⽅方案!
• Mesos+Docker资源隔离与资源调度!
• ⾰革⾃自⼰己的命 — from 诸超 !