嘉宾介绍
周小军， 腾讯高级运维工程师，目前在腾讯社交网络事业部负责社交业务海量NoSQL集群运维和团队管理。曾在天涯社区任运维副总监，负责天涯整体运维。对互联网网站架构、数据中心、云计算及自动化运维等领域有深入研究和理解，积累了十多年的IT运维管理经验。希望穷尽一生来深入钻研运维领域。
主题简介
腾讯目前有三大NoSQL分布式存储系统，分别是：
◆Grocery，主要支撑QQ业务，包括关系链、群、圈子、消息等
◆CKV，主要支撑QQ空间、腾讯云、相册、音乐和广点通等
◆Quorum_KV，主要支撑微信业务，包括消息、朋友圈等产品
我们是SNG(腾讯社交网络事业部)社交网络运营部平台技术运营中心下的数据运维团队。团队主要负责CKV和Grocery二大NoSQL分布式存储集群的运营。目前团队有十几名工程师，负责一万几千台存储服务器。主要部署在深圳、天津、上海和广州等大区域。
存储服务器划分为几十个SET(仓库)集群，共有几百TB的内存和SSD存储容量，服务于QQ、朋友网、QQ空间、相册、广点通、微云、音乐等各类互联网核心业务。
部署模式
NoSQL集群按SET的方式部署，SET也称之为“仓库”。一个SET是一个物理单元。仓库内至少拥有四种服务器角色：
◆接入机(代理服务器)
◆存储机(主机+备机)
◆仓库管理机
◆搬迁机器
每个SET可部署为跨机架、跨IDC、跨城容灾。一个SET就是一个永不停服、永不丢数据的独立的，标准化的服务单元，类似于标准化集装箱。我们***的SET机器部署数量不会超过上千台，超大的SET会加大管理成本。
在腾讯的海量服务运营模型中，SET是一个非常重要的概念。接入层、逻辑层和数据层均按SET单元化来部署。一个业务譬如QQ音乐可能接入层和逻辑层各有十几个SET，数据层有几个SET。SET分别部署到不同的区域。每个SET都能容纳一定数量的在线用户(譬如500万在线用户)。
天津大爆炸2亿用户跨省大调度
8月12日发生在天津的特大爆炸事故中，腾讯天津数据中心距爆炸现场才1-2公里。当时天津数据中心高危，现场数名工程师受伤，市电随时可能中断，柴电只能支持不到一天。8月13日我们启动了大调度，把天津所容纳的二亿多华北活跃用户全部调度回深圳和上海。调度过程QQ用户无感知(从那几天IT业界的新闻来看，外界对这一大事件毫无知晓)。
这应该是中国互联网史上***规模的一次调度。调度的成功受益于SET化的管理，受益于数据SET的三地同步。
同步是怎么做的呢?
业务数据按仓库为单元，在全国各地IDC部署几个异地仓库，通过数据流水来实现各异地仓库间数据同步和一致性保证。当某一城市的IDC灾难性故障时，业务能迅速切到其他城市IDC恢复数据的读写，实现业务柔性可用，保证业务服务的持续性。数据的同步由同步中心负责，业务写入同步中心，由各地的仓库同步服务，从同步中心中读取数据，并写入本地仓库。
技术特点
1.低成本：利用数据冷热自动分离技术，将热数据存储在内存，冷数据存储在SSD中，从而大幅度降低成本，且保证20%以内的数据保存在内存中。
2.可扩展性强：表存储空间可以在线自动无损伸缩，业务基本无感知，适合各种规模的业务，和业务的各个生命周期。
3.高性能：单表***支持千万次/秒的访问。通过网络访问的延时1ms左右。单台存储服务器千兆网络环境支持50万/秒的访问，万兆网络环境支持超过100万/秒的访问。
4.可用性超过99.95%：软硬件全冗余设计，双机热备，主备切换对业务透明，跨机架跨交换机部署。
5.数据持久性超过8个9：数据落磁盘存储，多内存和磁盘副本，具有灾难时回档能力。
高可用架构
经过几年的不断打磨及优化，我们NoSQL分布式集群的架构已经非常的成熟，主要有以下几个特点：
1.高可靠：主备冗余，故障自动切换机制来解决单点问题，当主机故障时自动切换到备机。同时后台调度系统启动搬迁服务，把单点的备机数据搬迁到仓库里空闲的资源池。
2.异地容灾：多地部署，单IDC、甚至单个城市灾难时，服务持续可用。
3.强一致性：主提供读写，备容灾，保证数据强一致性;主故障时自动只读，用户切到备机后恢复读写，确保在单机故障时数据零丢失。
4.仓库集群机制：标准化部署，容量伸缩自动化，数据服务能力自动适配业务增长或衰退，保持对外服务的持续可用。
数据即服务的运营理念
数据中心由计算、存储、传输三大要素构成，IaaS服务提出了把传统数据中心的CPU，内存，网络和存储等转变为资源的目标，为业务提供计算资源的池化及智能调度管理。对于数据层我们的目标则是DaaS，把数据做为服务提供给用户。
构建可伸缩的分布式数据库
我们的分布式数据库把存储资源池化，把内存存储块及磁盘存储块做为资源，放在一个存储大池子里按照较固定的存储单元进行管理，并在其之上部署存储智能调度系统。
因此，我们的上万台存储服务器已经是真正意义上，具备动态伸缩能力的分布式数据库：
◆业务使用数据容量最小为1GB，***为10TB。
◆内存存储从1GB扩容到多机的100GB在分钟级在线完成，扩容过程业务无感知无损。
◆业务保持可用率4个9，延迟2ms。
◆扩容过程不需要工程师跟踪。
我们的数据管理集中化，在数据复杂度以及数据量不断增长的情况下，数据运维能够支撑多变的业务需求。
运维即服务，数据即服务
在DaaS中，我们已经落地实施了以下几点：
1.业务自助接入服务：业务申请、创建业务ID、自动创建表空间、自动下线，贯穿整个业务的生命周期。
2.机器部署：采用基础运维平台，包括包安装，一键上架等自动化部署。支持跨机架部署。
3.弹性伸缩：一是存储代理的弹性;二是存储分配空间的弹性，根据业务存储使用率自动扩缩容。
4.水位调度：业务流量在接入集群间自动流动，存储块在存储集群间自动流动。
5.用户报表：全方位的访问趋势、存储趋势、数据冷热分布、接入机分布、存储机分布、主机当前负载等业务存储数据。
6.多协议支持：支持私有协议、Redis协议和Memcache协议。
7.成本分摊：按请求量和存储量进行月度财务核算，便于对用户成本透明。
成本优化策略
上万台存储集群的成本优化是运营中比较核心的目标之一，我们在成本上的措施主要为：
1.用访问密度做为可度量的成本指标，按每单位GB的访问量来衡量业务接入的合理性。
2.数据密度，由于数据块是由固定长度的Block组成的。用户记录的不定长会造成存储块碎片严重。所以我们通过定期的碎片整理来实现存储块的高效使用，碎片少，提升有效存储空间。
3.分层存储，热KEY保存在内存，冷KEY下沉到SSD硬盘。按通常的八二冷热数据比例，我们可以节省大量的内存服务器。
4.备机复用，为保证数据的强一致性，我们的存储主机提供读写服务，备机只提供数据流水落地，不提供服务。因此我们在备机上部署容器，满足公司离线计算或长尾业务对计算资源的需求。
运营团队的工作本质
研发和DBA的关系就如同一辆车，我们造好一辆车，写好说明手册，而DBA则负责调教和维护这辆车，让它能发挥***的性能，坐得最舒服。
—MySQL研发团队成员赖铮
的确，我们运营团队也是类似，与研发团队一起把原始的数据库引擎打磨得更易于运维、性能更高及对业务更多的特性支持，发挥工匠精神，不断在成本、安全、质量和效率上追求***。
除了研发团队，运维团队本身也是开发&运维相结合的团队，团队内有开发和运维二种角色：
◆开发工程师：负责持续集成环境、流程引擎、接口、代码审核等工作。
◆运维工程师：负责上到产品经理，下到任务粒度级的开发等职责。
运维强大的工具平台具备了功能丰富的API接口，譬如身份验证、流程引擎、CMDB接口、监控接口、日志上报、包安装接口等功能，极大地提高了运维工程师工具开发效率。
如何一起愉快地发展
“高效运维”公众号(如下二维码)值得您的关注，作为高效运维系列微信群(国内领先的运维垂直社区)的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛精彩分享及群友原创等。“高效运维”也是互联网专栏《高效运维***实践》及运维2.0官方公众号。
重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。
