2019年5月8日-10日，第十届中国数据库技术大会DTCC在北京举行，网易游戏资深系统运维工程师段正域受邀进行了主题为《网易CockroachDB云化实践》的分享，介绍了CRDB在网易内部的运用和相关测试经验。
网易游戏数据库的发展历程
网易游戏最初主要使用文本数据库来存放用户数据，慢慢发展到关系型数据库MySQL，逐渐 MySQL已经无法满足那么大的数据量后，开始使用MongoDB。
在现阶段，网易游戏需要一款能支持大数据量存储，又能支持事务的数据库，所以开始了对 NewSQL的探索。
网易游戏目前主要使用的还是MongoDB和MySQL，NewSQL仍然处于探索阶段。私有云针对了多个NewSQL数据库进行尝试，其中包括 CockroachDB，TiDB，TokuDB 等等。
经过调研，目前几款常见的NewSQL数据库支持的功能比较类似，各有优缺点，基本可以满足目前NewSQL数据库的需求，不过在具体业务场景中，CockroachDB（后简称CRDB）整体表现更优。
CockroachDB 测试
CockroachDB是一款开源的分布式NewSQL数据库，功能特性丰富：
可任意横向拓展，支持多数据副本，任一节点宕机不受影响。
支持强一致性的ACID事务，隔离级别为SERIALIZABLE。
CockroachDB基于PostgreSQL协议兼容，兼容PostgreSQL客户端。
底层使用RocksDB做KV存储。
众多的使用特性如JSON、地理分区、物理备份等。
在对几款NewSQL数据库经过一段时间的测试后，发现在实际业务场景中CRDB有更优的表现，主要体现在：
针对OLTP做深度优化，在不同连接数下的读性能和时延较好（有些数据库的高性能前提需要足够多的连接数）
——这是因为CRDB使用了非常特别的混合逻辑时钟的技术来实现全局可串行化，相对于其他数据库降低了耗时，因此查询时延较低。
支持多机房，多区域部署和管理
架构简单，安装、部署、维护、上云，都简单方便
– 只有一个二进制文件，只有一种类型的服务
– 官方提供了docker和k8s的部署支持
– 官方工具对EC2/S3等各种服务都提供了支持
– 内置监控和管理平台
除支持逻辑备份恢复外，也支持物理备份和恢复
非常优秀和专业的代码质量和代码管理，包括commit信息、issue管理等都非常专业严谨，对源码阅读和开发优化都非常友好
同时在某些方面也存在一些不足：
PostgreSQL在网易的使用不如MySQL广泛，基本的SQL不会有问题，但如果使用了MySQL特有的语句或者功能则需要调整
没有针对OLAP做深度优化
不支持proxy protocol等IP传输协议，在有负载均衡的前提下，需要经过特殊手段才能获取到客户端IP和端口
授权问题，部分功能为企业版功能，需要付费代码使用混合协议，需要注意代码的License
CockroachDB架构
CRDB在上层通过HAproxy、Nginx等做负载均衡处理，下层对应多个节点实例。
部署每个节点实例只需要一个二进制文件，充分体现了CRDB集群搭建的简单便捷。
同时还介绍了CRDB的一些核心特性：
使用SSL加密方式进行连接（可关闭），并且还需要用户密码双重验证
默认数据副本为3，可在线变更，不影响业务
– 可针对库、表、行、索引等不同维度控制不同数据不同的副本数
节点间会自动均衡分布数据
– 按范围分区，不会做哈希，容易出现热点效应，建议手工做哈希
– 按数量做分区（不是实际空间大小，各节点占用空间不一定是均衡的）
支持节点、数据的地域信息
– 设置节点的数据信息
– 根据负载的来源地域和延时情况自动转移raft leader
– 可以针对库、表、行、索引等不同维度，控制数据所处区域
支持JSON
CockroachDB常见维护操作
部署
– 直接部署二进制文件
– Kubernetes 集成
– docker 集成
监控
– 直接使用官方的 Admin UI 可以获取大量信息，有概览、监控、统计数据等大量核心指标
– 官方支持 Prometheus
支持历史数据查询
– SELECT * FROM sometable WHEREid = 100 AS OF SYTEM TIME ‘2019-05-03 15:00:00’
– 默认清理超过 24 小时的历史数据，可以调整
备份和备份恢复
– 可以使用 DUMP 和 IMPORT 命令做逻辑备份和恢复
– 企业版可以利用 BACKUP 和 RESTORE 命令做物理备份和恢复
从部署到监控到备份和恢复，CRDB的支持还是比较完善的。其中物理备份为企业版功能，由于有历史数据查询，以及多副本，备份和备份恢复未必是必须的。
运维过程中，或多或少的踩过坑。CRDB作为新兴NewSQL数据库，也会存在一些坑，不过CRDB的更新迭代速度还是非常快的。目前发现的一些坑：
删除库后新建同名库，不会继承之前的用户权限
默认开启了sql_safe_update，无法执行drop或者执行不带where条件的update和 delete（可关闭）
CockroachDB的性能与调优
QPS随节点数量的增长基本呈线性增长
– 使用9节点，简单查询可以达到MySQL单节点的四倍读性能和80%的写性能
– 非常大的范围查询无法通过增加节点数量来提升性能
响应时间接近传统关系型数据库，简单查询可以控制在5ms以内
较小的连接数（几百）的情况下仍然有很好的性能表现
巨大的并发连接数（几万甚至更多），并且所有连接均有较高QPS的情况下，性能下降明显
在某些场景中，若遇到性能不满足的情况下，我们可以通过RocksDB调参来优化性能。 RocksDB 调参的一些经验为：
默认参数相对比较均衡，适用于通用场景
针对业务特点做调整可以牺牲某项方面的性能，从而在另一些方面获得巨大的性能改善
Level间的Compact是影响写入性能的主要因素，可从减少Compact触发次数，提高Compact 速度和效率。
根据业务特点酌情开启数据压缩，用CPU换区更高的IO吞吐能力
总体来说，性能是符合期望的。不同场景需要也可以通过RocksDB调参来优化，达到自己所期望性能。
可能的云化方案
不使用虚拟化，宿主机启动多个进程，使用cgroups做资源隔离
– 资源调度和调整最灵活，但是需要自己开发管理工具
– 不易构造一个直观的监控
使用半虚拟化技术：LXC、systemd-spawn、jail等
– 资源调度和调整较灵活，但是需要自己开发管理工具
使用容器技术：docker/k8s等
– 有大量的线程的容器管理工具，降低开发成本
使用全虚拟化技术：KVM/XEN 等
– 资源隔离最优秀
– 支持使用不同的操作系统
– 性能损耗最严重
网易最终选择了LXC半虚拟化技术，首先内部已经有比较成熟的LXC集群和管理平台，其次 LXC的性能损耗极小，资源调度灵活，可以充分利用cgroup的强大功能；
且使用lxcfs可以构建直观的监控。而作为数据库服务，用户无需登录到服务器，因此不用担心隔离性弱导致的安全性隐患。
但也存在着缺点：不易做迁移，缺乏足够优秀的管理工具。
同时网易也分享了自己的LXC架构：
固定大小节点，提前预分配和初始化好，节省创建时间
每个节点独立固态硬盘，避免IO冲突
确保同实例不同节点分布在不同宿主机上
将CPU 0 留给宿主机专用，用于中断处理等
预留几个CPU 核心，所有LXC共享，供管理进程使用，确保CockroachDB进程不使用共享 CPU，管理进程只使用共享CPU
网络软中断使用共享CPU处理
云化总体架构图:
网易使用 golang 作为开发语言，使用微服务架构，设计了大量的微服务，用 grpc 进行交互。在基础设施层，除了LXC虚拟机之外，还有独立服务器（用于对性能要求极高，或者第三方云服务提供商提供的云服务器）。
网易在前端使用 Angular 作为前端框架，使用 kong 来管理 API。除了提供基础的数据库功能（例如创建集群，增减节点，备份和日志管理，监控等）之外，还提供了DBA服务，例如性能分析，索引分析等。
