极光笔记|百亿级KV存储在极光的运维实践之路

前言
极光从某种意义上讲，是一家数据公司。在整个公司的技术运营体系中，需要存储大量的KV数据。根据数据量、KV结构特点、数据更新频率、数据冷热、读写请求量和比例等因素，在极光逐步形成了CouchBase、Redis和Pika三种不同的KV解决方案。
以下我们主要是从大规模数据量/请求量场景下碰到的运维难题，以及服务的性能、可扩容性、数据备份与安全、运维保障工具等方面介绍一下极光在使用以上KV组件的实践经验。
一、CouchBase实践
极光 CouchBase 规模

CouchBase 当前总使用量大约在 6.5T 左右；单个集群最大25台（16核128G内存）。

CouchBase是一个非关系型数据库，它实际上是由couchdb+membase组成，所以它既能像couchdb那样存储json文档，也能像membase那样高速存储键值对。
在极光我们主要用它做KV存储，主要有以下几个特点：
速度快
由于是放在内存中的数据库，所有的读写操作都是直接操作内存，因此速度非常快。极光数据量最大的集群规模约25台机器（16核128G），可以提供1.5TB的可用内存。读写压力最大的集群，大概是8台机器，但是需要抗住100万的QPS，单机可以抗住10万以上的QPS，性能相当强悍了。

与官网宣称的性能与节点数的线性关系不同，实际使用中发现，超过40个节点的集群，在扩缩容、故障节点替换、集群稳定性方面存在明显的问题，在扩缩容、替换节点的时候，集群容易进入假死的状态，在控制台上没有任何反应，客户端断断续续出现超时或者错误的返回结果。这个过程无法快速自动恢复，在极光类似的故障最长的一次持续了3个多小时，最终我们是停掉了业务才修复的。
另外有一次故障，发现主要原因CouchBase 内存占用只增不减，导致机器内存爆满，最终被 oom。最终通过进行集群拆分暂时解决了问题，新集群也同步使用更新的版本。

高可用
主要有两个方面的高可用：一个是它自带集群方案，支持多副本模式，我们一般是选择2副本模式，类似一主一备的方案，这样可以确保没有单点故障的问题；
另一个是它自带持久化方案，可以设置定时把数据异步写到文件系统上，所以在一般情况下单一节点的宕机，对集群的可用性和性能影响有限，但是一次性故障超过2个节点，就有出现数据丢失的可能性了。

<